Wi fi multicast blocking

[edit] Introduction

This section explains how to use the DD-WRT GUI to configure DD-WRT supporting multicast IPTV traffic while at the same time enable some LAN ports and Wireless Clients working in parallel.

There are 2 ways to achieve this. The first is to unbridge the LAN area that shouldnt get flooded with mulicast packets. The second (and imho more elegand) way is to block mulicast traffic to the interfaces which doesnt need it.

[edit] Setup (Updated)

1. In wireless, basic settings: enable «optimize multicast traffic» for all wireless radios, save and apply
2. In Setup, networking, bridging, enable IGMP Snooping by selecting yes from the drop down menu under IGMP Snooping, save then apply
3. Connect IPTV box using LAN cable to one of the LAN ports of the router
   • Note: in AP mode, LAN cable to gateway/modem and LAN cable to IPTV box must be on the switch ports of the dd-wrt router and not on the WAN port, even if «assign WAN port to switch» is enabled.

Tested on Linksys EA2700 (build 38581), Netgear R7000, Netgear R7000P. ARM Kong builds 35550M and 38580M. Do not consider these build recommendations. They are only listed here to note when the above instructions were created.

[edit] Assumption (Old Instructions)

In the sample configuration, the TV media receiver is connected to LAN Port 4, and the router Ip is 192.168.1.1. Other configurations work accordingly.

[edit] Prerequisites

1. Ensure that you are at least on DD-WRT 24v1 Firmware, otherwise download the most recent release.
2. Connect the TV media receiver to Port 4. Connect other LAN connections to Ports 1,2,3

[edit] Allow for multicast traffic

[edit] Disable multicast traffic to reach the Wireless adapter

1. In Wireless—>Basic setting, set «Network Configuration» to «Unbridged», and «Multicast forwarding» to «disabled».
2. Provide 192.168.3.1 with subnet mask 255.255.255.0 as the IP address for Wireless connections

[edit] Setup an additional VLAN

1. In Setup—>VLANs, check the «tagged» checkboxes for Ports 1,2,3. Then, check the three accoring checkboxes in the VLAN 7 row, uncheck them in the VLAN 0 row, and finally uncheck the «tagged» checkboxes.
2. Apply the settings and reboot the router

[edit] Disable multicast traffic to reach the LAN Ports 1,2,3

1. In Setup—>Networking, check «Unbridged» for «Network Configuration vlan7», «Multicast forward» to «disable».
2. Below this entry, provide IP number 192.168.2.1 with subnet mask 255.255.255.0 as the IP address

[edit] Enable DHCP for the additional local Networks and final steps

1. In Setup—>Networking, add two DHCP Servers in the bottom area, one for vlan7, one for eth1 (keep the standard settign for the other fields)
2. Apply all changes, and reboot the router

[edit] Block Multicast via Ebtables Firewall

Leave the wifi brdiged. Load the layer2 firewall modules and your ebtables rules via the firewall startup

insmod ebtables insmod ebtable_filter insmod ebt_pkttype ebtables -A FORWARD -o "interface to block" --pkttype-type multicast -j DROP ebtables -A OUTPUT -o "interface to block" --pkttype-type multicast -j DROP

If you want this script to run everytime your router starts, do the following:

• Go to Administration->Commands
• Paste commands in the Commands window
• Click Save startup

The drawback is ebtables will use sightly mode cpu time. Finally, enjoy TV, LAN, and Wireless simultaneously.

Источник

[edit] Introduction

This section explains how to use the DD-WRT GUI to configure DD-WRT supporting multicast IPTV traffic while at the same time enable some LAN ports and Wireless Clients working in parallel.

There are 2 ways to achieve this. The first is to unbridge the LAN area that shouldnt get flooded with mulicast packets. The second (and imho more elegand) way is to block mulicast traffic to the interfaces which doesnt need it.

[edit] Setup (Updated)

1. In wireless, basic settings: enable «optimize multicast traffic» for all wireless radios, save and apply
2. In Setup, networking, bridging, enable IGMP Snooping by selecting yes from the drop down menu under IGMP Snooping, save then apply
3. Connect IPTV box using LAN cable to one of the LAN ports of the router
   • Note: in AP mode, LAN cable to gateway/modem and LAN cable to IPTV box must be on the switch ports of the dd-wrt router and not on the WAN port, even if «assign WAN port to switch» is enabled.

Tested on Linksys EA2700 (build 38581), Netgear R7000, Netgear R7000P. ARM Kong builds 35550M and 38580M. Do not consider these build recommendations. They are only listed here to note when the above instructions were created.

[edit] Assumption (Old Instructions)

In the sample configuration, the TV media receiver is connected to LAN Port 4, and the router Ip is 192.168.1.1. Other configurations work accordingly.

[edit] Prerequisites

1. Ensure that you are at least on DD-WRT 24v1 Firmware, otherwise download the most recent release.
2. Connect the TV media receiver to Port 4. Connect other LAN connections to Ports 1,2,3

[edit] Allow for multicast traffic

[edit] Disable multicast traffic to reach the Wireless adapter

1. In Wireless—>Basic setting, set «Network Configuration» to «Unbridged», and «Multicast forwarding» to «disabled».
2. Provide 192.168.3.1 with subnet mask 255.255.255.0 as the IP address for Wireless connections

[edit] Setup an additional VLAN

1. In Setup—>VLANs, check the «tagged» checkboxes for Ports 1,2,3. Then, check the three accoring checkboxes in the VLAN 7 row, uncheck them in the VLAN 0 row, and finally uncheck the «tagged» checkboxes.
2. Apply the settings and reboot the router

[edit] Disable multicast traffic to reach the LAN Ports 1,2,3

1. In Setup—>Networking, check «Unbridged» for «Network Configuration vlan7», «Multicast forward» to «disable».
2. Below this entry, provide IP number 192.168.2.1 with subnet mask 255.255.255.0 as the IP address

[edit] Enable DHCP for the additional local Networks and final steps

1. In Setup—>Networking, add two DHCP Servers in the bottom area, one for vlan7, one for eth1 (keep the standard settign for the other fields)
2. Apply all changes, and reboot the router

[edit] Block Multicast via Ebtables Firewall

Leave the wifi brdiged. Load the layer2 firewall modules and your ebtables rules via the firewall startup

insmod ebtables insmod ebtable_filter insmod ebt_pkttype ebtables -A FORWARD -o "interface to block" --pkttype-type multicast -j DROP ebtables -A OUTPUT -o "interface to block" --pkttype-type multicast -j DROP

If you want this script to run everytime your router starts, do the following:

• Go to Administration->Commands
• Paste commands in the Commands window
• Click Save startup

The drawback is ebtables will use sightly mode cpu time. Finally, enjoy TV, LAN, and Wireless simultaneously.

Источник

Why do some WiFi routers block multicast packets going from wired to wireless?

Is there a list anywhere of incompatibility with this? What is the cause? Just a bug in the router?

2 Answers 2

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.

1. 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.
2. 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).
3. 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.
4. 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.
5. 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.
6. 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:

1. 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.
2. 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.

Источник