Чому деякі маршрутизатори WiFi блокують багатоадресні пакети, що йдуть від дротового до бездротового?

Я працював з десятками WiFi-маршрутизаторів споживчих класів, і вони з цим дійсно вражали або пропускали, хоча, здається, стає все краще.

Приклад випуску:

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 -і-бездротова мережа-on-actiontec / td-p / 461359 для прикладів.

Чи є список де не сумісний з цим? У чому причина? Просто помилка в роутері?

Зазвичай це пов'язано з помилками в домашніх маршрутизаторах Wi-Fi (AP) або іноді в чіпсетах / драйверах / програмному забезпеченні бездротового клієнта.

На Wi-Fi надсилання бездротових повідомлень з AP до бездротових клієнтів (це відомо в стандарті як "Від системи розподілу" або "FromDS") є складним, тому існує безліч способів його виходу з ладу, і це легко вводити помилок.

1. Навіть незважаючи на те, що радіоносій є досить ненадійним, що потрібно 802.11 одноадресних повідомлень, щоб мати підтвердження на рівні зв’язку (ACK) та отримувати повторну передачу кілька разів, якщо немає ACK, багатоадресні повідомлення FromDS ніколи не ставляться ACKed, оскільки їм потрібно буде ACKed усіма бездротовими клієнтами AP, що може бути цілком "штормом АСК". Тож замість цього мультимедійні повідомлення FromDS повинні надсилатися з низькою швидкістю передачі даних; використовуючи простішу, повільнішу, модульну модуляцію співвідношення сигнал / шум, яка легко розшифрується, навіть при низькому рівні сигналу / шуму, яку, сподіваємось, надійно отримають усі клієнти AP. Деякі AP-адреси дозволяють адміністратору встановлювати швидкість передачі даних, а деякі адміністратори мимоволі встановлюють його занадто високим, щоб деякі їх клієнти надійно отримували, порушуючи доставку багатоадресної передачі цим клієнтам.
2. Коли використовується WPA (TKIP) або WPA2 (AES-CCMP) шифрування, мультимедійні повідомлення FromDS повинні бути зашифровані окремим ключем шифрування, відомим усім клієнтам (це називається груповим ключем).
3. Коли клієнт залишає мережу, або щогодини або близько того, просто задля доброї міри, груповий ключ потрібно змінити, щоб клієнт, який вийшов, більше не мав доступу до розшифровки багатоадресних повідомлень. Цей процес "обертання групових ключів" іноді має проблеми. Якщо клієнт не підтвердив отримання нового групового ключа, AP повинен видалити аутентифікацію цього клієнта, але якщо він не зробить це через помилку, клієнт може мати неправильний груповий ключ і, таким чином, бути "глухим" "для багатоадресних повідомлень, не усвідомлюючи цього.
4. Коли ввімкнено "змішаний режим" WPA2 (тобто коли одночасно ввімкнено і WPA, і WPA2), багатоадресні повідомлення FromDS, як правило, повинні бути закодовані шифром TKIP, щоб всі клієнти гарантовано знали, як його розшифрувати. .
5. Багатоадресні повідомлення FromDS повинні бути встановлені в чергу в AP і передаватися лише тоді, коли від усіх клієнтів, які дбають про багатоадресні повідомлення, можна буде включити їх приймачі. Час між періодами "безпечної передачі багатоадресних даних FromDS" називається "інтервалом DTIM". Якщо AP або клієнти завершать обробку інтервалу DTIM, це може призвести до того, що клієнти не зможуть надійно приймати багатоадресні дані.
6. Деякі AP-сервіси мають функції запобігання бездротовим клієнтам можливості спілкуватися безпосередньо один з одним, щоб, можливо, не дозволяти вашим бездротовим гостям не хавати інших бездротових гостей. Ці функції зазвичай блокують мультикасти з WLAN-пристроїв на інші пристрої WLAN, і цілком можуть бути реалізовані наївно, що навіть блокує багатоадресні передачі з локальної мережі в бездротову мережу.

