Почему некоторые маршрутизаторы WiFi блокируют многоадресные пакеты, идущие от проводного к беспроводному?

Я работал с десятками потребительских Wi-Fi-роутеров, и им это очень понравилось, хотя, похоже, все становится лучше.

Пример вопроса:

1. Устройство, которое можно обнаружить с помощью mDNS, подключается к маршрутизатору с помощью кабеля.
2. Другое устройство, подключенное к маршрутизатору по WiFi, пытается обнаружить устройство на шаге 1.
3. Пакеты с устройства по WiFi не попадают на проводное устройство, или, если они это делают, пакеты, отправленные с проводного устройства, не попадают на беспроводное устройство.

Многие маршрутизаторы имеют настройки, позволяющие это работать.

См. Http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 и http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -и-беспроводная сеть-на-actiontec / td-p / 461359 для примеров.

Есть ли где-нибудь список несовместимости с этим? В чем причина? Просто ошибка в роутере?

Обычно это происходит из-за ошибок в домашних шлюзах Wi-Fi (AP) или иногда в наборах микросхем / драйверах / программном обеспечении беспроводного клиента.

На Wi-Fi отправка многоадресных рассылок с точки доступа на беспроводных клиентов (это известно в стандарте как «Из системы распространения» или «FromDS») является сложной задачей, поэтому существует множество способов ее сбоя, и ее легко ввести ошибки.

1. Несмотря на то, что радиосвязь достаточно ненадежна, для одноадресных передач 802.11 требуется наличие подтверждений на уровне канала (ACK) и их повторная передача несколько раз, если ACK отсутствует, многоадресные рассылки FromDS никогда не ACKed, поскольку они должны быть подтверждены всеми беспроводными клиентами AP, который мог быть довольно "штормом ACK". Поэтому вместо этого групповые рассылки FromDS должны отправляться с низкой скоростью передачи данных; используя более простую, более медленную, простую для декодирования схему модуляции отношения сигнал-шум даже при низком уровне, которая, мы надеемся, может быть надежно принята всеми клиентами AP. Некоторые точки доступа позволяют администратору устанавливать скорость многоадресной рассылки, а некоторые администраторы невольно устанавливают ее слишком высокой, чтобы некоторые из их клиентов могли получать надежно, прерывая многоадресную доставку этим клиентам.
2. Когда используется шифрование WPA (TKIP) или WPA2 (AES-CCMP), многоадресные рассылки FromDS должны быть зашифрованы с помощью отдельного ключа шифрования, который известен всем клиентам (это называется групповым ключом).
3. Когда клиент покидает сеть или каждый час или около того, просто для хорошей меры, ключ группы необходимо изменить, чтобы ушедший клиент больше не имел доступа для дешифрования многоадресных рассылок. Этот процесс "Поворот ключа группы" иногда имеет проблемы. Если клиент не подтверждает получение нового группового ключа, AP должен де-аутентифицировать этого клиента, но если это не удается сделать из-за ошибки, клиент может иметь неправильный групповой ключ и, таким образом, быть "глухим" на многоадресную рассылку, не осознавая этого.
4. Когда WPA2 «смешанный режим» включен (то есть, когда и WPA, и WPA2 включены одновременно), многоадресные рассылки FromDS обычно должны кодироваться с помощью шифра TKIP, чтобы все клиенты гарантированно знали, как его декодировать. ,
5. Многоадресные рассылки FromDS должны быть поставлены в очередь AP и передаваться только в те моменты, когда от всех клиентов, которым небезразличны многоадресные рассылки, могут быть включены их приемники. Время между «безопасными для передачи FromDS групповыми» периодами называется «интервалом DTIM». Если точка доступа или клиенты испортят свою обработку интервала DTIM, это может привести к тому, что клиенты не смогут получать многоадресные сообщения надежно.
6. Некоторые точки доступа имеют функции, которые не позволяют беспроводным клиентам общаться напрямую друг с другом, и, возможно, не позволяют вашим беспроводным гостям взломать других ваших беспроводных гостей. Эти функции обычно блокируют многоадресную передачу от устройств WLAN к другим устройствам WLAN, и их вполне можно реализовать наивным способом, который даже блокирует многоадресную передачу от LAN к WLAN.

