AP230 not respecting "Convert IP Multicast to Unicast" for RAs; no IPv6 default routes on Android

[interfect]

I have a problem very similar to "No IPV6 access on some clients(Android) with AP230". I have some AP230s running firmware 10.4.4.0. I have an Android client that is picking up IPv6 addresses from my router, but which is not getting a default route. It can talk to other IPv6 devices on the LAN, but without a default route, it can't access the IPv6 Internet.

I saw it suggested that the "Convert IP Multicast to Unicast" setting on the SSID, under "Additional Settings" and then the "Optional settings" "Customize" button, might be relevant here. I did a packet capture with my Windows machine and compared the IPv6 RA router advertisement packets received over Ethernet and over WiFi to the AP230, and the only difference in their content was that the advertisement frame received over Ethernet was addressed to what Wireshark called "IPv6mcast_01" (33:33:00:00:00:01), while the advertisement frame received over WiFi was addressed directly to the WiFi adapter's MAC.

So I went and turned off "Convert IP Multicast to Unicast" on all my SSIDs. I also turned off "Enable Non-Essential Broadcast Filtering", and turned off "IGMP Snooping" in the "Switching/Routing" section. I applied the config to the devices, and I also rebooted them for good measure.

But the "Convert IP Multicast to Unicast" setting of off is not respected by the APs, as far as I can tell, at least for router advertisements. When I capture an RA over WiFi from my Windows machine, I still see it as addressed to that machine's WiFi MAC. When I capture an RA via Ethernet, I correctly see it as addressed to the multicast group.

Does anybody know how to get the "Convert IP Multicast to Unicast" setting to actually turn off on these devices? How would I go about downgrading the firmware to an older version like 10.0r10b which is supposed to be the documented solution to the no-default-route-for-Android problem that @jackhsweeney1 had? Is there some *other* solution to Android not creating a default IPv6 route on an AP230 AP?

For reference, someone on StackOverflow had a similar problem with Android clients never getting an IPv6 default route, in a different environment, which they apparently fixed by throwing out their router and getting a different one.

[SamPirok]

Hi @interfect, thank you for keeping this thread updated with all your troubleshooting. I ran this past our IQE team and given the in-depth nature of the question here and how much work you've already done, they've asked if we can open a support ticket for this request, would that be possible? 

[interfect]

@SamPiroksorry for the delay; I'd be happy to have a support ticket open for this, and I can try to keep on top of it better than this thread. I don't actually pay you all for support though.

I think the problem a support ticket could solve is the "Convert IP Multicast to Unicast" setting being seemingly stuck on. That should be something you can reproduce on your end. The downstream effects that lead to that causing me problems are specific to my slightly broken client.

[interfect]

I did some deciphering of the cnss-daemon binary with Ghidra. It looks like it complains that the gateway MAC is "Invalid" if it is all 0s by the time it looks at it, and it starts out all 0s, and it only fills it in if certain conditions I couldn't figure out hold when it is parsing the messages it gets from the other Android components about what the advertisement was like. It might be trying to pull the MAC belonging to a link-local address and doing... something with it.

[interfect]

I've also pulled some logs from the offending Android device with adb logcat.

I noticed that it does get the router advertisement and set about setting up its IPv6 addresses and its routes, and I can see it adding routes and thinking about using a default route. But then there are 2 potential problems:

1. When it goes to actually add the default route, it gets:

05-27 17:36:17.185  1087  1087 E netd    : Error adding route ::/0 -> fe80::76ac:b9ff:fea0:37dc wlan0 to table 1026: File exists

This is supposed to mean that that exact route already is added. So maybe it's trying to add the route twice. But then it must be in at least once.

2. When it's thinking about default gateways, it produces:

05-27 17:36:18.401  1453  1453 I cnss-daemon: Ready to update GW parameters
05-27 17:36:18.401  1453  1453 E cnss-daemon: Invalid mac address
05-27 17:36:18.401  1453  1453 E cnss-daemon: failed to update gateway

This is nearly simultaneous with (possibly after?) starting to tear down all the routes. But it matches with what the problem seems to be, where the destination MAC address on the multicast router advertisement is not allowed to be the device's own MAC. (I also see it trying to remove the default route and complaining it is already removed.)

The "cnss-daemon" component here is part of Qualcomm's userspace machinery for the WiFi driver. So this might be a problem specifically for Android devices with (some) Qualcomm radios, caused by the Qualcomm proprietary WiFi userspace doing excessive validation of the RA frames and telling the device not to take a default route from them if it doesn't like the destination MAC.