Божевільна річ полягає в тому, що багатоадресні передачі "ToDS" робляться так само, як одноадреси ToDS, і тому вони рідко ламаються. А оскільки багатоадресні ToDS (не мультимедіа FromDS) - це все, що потрібно, коли бездротовий клієнт отримує DHCP в оренду та ARP, щоб знайти його шлюз за замовчуванням, більшість клієнтів мають змогу підключитися та переглядати Інтернет, перевіряти електронну пошту тощо, навіть коли FromDS багатоадресні ламаються. Тому багато людей не розуміють, що у них є багатоадресна проблема у своїй мережі, поки вони не намагаються робити такі речі, як mDNS (він же IETF ZeroConf, Apple Bonjour, Avahi тощо).

Ще кілька речей, які слід зазначити, що стосуються провідних бездротових передач багатоадресної передачі:

1. Більшість локальних мереж, таких як mDNS, виконуються за допомогою спеціальних діапазонів адрес багатоадресної передачі, які не призначені для маршрутизації через маршрутизатори. Оскільки домашні шлюзи з підтримкою Wi-Fi з NAT підтримуються маршрутизаторами, mDNS не повинен переходити з WAN в [W] LAN. Але це ДОБРІЛЬНО працювати від локальної мережі до WLAN.
2. Оскільки мультимедіа в Wi-Fi потрібно надсилати з низькою швидкістю передачі даних, вони забирають багато ефірного часу. Отже, вони "дорогі", і ви не хочете мати їх занадто багато. Це протилежне тому, як все працює на провідній Ethernet, де багатоадресні передачі "менш дорогі", ніж надсилання окремих одноадресних даних на кожну машину, "наприклад, налаштування у відеопотік багатоадресної передачі". Через це багато AP-серверів Wi-Fi зроблять "IGMP Snooping", щоб спостерігати, на які машини надсилаються запити протоколу IGMP-протоколу управління групою, висловлюючи своє бажання налаштуватися на заданий потік багатоадресної передачі. AP-адреси Wi-Fi, які роблять IGMP Snooping, автоматично не пересилають деякі класи багатоадресних повідомлень у бездротову мережу, якщо вони не бачать, щоб клієнт бездротового зв'язку намагався підписатися на цей потік через IGMP. У документах, що описують, як правильно робити IGMP Snooping, чітко видно, що певні класи низькочастотної широкосмугової передачі даних (mDNS вписуються в цю категорію) повинні завжди пересилатися, навіть якщо ніхто не попросив їх прямо через IGMP. Однак я би не здивувався, якщо там порушені реалізації IGMP Snooping, які абсолютно ніколи не пересилають будь-який тип багатоадресної передачі, поки він не побачить на нього запит IGMP.

tl; dr: Клопи. Багато можливостей для помилок. І іноді погано розроблені функції та помилки конфігурації. Ваш найкращий захист - купувати високоякісні AP у компаній, які дбають про те, щоб переконатися в тому, що багатоадресна мережа працює. Оскільки Apple так любить Bonjour (mDNS), AP-адреси Apple, мабуть, є найбільш стабільними у надійному проходженні багатоадресних повідомлень, а клієнтські пристрої Apple Wi-Fi, мабуть, є найбільш стабільними при надійному отриманні багатоадресних повідомлень

@Spiff зробив кілька дивовижних моментів у своїй відповіді, і я тут не повторююсь. Але є деякі інші відповіді та альтернативи, щоб обійти це питання.

Коротка відповідь? Я не думаю, що вони завжди "блокують" так сильно, як просто "не роблять цього з початку" через інженерну лінь, створюючи якийсь конкретний пристрій. Деякі не вважають це пріоритетним, а деякі просто не мають часу, щоб він працював.

Це не високий список пріоритетів порівняно з усіма новими маркетинговими "функціями", які використовуються для продажу цих пристроїв для споживачів, і це особливість більшості не кмітливих людей, які не мають кмітливості, поняття не мають, тому внизу списку пріоритетів це стосується лише того, що якщо великий набір власників не скаржиться на це, він залишається поза будь-якими оновленнями версій.

Якщо ви хочете, щоб пристрій, який його підтримує, зробити належну ретельність щодо ваших досліджень, і ви отримаєте пристрій, який його підтримує, або якщо ви зможете знайти новий або вживаний пристрій, який підтримує щось на зразок OpenWrt або Tomato від Polarcloud, ви можете бути впевнений у отриманні того, що вам потрібно.

Удачі. :)