It's usually due to bugs in the Wi-Fi home gateway routers (APs), or sometimes in the wireless client chipsets/drivers/software.
On Wi-Fi, sending multicasts from the AP to the wireless clients
(this is known in the standard as "From the Distribution System" or
"FromDS") is tricky, so there are lots of ways it can fail, and it's
easy to introduce bugs.
- Even though the radio medium is unreliable enough that 802.11
unicasts are required to have link-level acknowledgements (ACKs) and get
retransmitted several times if there's no ACK, FromDS multicasts are
never ACKed because they'd need to be ACKed by all the wireless clients
of the AP, which could be quite an "ACK storm". So instead, FromDS
multicasts have to be sent at a low data rate; using a simpler, slower,
easy-to-decode-even-at-low-signal-to-noise-ratios modulation scheme,
that can hopefully be received reliably by all the clients of the AP.
Some APs let the administrator set the multicast rate, and some
administrators unwittingly set it too high for some of their clients to
receive reliably, breaking multicast delivery to those clients.
- When WPA (TKIP) or WPA2 (AES-CCMP) encryption is in use, FromDS
multicasts have to be encrypted with a separate encryption key that is
known to all of the clients (this is called the Group Key).
- When a client leaves the network, or every hour or so, just for good
measure, the Group Key needs to be changed so that the client that left
no longer has access to decrypt the multicasts. This "Group Key
Rotation" process sometimes has problems. If a client doesn't
acknowledge receipt of the new group key, the AP is supposed to
de-authenticate that client, but if it fails to do that due to a bug, a
client could have the wrong group key and thus be "deaf" to multicasts
without realizing it.
- When WPA2 "mixed mode" is enabled (that is, when both WPA and WPA2
are enabled at the same time), the FromDS multicasts typically have to
be encoded with the TKIP cipher, so that all clients are guaranteed to
know how to decode it.
- FromDS multicasts have to be queued up by the AP and only
transmitted at times when all clients who care about multicasts can be
expected to have their receivers powered on. The time between the "safe
to transmit FromDS multicasts" periods is called the "DTIM interval". If
the AP or clients screw up their DTIM interval handling, it could
result in clients unable to receive multicasts reliably.
- Some APs have features to keep wireless clients from being able to
talk directly to each other, to maybe keep your wireless guests from
hacking your other wireless guests. These features usually block
multicasts from WLAN devices to other WLAN devices, and could well be
implemented in a naive way that even blocks multicasts from LAN to WLAN.
The crazy thing is, "ToDS" multicasts are done just like ToDS
unicasts, and so they rarely break. And since ToDS multicasts (not
FromDS multicasts) are all that are needed when a wireless client gets a
DHCP lease and ARPs to find its default gateway, most clients are able
to get connected and surf the web, check email, etc. even when FromDS
multicasts are broken. So a lot of people don't realize they have
multicast problems on their network until they try to do things like
mDNS (a.k.a. IETF ZeroConf, Apple Bonjour, Avahi, etc.).
A couple other things to note, regarding wired to wireless multicast transmissions:
- Most LAN multicasts, such as mDNS, are done using special multicast
address ranges that are not meant to be routed across routers. Since
Wi-Fi-capable home gateways with NAT enabled count as routers, mDNS is
not meant to cross from WAN to [W]LAN. But it SHOULD work from LAN to
WLAN.
- Because multicasts on Wi-Fi have to be sent at a low data rate, they
take up a lot of airtime. So they're "expensive", and you don't want to
have too many of them. That's the opposite of how things work on wired
Ethernet, where multicasts are "less expensive" than sending separate
unicasts to each machine "tuning into a multicast video stream" for
example. Because of this, many Wi-Fi APs will do "IGMP Snooping" to
watch which machines are sending Internet Group Management Protocol
(IGMP) requests, expressing their desire to tune into a given multicast
stream. Wi-Fi APs that do IGMP Snooping won't automatically forward some
classes of multicasts onto the wireless network unless they see a
wireless client try to subscribe to that stream via IGMP. The documents
that describe how to do IGMP Snooping properly make it clear that
certain classes of low-bandwidth multicasts (mDNS fits in this category)
are supposed to always be forwarded even if no one has explicitly asked
for them via IGMP. However, I wouldn't be surprised if there are broken
IGMP Snooping implementations out there that absolutely never forward
any kind of multicast until it sees an IGMP request for it.
tl;dr: Bugs. Lots of opportunities for bugs. And
occasional poorly-designed features and configuration errors. Your best
defense is to buy high-quality APs from companies that care about making
sure multicasts work. Since Apple loves Bonjour (mDNS) so much, Apple's
APs are probably the most consistently excellent at passing multicasts
reliably, and Apple's Wi-Fi client devices are probably the most
consistently excellent at receiving multicasts reliably.
No comments:
Post a Comment