Mengapa beberapa router WiFi memblokir paket multicast dari kabel ke nirkabel?

Saya telah bekerja dengan puluhan router WiFi kelas konsumen, dan mereka benar-benar untung-untungan dengan ini, meskipun tampaknya semakin baik.

Contoh masalah:

1. Perangkat yang dapat ditemukan dengan mDNS terhubung ke router dengan kabel.
2. Perangkat lain yang terhubung ke router pada WiFi mencoba menemukan perangkat di langkah 1.
3. Paket dari perangkat pada WiFi tidak membuatnya ke perangkat kabel, atau jika ya, paket yang dikirim dari perangkat kabel tidak membuatnya ke perangkat nirkabel.

Banyak router memiliki pengaturan yang memungkinkan ini berfungsi.

Lihat http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 dan http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -dan-nirkabel-jaringan-on-actiontec / td-p / 461359 untuk contoh.

Apakah ada daftar yang tidak sesuai dengan ini? Apa penyebabnya? Hanya bug di router?

Biasanya karena bug di router gateway rumah Wi-Fi (AP), atau kadang-kadang di chipset / driver / perangkat lunak klien nirkabel.

Di Wi-Fi, mengirim multicast dari AP ke klien nirkabel (ini dikenal dalam standar sebagai "Dari Sistem Distribusi" atau "FromDS") rumit, sehingga ada banyak cara yang bisa gagal, dan mudah untuk memperkenalkan bug.

1. Meskipun media radio tidak dapat diandalkan sehingga 802.11 unicast diharuskan memiliki link-level acknowledgement (ACKs) dan dikirim kembali beberapa kali jika tidak ada ACK, FromDS multicast tidak pernah ACKed karena mereka perlu ACKed oleh semua klien nirkabel AP, yang bisa menjadi "badai ACK". Jadi alih-alih, FromDS multicast harus dikirim dengan kecepatan data rendah; menggunakan skema modulasi rasio yang lebih sederhana, lebih lambat, mudah didekodekan, bahkan pada sinyal rendah terhadap kebisingan, yang diharapkan dapat diterima secara andal oleh semua klien AP. Beberapa AP membiarkan administrator mengatur laju multicast, dan beberapa administrator tanpa sadar menetapkannya terlalu tinggi untuk diterima oleh beberapa klien mereka dengan andal, memutus pengiriman multicast ke klien tersebut.
2. Ketika enkripsi WPA (TKIP) atau WPA2 (AES-CCMP) sedang digunakan, FromDS multicast harus dienkripsi dengan kunci enkripsi terpisah yang diketahui oleh semua klien (ini disebut Kunci Grup).
3. Ketika klien meninggalkan jaringan, atau setiap jam, hanya untuk ukuran yang baik, Kunci Grup perlu diubah sehingga klien yang pergi tidak lagi memiliki akses untuk mendekripsi multicast. Proses "Rotasi Kunci Grup" ini terkadang memiliki masalah. Jika klien tidak mengakui penerimaan kunci grup baru, AP seharusnya membatalkan otentikasi klien itu, tetapi jika gagal melakukan itu karena bug, klien dapat memiliki kunci grup yang salah dan dengan demikian menjadi "tuli" "Untuk multicast tanpa menyadarinya.
4. Ketika "mode campuran" WPA2 diaktifkan (yaitu, ketika WPA dan WPA2 diaktifkan sekaligus), multicast FromDS biasanya harus dikodekan dengan cipher TKIP, sehingga semua klien dijamin tahu cara mendekode kodenya. .
5. FromDS multicast harus diantrikan oleh AP dan hanya ditransmisikan pada saat semua klien yang peduli tentang multicast dapat diharapkan memiliki penerima yang dinyalakan. Waktu antara periode "safe to transmit FromDS multicasts" disebut "interval DTIM". Jika AP atau klien mengacaukan penanganan interval DTIM mereka, itu dapat menyebabkan klien tidak dapat menerima multicast dengan andal.
6. Beberapa AP memiliki fitur untuk menjaga klien nirkabel agar tidak dapat berbicara langsung satu sama lain, untuk mencegah tamu nirkabel Anda meretas tamu nirkabel Anda yang lain. Fitur-fitur ini biasanya memblokir multicast dari perangkat WLAN ke perangkat WLAN lainnya, dan dapat diimplementasikan dengan cara naif yang bahkan memblokir multicast dari LAN ke WLAN.