Сумасшедшая вещь заключается в том, что многоадресные рассылки «ToDS» выполняются так же, как одноадресные рассылки ToDS, и поэтому они редко ломаются. А поскольку многоадресные рассылки ToDS (не групповые рассылки FromDS) - это все, что нужно, когда беспроводной клиент получает аренду DHCP и ARP для поиска своего шлюза по умолчанию, большинство клиентов могут подключаться и просматривать веб-страницы, проверять электронную почту и т. Д. Даже при использовании FromDS. мультикасты нарушены. Поэтому многие люди не осознают, что у них есть проблемы с многоадресной рассылкой в ​​их сети, пока они не попытаются сделать такие вещи, как mDNS (он же IETF ZeroConf, Apple Bonjour, Avahi и т. Д.).

Еще пара моментов, которые следует отметить в отношении проводных и беспроводных многоадресных передач:

1. Большинство многоадресных рассылок локальной сети, таких как mDNS, выполняются с использованием специальных диапазонов многоадресных адресов, которые не предназначены для маршрутизации через маршрутизаторы. Поскольку домашние шлюзы с поддержкой Wi-Fi с включенным NAT считаются маршрутизаторами, mDNS не предназначен для перехода от WAN к [W] LAN. Но это ДОЛЖНО работать от LAN до WLAN.
2. Поскольку многоадресные рассылки по Wi-Fi необходимо отправлять с низкой скоростью передачи данных, они занимают много эфирного времени. Так что они «дорогие», и вы не хотите иметь их слишком много. Это противоположно тому, как все работает в проводном Ethernet, где многоадресные рассылки «дешевле», чем отправка отдельных одноадресных сообщений на каждую машину, например, «настраивая в многоадресном видеопотоке». Из-за этого многие точки доступа Wi-Fi будут выполнять «IGMP Snooping», чтобы посмотреть, какие машины отправляют запросы IGMP, выражая свое желание настроиться на данный многоадресный поток. Точки доступа Wi-Fi, которые выполняют IGMP Snooping, не будут автоматически пересылать некоторые классы многоадресных рассылок в беспроводную сеть, если они не увидят, что беспроводной клиент пытается подписаться на этот поток через IGMP. Документы, в которых описывается, как правильно выполнять IGMP Snooping, ясно дают понять, что определенные классы многоадресных рассылок с низкой пропускной способностью (mDNS вписывается в эту категорию) должны всегда передаваться, даже если никто явно не запрашивал их через IGMP. Тем не менее, я не удивлюсь, если появятся сломанные реализации IGMP Snooping, которые абсолютно никогда не отправляют многоадресную рассылку, пока не увидит запрос IGMP.

tl; dr: ошибки. Много возможностей для ошибок. И иногда плохо разработанные функции и ошибки конфигурации. Ваша лучшая защита - покупать высококачественные точки доступа у компаний, которые заботятся о том, чтобы многоадресная рассылка работала. Так как Apple очень любит Bonjour (mDNS), точки доступа Apple, вероятно, наиболее стабильно превосходно справляются с многоадресной передачей, а клиентские устройства Apple Wi-Fi, вероятно, наиболее стабильно превосходны в получении многоадресных сообщений.

@Spiff сделал несколько удивительных замечаний в своем ответе, и я не буду повторять здесь. Но есть и другие ответы и альтернативы, чтобы обойти эту проблему.

Краткий ответ? Я не думаю, что они всегда "блокируют" столько, сколько они просто "не делают это с самого начала" из-за инженерной лени, создающей какое-то конкретное устройство. У некоторых это не является приоритетом, а у некоторых просто нет времени, чтобы заставить его работать.

Он не занимает первое место в списке приоритетов по сравнению со всеми новыми «функциями», используемыми маркетингом для продажи этих потребительских устройств, и это особенность, которую не разбираются в большинстве не разбирающихся в технологиях людей, поэтому в списке приоритетов он идет до того момента, когда если большой пул владельцев не жалуется на это, он не учитывается в любых обновлениях ревизий.

Если вам нужно устройство, которое его поддерживает, проведите тщательную проверку своих исследований, и вы получите устройство, которое его поддерживает, или если вы можете найти новое или использованное устройство, которое поддерживает что-то вроде OpenWrt или Tomato, из Polarcloud, вы можете уверен получить то, что вам нужно.

Удачи. :)