Итак, у меня была проблема с D-Link DSL-G604T, аналогичная описанной в корневом сообщении.
Симптомы:
Выключен Стрим-ТВ -- интернет работает по беспроводному интерфейсу и по кабелю UTP. Включаю AmiNET 110 кнопкой на пульте, и передача данных по Wi-Fi (wlan0) прекращается. Не проходит пинг даже на саму точку доступа "ping -c2 192.168.1.1". Передача данных по Ethernet порту точки доступа (eth0) идёт нормально. Если Стрим-ТВ выключить кнопкой на пульте приставки STB AmiNET 110, через некоторое время передача данных по беспроводному интерфейсу возобновляется.
Работа велась под Линуксом, но её можно выполнить и из командной строки Windows. Отличия лишь в том, что утилиту tcpdump придётся чем-то заменить, или не пользоваться ею вообще.
Перед тем, как воспользоваться моей инструкцией, убедитесь в следующем:
1. У вас прошивка точки доступа D-Link DSL-G604T V2.01B01T01.RU.20060109. Если более старая, то обновите. Прошивки лежат тут:
http://ftp.dlink.ru/pub/ADSL/DSL-G604T/Firmware/ADSL2+/
2. При выключенной приставке STB AmiNET 110 с интернетом у вас проблем не возникает. Если есть проблемы, то о настройках я бы советовал читать здесь:
viewtopic.php?t=25725&postdays=0&postorder=asc&start=0
Важное дополнение: DHCP сервер должен быть выключен. Причина: DSLAM стрима шлёт данные только на те IP адреса, которые выдал его собственный DHCP сервер. Если включить DHCP сервер точки доступа, IP адрес приставке выдаст именно точка доступа, а не DSLAM стрима. Поэтому для DSLAM-а стрима наша приставка существовать не будет и никакой поток видео-данных на неё не пойдёт.
3. Стрим-ТВ нормально показывает, каналы переключаются.
4. Подключаемся к точке доступа по беспроводному интерфейсу. STB-приставка выключена. Пингуем, например, mail.ru: "ping -c2 mail.ru". При выключенной приставке пинг проходит, число полученных ответов равно числу отправленных. Включаем приставку, дожидаемся видео на экране телевизора. Снова пингуем тот же адрес -- пинг не проходит. Ответов либо нет совсем, либо они приходят с большими задержками и более половины ответов теряются. Выключили приставку -- через некоторое время пинг снова пошёл.
Причина этого -- забивание беспроводного интерфейса потоком UDP multicast пакетов, которые и содержат данные видео и аудио. Это пакеты, которые отправляются не на конкретный физический или сетевой адрес, а доставляются всем сетевым устройствам, которые сами "решают", что с таким потоком данных делать. Этот multicast поток находится на грани или за гранью пропускной способности беспроводного интерфейса точки доступа, что лишает её возможности передавать другие данные. А Wi-Fi сетевая карта компьютера, подключенного к такой точке доступа, такие пакеты игнорирует, т.к. ждёт unicast пакеты ("интернет").
Как проверить это на практике?
Из-под учётной записи суперпользователя Linux запускаем утилиту tcpdump:
#/usr/sbin/tcpdump -i ath0 -c 2 udp and ip multicast
ath0 -- наша Wi-Fi карта
2 -- число пакетов, после получения которых можно выйти
"udp and ip multicast" -- признаки пакетов, которые надо получить
Если STB приставка выключена, эта утилита ничего не выдаёт на экран.
Если же включить приставку Стрим-ТВ, то мы увидим примерно следующее:
# /usr/sbin/tcpdump -i ath0 -c 2 udp and ip multicast
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
01:25:46.315996 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:02:0f:05:3d, length: 548
01:25:47.307352 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:02:02:0f:05:3d, length: 548
2 packets captured
2 packets received by filter
0 packets dropped by kernel
-- это STB приставка получает адрес
позже данные будут примерно такими:
# /usr/sbin/tcpdump -i ath0 -c 2 udp and ip multicast
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
01:28:25.193467 IP 172.16.73.17.1048 > 239.255.2.22.5500: UDP, length 1316
01:28:25.199304 IP 172.16.73.17.1048 > 239.255.2.22.5500: UDP, length 1316
2 packets captured
386 packets received by filter
355 packets dropped by kernel
-- от стримовского DSLAM-а 172.16.73.17 валятся multicast пакеты на адрес 239.255.2.22. Это адрес из специального multicast адресного пространства. Валятся, как и положено, в порт 5500.
tcpdump -- наше ключевое средство диагностики.
Чтобы иметь нормальный доступ к сети по беспроводному интерфейсу, надо его разгрузить, избавив беспроводной интерфейс точки доступа от multicast потока.
Совет, данный здесь
viewtopic.php?p=127530#127530 выполнить следующие команды
ifconfig nas1 -multicast
ifconfig wlan0 -multicast
Не работает (по крайней мере, с данной прошивкой), в чём можно легко убедиться -- tcpdump будет демонстрировать получение UDP multicast пакетов. Даже если ещё и выполнить
ifconfig nas2 -multicast. tcpdump беспристрастно покажет продолжение multicast флуда на беспроводной интерфейс.
Для решения проблемы надо добавить фильтр моста. Впервые об этом я прочитал тут:
viewtopic.php?p=117080&sid=0eb789b027f9246e7cfa488ae20d3b4e#117080
Для этого надо войти телнетом на точку доступа:
$ telnet 192.168.1.1
Там надо выполнить следующую команду:
# /usr/sbin/brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000d08000302 no eth0
nas1
nas2
wlan0
br1 8000.000000000000 no
Нас интересует мост br0, соединяющий беспроводной интерфейс wlan0, Ethernet интерфейс eth0 и PPPoE интерфейсы nas1 и nas2. Надо прервать поток UDP multicast от интерфейса nas2 к Wi-Fi карте точки доступа wlan0. Это можно сделать с помощью команды addfilter. Но ей нужно сообщить физический адрес источника multicast потока. Список подключенных устройств можно увидеть так:
# /usr/sbin/brctl showmacs br0
port no mac addr is local? ageing timer
1 00:02:02:0f:05:3d no 22.24
1 00:0d:08:00:03:02 yes 0.00
4 00:15:e9:84:81:0c no 0.02
2 00:16:9c:6c:87:c0 no 22.23
3 00:40:43:bd:64:2d no 71.62
4 00:50:f1:12:12:10 yes 0.00
2 00:aa:bb:cc:dd:11 yes 0.00
3 00:aa:bb:cc:dd:12 yes 0.00
Нас интересует адрес стримовского DSLAM-а, а это явно нелокальное устройство:
# /usr/sbin/brctl showmacs br0 | grep no
port no mac addr is local? ageing timer
1 00:02:02:0f:05:3d no 2.64
4 00:15:e9:84:81:0c no 0.05
2 00:16:9c:6c:87:c0 no 2.63
3 00:40:43:bd:64:2d no 71.20
Итак, у имеются 4 кандидата на источник флуда. 00:15:e9:84:81:0c -- Wi-Fi плата. Осталось три. Можно исключить ещё один -- интерфейс, который передаёт для нас данные:
# ping -c 2 mail.ru
PING mail.ru (194.67.57.26): 56 data bytes
64 bytes from 194.67.57.26: icmp_seq=0 ttl=121 time=10.0 ms
64 bytes from 194.67.57.26: icmp_seq=1 ttl=121 time=10.0 ms
--- mail.ru ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 10.0/10.0/10.0 ms
# arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.2 ether 00:15:E9:84:81:0C C br0
Из оставшихся двух методом перебора можно найти DSLAM, отправляющий multicast поток. А можно и предположить, что его mac адрес начинается цифрами 00:40:43:xx:xx:xx (крупные корпорации редко закупают мелкие партии оборудования).
Запускаем в нашей длительной telnet сессии на точке доступа утилиту управления мостом для активации фильтра:
# brctl addfilter br0 wlan0 nas2 00-00-00-00-00-00 00-40-43-xx-xx-xx 0x0 deny
00-40-43-xx-xx-xx -- найденный нами мак-адрес стримовского DSLAM-а.
Теперь важно проверить промежуточный результат. Выполняем команду
# /usr/sbin/brctl showfilter br0
Bridge Filter Table
Access Type Destination Source Protocol
Deny 00-00-00-00-00-00 00-40-43-bd-64-2d 0x0
port: wlan0 port: nas2
Frames Matched = 0
Первое важное замечание: фильтр появился и он будет фильтровать то, что нам нужно. Внимательно проверим все поля. Второе важное замечание: пока multicast потока нет (STB приставка выключена), в соответствие нашему фильтру не попал ни один кадр -- "Frames Matched = 0". Включаем STB приставку и наблюдаем, что повторное исполнение команды "# /usr/sbin/brctl showfilter br0" демонстрирует увеличивающееся число отброшенных фильтром кадров. Если приставку выключить, число отброшенных кадров увеличиваться перестанет.
Мак-адрес получателя указываем 00-00-00-00-00-00, что означает игнорирование этого параметра. Дело в том, что стримовский DSLAM не указывает получателя multicast пакета, т.к. таким получателем может быть любое устройства.
Заканчиваем telnet сессию командой exit и смотрим Стрим-ТВ одновременно с работой Wi-Fi интернета. Сильно тормозит?
Для проверки можно снова выполнить команду "# /usr/sbin/tcpdump -i ath0 -c 2 udp and ip multicast" при включенной приставке. Она должна и через 3 и через 5 минут ничего не выдать, замерев в ожидании пакетов, поток которых мы остановили. Прервать ожидание можно комбинацией клавиш Ctrl-C.
В точке доступа DSL-G604T живёт Linux и busybox в качестве интерпретатора командной строки. Для выбора набранных ранее команд можно применять клавиши со стрелками вверх и вниз, а после ввода первых букв команды можно нажимать tab, чтобы busybox попытался "угадать" требуемую команду, подставив имя существующих в системе с началом, соответствующим первым набранным символам.
Вход
Регистрация
FAQ
Поиск