Yang gila adalah, "ToDS" multicast dilakukan seperti halnya ToDS unicast, sehingga mereka jarang pecah. Dan karena multicast ToDS (bukan multicast FromDS) adalah semua yang diperlukan ketika klien nirkabel mendapatkan sewa DHCP dan ARP untuk menemukan gateway standarnya, sebagian besar klien dapat terhubung dan menjelajahi web, memeriksa email, dll. Bahkan ketika FromDS multicast rusak. Jadi banyak orang tidak menyadari bahwa mereka memiliki masalah multicast di jaringan mereka sampai mereka mencoba melakukan hal-hal seperti mDNS (alias IETF ZeroConf, Apple Bonjour, Avahi, dll.).

Beberapa hal lain yang perlu diperhatikan, mengenai transmisi multicast kabel ke nirkabel:

1. Sebagian besar multicast LAN, seperti mDNS, dilakukan menggunakan rentang alamat multicast khusus yang tidak dimaksudkan untuk dialihkan melalui router. Karena gateway rumah berkemampuan Wi-Fi dengan NAT yang diaktifkan dihitung sebagai router, mDNS tidak dimaksudkan untuk berpindah dari WAN ke LAN [W]. Tapi itu HARUS bekerja dari LAN ke WLAN.
2. Karena multicast pada Wi-Fi harus dikirim dengan kecepatan data yang rendah, mereka membutuhkan banyak airtime. Jadi harganya "mahal", dan Anda tidak ingin memiliki terlalu banyak. Itu kebalikan dari cara kerja pada kabel Ethernet, di mana multicast "lebih murah" daripada mengirim unicast terpisah untuk setiap mesin "tuning ke aliran video multicast" misalnya. Karena itu, banyak Wi-Fi AP akan melakukan "IGMP Snooping" untuk menonton mesin mana yang mengirim permintaan Protokol Manajemen Kelompok Internet (IGMP), yang menyatakan keinginan mereka untuk menyesuaikan dengan aliran multicast yang diberikan. Wi-Fi AP yang melakukan IGMP Snooping tidak akan secara otomatis meneruskan beberapa kelas multicast ke jaringan nirkabel kecuali mereka melihat klien nirkabel mencoba berlangganan aliran itu melalui IGMP. Dokumen-dokumen yang menggambarkan bagaimana melakukan IGMP Snooping dengan benar memperjelas bahwa kelas-kelas tertentu dari multicast bandwidth rendah (mDNS cocok dalam kategori ini) seharusnya selalu diteruskan bahkan jika tidak ada yang secara eksplisit meminta mereka melalui IGMP. Namun, saya tidak akan terkejut jika ada implementasi IGMP yang mengintip di luar sana yang sama sekali tidak pernah meneruskan segala jenis multicast sampai ia melihat permintaan IGMP untuk itu.

tl; dr: Bugs. Banyak peluang untuk bug. Dan sesekali fitur yang dirancang buruk dan kesalahan konfigurasi. Pertahanan terbaik Anda adalah membeli AP berkualitas tinggi dari perusahaan yang peduli untuk memastikan multicast bekerja. Karena Apple sangat mencintai Bonjour (mDNS), AP Apple mungkin adalah yang paling baik secara konsisten dalam melewati multicast secara andal, dan perangkat klien Wi-Fi Apple mungkin yang paling konsisten baik dalam menerima multicast dengan andal.

@Spiff membuat beberapa poin luar biasa dalam jawabannya dan saya tidak akan mengulangi di sini. Tetapi ada beberapa jawaban dan alternatif lain untuk mengatasi masalah ini.

Jawaban singkat? Saya tidak berpikir mereka selalu "memblokir" sebanyak mereka hanya "tidak melakukannya atau memulai dengan" karena kemalasan insinyur menciptakan perangkat tertentu. Beberapa tidak memilikinya sebagai prioritas tinggi, dan beberapa hanya tidak punya waktu untuk membuatnya bekerja.

Itu tidak tinggi pada daftar prioritas dibandingkan dengan semua "fitur" pemasaran baru gunakan untuk menjual perangkat kelas konsumen ini dan itu adalah fitur yang kebanyakan orang yang mengerti teknologi tidak tahu tentang, jadi turun daftar prioritas itu berjalan sampai pada titik yang kecuali sekelompok besar pemilik mengeluh tentang hal itu, itu akan dibiarkan keluar dari pembaruan revisi.

Jika Anda menginginkan perangkat yang mendukungnya, lakukan uji tuntas pada penelitian Anda dan Anda akan mendapatkan perangkat yang mendukungnya, atau jika Anda dapat menemukan perangkat baru atau bekas yang mendukung sesuatu seperti OpenWrt atau Tomat dari Polarcloud, Anda bisa menjadi yakin mendapatkan apa yang Anda butuhkan.

Semoga berhasil. :)