Perché alcuni router WiFi bloccano i pacchetti multicast che vanno dal cablato al wireless?

Ho lavorato con dozzine di router WiFi di livello consumer, e sono stati davvero imperdibili, anche se sembra che stia migliorando.

Esempio di problema:

1. Un dispositivo che può essere scoperto con mDNS è collegato al router con un cavo.
2. Un altro dispositivo collegato al router su WiFi tenta di rilevare il dispositivo nel passaggio 1.
3. I pacchetti dal dispositivo su WiFi non arrivano al dispositivo cablato o, se lo fanno, i pacchetti inviati dal dispositivo cablato non arrivano al dispositivo wireless.

Molti router hanno impostazioni che consentono di farlo funzionare.

Vedi http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 e http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -e-wireless-network-on-actiontec / td-p / 461359 per esempi.

Esiste un elenco in qualche modo incompatibile con questo? Qual è la causa? Solo un bug nel router?

Di solito è dovuto a bug nei router gateway di casa Wi-Fi (AP), o talvolta nei chipset / driver / software client wireless.

Sul Wi-Fi, l'invio di multicast dall'AP ai client wireless (questo è noto nello standard come "Dal sistema di distribuzione" o "FromDS") è complicato, quindi ci sono molti modi in cui può fallire ed è facile introdurre bug.

1. Anche se il supporto radio non è abbastanza inaffidabile da richiedere agli unicast 802.11 di avere riconoscimenti a livello di collegamento (ACK) e di essere ritrasmessi più volte se non c'è ACK, i multicast FromDS non vengono mai ACK perché devono essere ACK da tutti i client wireless dell'AP, che potrebbe essere piuttosto una "tempesta ACK". Quindi, invece, i multicast FromDS devono essere inviati a una bassa velocità di dati; utilizzando uno schema di modulazione più semplice, più lento, facile da decodificare, anche a basso rapporto segnale rumore, che si spera possa essere ricevuto in modo affidabile da tutti i client dell'AP. Alcuni AP consentono all'amministratore di impostare la velocità multicast e alcuni amministratori impostano involontariamente un valore troppo alto per consentire ad alcuni dei loro clienti di ricevere in modo affidabile, interrompendo la consegna multicast a tali client.
2. Quando è in uso la crittografia WPA (TKIP) o WPA2 (AES-CCMP), i multicast FromDS devono essere crittografati con una chiave di crittografia separata nota a tutti i client (questa è chiamata chiave di gruppo).
3. Quando un client lascia la rete, o ogni ora circa, solo per buona misura, la chiave di gruppo deve essere cambiata in modo che il client che ha lasciato non abbia più accesso per decrittografare i multicast. Questo processo di "Rotazione chiave di gruppo" a volte presenta problemi. Se un client non riconosce la ricezione della nuova chiave di gruppo, l'AP dovrebbe annullare l'autenticazione di quel client, ma se non lo fa a causa di un bug, un client potrebbe avere la chiave di gruppo sbagliata e quindi essere "sordo "ai multicast senza accorgersene.
4. Quando la "modalità mista" di WPA2 è abilitata (ovvero quando sia WPA che WPA2 sono abilitati contemporaneamente), i multicast FromDS devono in genere essere codificati con il codice TKIP, in modo che tutti i client siano sicuri di sapere come decodificarlo .
5. I multicast FromDS devono essere messi in coda dall'AP e trasmessi solo in momenti in cui ci si può aspettare che tutti i client che si occupano di multicast abbiano i loro ricevitori accesi. Il tempo tra i periodi di "trasmissione sicura di multicast FromDS" viene chiamato "intervallo DTIM". Se l'AP o i client rovinano la gestione degli intervalli DTIM, i client potrebbero non essere in grado di ricevere i multicast in modo affidabile.
6. Alcuni AP hanno funzionalità che impediscono ai client wireless di dialogare direttamente tra loro, per impedire agli ospiti wireless di violare gli altri ospiti wireless. Queste funzionalità di solito bloccano i multicast da dispositivi WLAN ad altri dispositivi WLAN e potrebbero essere implementati in modo ingenuo che blocca persino i multicast da LAN a WLAN.

