I use a OpenWRT 18.06.1 on an TP-Link Archer C7 v2 as a Bridge and Switch (no WAN involved) and a different router with IPTV which requires IGMP v3. The network has the gateway (192.168.2.1) -> switch with IGMP snooping. One Switchport has the IPTV receiver, one port a PC and a third port the OpenWRT device (98:de:d0:3c:xx:xx).
The multicast traffic is forwarded by the switch only to the subscribed ports. As I want to use the IPTV also behind the OpenWRT WIFI device I need ICMP snooping to work so it only forwards the multicast to the different LAN/Radio interfaces on demand.
The main issue is that when I enable IGMP snooping on the lan bridging interface the OpenWRT device starts sending IGMP v2 membership queries. This causes the devices on the network to fall back from IGMP v3 to v2 and consequently breaking the IPTV. This can only be stopped by disabling IGMP snooping on the bridge and rebooting the OpenWRT device.
Why is the OpenWRT device using v2 only? I tried the force_igmp_version sysctl but it still uses v2.
14:49:02.104085 98:de:d0:3c:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 0.0.0.0 > 126.96.36.199: igmp query v2
14:49:07.065194 98:de:d0:3c:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 0.0.0.0 > 188.8.131.52: igmp query v2
14:49:08.956295 6c:f0:49:b9:xx:xx > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.2.7 > 184.108.40.206: igmp v2 report 220.127.116.11
14:49:13.644033 cc:ce:1e:8a:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 192.168.2.1 > 18.104.22.168: igmp query v3
after disabling the igmp snooping and rebooting the OpenWRT device the v3 can be used again
15:28:13.677127 cc:ce:1e:8a:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 192.168.2.1 > 22.214.171.124: igmp query v3
15:28:23.089349 6c:f0:49:b9:xx:xx > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54: 192.168.2.7 > 126.96.36.199: igmp v3 report, 1 group record(s)
Is there any way to get the IGMP snooping to work correctly? The alternative would require separate switches and treat the OpenWRT device a cable without any intelligence
Did you enable IGMPv3?
# in /etc/config/network
option name 'switch0'
option reset '1'
option enable_vlan '1'
option igmp_v3 '1'
hmm nice option and no clue why that would not be default these days
but setting that does not change the IGMP version anyhow
tried that on a TL-WDR3600, even upgraded to 18.06.2 but still no change
23:06:26.670907 c0:4a:00:6c:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 0.0.0.0 > 188.8.131.52: igmp query v2
23:06:58.291183 c0:4a:00:6c:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 0.0.0.0 > 184.108.40.206: igmp query v2
23:09:06.292674 c0:4a:00:6c:xx:xx > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 0.0.0.0 > 220.127.116.11: igmp query v2
What software is sending out those queries?
those queries start from the OpenWRT device after enabling igmp snooping on the lan bridge, no clue what OpenWRT component generates these queries
the c0:4a:00:6c:xx:xx device was direct and only connect to a pc
The bridge itself will act as a querier if you enable that. and it may not be able to be a v3 querier. You can disable querying in the bridge.
echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_querier
This will still do snooping but not send queries. If your other switch does querying it will take over the query role and use v3.
yes that silences the bridge from sending these v2 queries. :slight_smile
According to netifd there should also be an option multicast_querier which needs to be turned off when using igmp_snooping in my case. See https://git.openwrt.org/?p=project/netifd.git;a=commit;h=ef4b8c8446b5f164a310a3955e90f7ffd59e2a59 it is turned on for compatibility together with igmp_snooping. (Maybe it would be better to turn it off by default like the kernel did in version 3.5 or at least use v3 be default)
uci set network.lan.multicast_querier=0
uci commit network
Did the trick so far. I will test this on the weekend to see how IPTV (MagentaTV from German Telekom) with SSM handles this now.
Hi just a final update
Forcing the multicast_querier=0 fixes the issue and the IPTV stays stable.
I as I wanted to igmp snoop between the switch ports I changed the internal switch to vlan tag every switchport to a tagged vlan on the cpu port and untagged on the lan port. As well as adding all the cpu vlan ports to the lan bridge.
Just make sure to change everything before hitting apply/commit.
I think some switch chips do snooping in the switch. You should find out before going this route, as your route will be much higher CPU overhead. If you're connecting video cameras or something so that moderate levels of multicast are the main thing connected to this device then your strategy is probably fine. But if you're hooking up to a 200+Mbps WAN this situation will be a lot of CPU overhead.
Resurrecting this ancient thread to say "thank you this solved my problem," and to share in case it helps anyone else (since Google led me here).
I have a Synology RT2600ac as gateway, router, and primary access point, and I'm using an old Archer C7 with OpenWRT as a wireless range extender in WDS client mode.
Getting the two devices to cooperate on Wi-Fi has been relatively smooth except for multicast. Google Home devices were able to maintain their internet connections, but casting was always hit-or-miss; often you'd only see the devices that were connected to the other AP. I tried every combination of IGMP snooping settings I could think of without success.
This is what worked, in tandem with the Synology router configured with IGMP snooping enabled and IGMP version 3:
uci set network.lan.igmp_snooping=1
uci set network.lan.igmp_v3=1
uci set network.lan.multicast_querier=0
uci commit network
This seems to have fixed everything; every Windows, iOS, and Android device can now consistently see every Google Home device in every part of the house. THANK YOU!
Thank you so much, this helped me getting more network performance with my IOT devices (see State of Archer C7 v2 in mid-2020 )
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.