Option igmp_snooping '1' and ipv6 problems

In debugging my previous issues: (Solved) Flaky wifi with WRT1900ACS v2 and Android phones

I discovered that one symptom is that my android phone connects, gets an ipv4 address only, and then say 60 seconds later receives an RA packet and suddenly has ipv6 connectivity, at which point it immediately within a second or so drops the connection and reconnects.

It seems that this was caused by recent changes I tried to make to improve the performance of LAN games that use multicast for my kids. In particular I enabled igmp_snooping in /etc/config/network.

I thought it was only a problem with my WRT1900ACS because I had this setting also in my TP-Link wdr3600 devices and they seemed to work fine. This morning when I woke up I'd left my WRT1900 turned off all night, and the phone was exhibiting the same problem connecting to the WDR3600's

Commenting out the igmp_snooping line from all 3 aps and rebooting immediately made it so that as soon as my android phone connected it would get ipv6 addresses (within a second or so, instead of waiting for the every 60 seconds RA).

In the past, kernel versions around 3.x this was described as a problem in multiple online forums, for example https://askubuntu.com/questions/724859/where-to-put-configuration-to-turn-off-multicast-snooping-on-bridges

My impression was that this bug was fixed in mid 3.x series and that the 4.9 of LEDE 14.1.04 which I'm running shouldn't have the bug, but evidently the symptoms are pretty much the same.

Anyone know anything about this?

I own a similar router, have IPv6 connectivity, and a couple of Android phones around here... will do a couple of tests tonight.

Thanks. as I say it's not entirely consistent. My Android phone runs 7.0 if that matters. It seems to me based on some light tcpdumping that the ipv6 multicast packets don't pass through consistently. It's quite possible that there's an initial transient where the kernel has to learn who is around wanting ipv6 multicast, so perhaps if a device gets connected and stays connected long enough... things are fine. For example my laptops don't have a problem. This is probably because a delay in getting an ipv6 address and a little light flakiness initially doesn't cause my laptop to abandon the connection. Android with its aggressive attempt to disconnect from APs that don't give it precious precious internet connectivity might be interacting with the multicast snooping in such a way that Android refuses to believe that the connection is ok and just won't stay connected.

It also might be interacting with EAPOL ? I'm running enterprise WPA2 with a RADIUS server.

In any case, turning off igmp_snooping this morning an hour ago made it so that I haven't had this problem at all this morning. I'll update here if it returns throughout the day.

btw the symptom can be seen by going to the wifi settings in android, connecting to the desired SSID, then immediately opening the advanced wifi info. You'll see that an ipv4 address is acquired, and a link local ipv6 address, but no other ipv6... some time later regular IPv6 addresses will show up, and within seconds of that the wifi connection will drop. Strangely I sometimes get just ipv6 and no ipv4 ... that may have to do with when I connect immediately before a periodic RA packet arrives.

Sorry, but I could not reproduce this issue: added igmp_snooping option to my LAN network, then restarted the network, and tried to connect using my Android phone: it acquired both a IPv4 and a IPv6 address immediately, and kept the connection up.

1 Like

Is your device acting as a dumb AP? Or is it the device responsible for advertising RA etc?

In my network the router is a different machine, and has switches between it and the AP where this is problematic.

No, I just used a single router in this test.

When I turned this option on, the modem kept restarting
I have been in this condition for quite a long time

Please fix this error

Xiaomi r3g v1 OpenWrt SNAPSHOT r13573-03a0b7b7e5