La cosa folle è che i multicast "ToDS" sono fatti proprio come gli unicasti ToDS e quindi si rompono raramente. E poiché i multicast ToDS (non i multicast FromDS) sono tutto ciò che è necessario quando un client wireless ottiene un lease DHCP e ARP per trovare il gateway predefinito, la maggior parte dei client è in grado di connettersi e navigare sul Web, controllare la posta elettronica, ecc. Anche quando FromDS i multicast sono rotti. Quindi molte persone non si rendono conto di avere problemi multicast sulla loro rete fino a quando non provano a fare cose come mDNS (aka IETF ZeroConf, Apple Bonjour, Avahi, ecc.).

Un altro paio di cose da notare, per quanto riguarda le trasmissioni multicast cablate a wireless:

1. La maggior parte dei multicast LAN, come mDNS, viene eseguita utilizzando intervalli di indirizzi multicast speciali che non devono essere instradati su router. Poiché i gateway domestici con funzionalità Wi-Fi con NAT abilitato contano come router, mDNS non intende attraversare da WAN a [W] LAN. Ma DOVREBBE funzionare da LAN a WLAN.
2. Poiché i multicast sul Wi-Fi devono essere inviati a una bassa velocità di trasmissione dei dati, richiedono molto tempo di trasmissione. Quindi sono "costosi" e non vuoi averne troppi. Questo è l'opposto di come funzionano le cose su Ethernet cablata, in cui i multicast sono "meno costosi" rispetto all'invio di unicast separati per ogni macchina "sintonizzandosi su un flusso video multicast", ad esempio. Per questo motivo, molti AP Wi-Fi eseguiranno lo "snooping IGMP" per controllare quali macchine stanno inviando richieste IGMP (Internet Group Management Protocol), esprimendo il loro desiderio di sintonizzarsi su un determinato flusso multicast. Gli AP Wi-Fi che eseguono snooping IGMP non inoltreranno automaticamente alcune classi di multicast sulla rete wireless a meno che non vedano un client wireless tentare di abbonarsi a tale flusso tramite IGMP. I documenti che descrivono come eseguire lo snooping IGMP chiariscono che determinate classi di multicast a bassa larghezza di banda (mDNS rientrano in questa categoria) dovrebbero essere sempre inoltrate anche se nessuno le ha esplicitamente richieste tramite IGMP. Tuttavia, non sarei sorpreso se ci sono implementazioni di Snooping IGMP rotte che assolutamente non inoltrano mai alcun tipo di multicast fino a quando non vede una richiesta IGMP per questo.

tl; dr: Bugs. Molte opportunità per i bug. E occasionali funzioni mal progettate ed errori di configurazione. La tua migliore difesa è acquistare AP di alta qualità da aziende che vogliono assicurarsi che i multicast funzionino. Poiché Apple ama così tanto Bonjour (mDNS), gli AP di Apple sono probabilmente i più costantemente eccellenti per trasmettere i multicast in modo affidabile, e i dispositivi client Wi-Fi di Apple sono probabilmente i più costantemente eccellenti per ricevere i multicast in modo affidabile.

@Spiff ha fatto alcuni punti meravigliosi nella sua risposta e non lo ripeterò qui. Ma ci sono altre risposte e alternative per aggirare questo problema.

Risposta breve? Non credo che "blocchino" sempre tanto quanto "non lo fanno o non iniziano con" a causa della pigrizia dell'ingegnere che crea un particolare dispositivo. Alcuni non hanno la massima priorità, altri semplicemente non hanno il tempo di farlo funzionare.

Non è in cima alla lista delle priorità rispetto a tutte le nuove "caratteristiche" che il marketing sta usando per vendere questi dispositivi di fascia consumer ed è una caratteristica che la maggior parte delle persone non esperte di tecnologia non hanno idea, quindi in fondo alla lista delle priorità va fino al punto che a meno che un grande pool di proprietari non si lamenti, viene escluso da eventuali aggiornamenti di revisione.

Se vuoi un dispositivo che lo supporti, fai la dovuta diligenza nella tua ricerca e otterrai un dispositivo che lo supporta, oppure se riesci a trovare un dispositivo nuovo o usato che supporti qualcosa come OpenWrt o Tomato di Polarcloud, puoi essere sicuro di ottenere ciò di cui hai bisogno.

In bocca al lupo. :)