IPv6 issues - broken multicast snooping on EAP653 standalone?
Most of the time when my PC wakes up from sleep and rejoins my Wi-Fi network, I find I have lost all IPv6 connectivity. My router shows it is soliciting for my IPv6 address, these ND packets are received by the EAP653, but they never make it to my PC nor does the EAP653 answer on behalf of my device. You can see from the following tcpdump that my device discovered the router's MAC address and can send traffic (ping), but the router has no idea how to send replies back as the AP isn't passing the ND packets.
14:31:03.828960 54:60:09:1f:f5:4c > bc:24:11:43:52:b2, ethertype IPv6 (0x86dd), length 78: fe80::5660:9ff:fe1f:f54c > fe80::be24:11ff:fe43:52b2: ICMP6, neighbor advertisement, tgt is fe80::5660:9ff:fe1f:f54c, length 24
14:31:04.544561 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
14:31:05.594557 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
14:31:07.198205 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
14:31:08.224516 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
14:31:08.488860 14:f6:d8:66:e7:4d > bc:24:11:43:52:b2, ethertype IPv6 (0x86dd), length 94: 2a02:a467:1896:0::xxxx > 2001:41d0:20b:b400:ef4b:113e:1469:840: ICMP6, echo request, id 1, seq 1538, length 40
14:31:09.264455 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
14:31:11.197835 bc:24:11:43:52:b2 > 33:33:ff:be:01:40, ethertype IPv6 (0x86dd), length 86: fe80::be24:11ff:fe43:52b2 > ff02::1:ffbe:140: ICMP6, neighbor solicitation, who has 2a02:a467:1896:0::xxxx, length 32
However if I change the source IPv6 address to my "permanent" address instead of one of the Windows-generated temporary addresses (IPv6 privacy extensions), the connectivity works fine. So it appears the AP is remembering my permanent address but losing track of the temporary IPv6 addresses that Windows generates. Unfortunately due to the firmware change to lock users out of their own devices, I cannot run any diagnostics on the AP itself any more to get any more information.
The EAP653 runs in standalone mode (just a home AP), so I don't know what kind of multicast-to-unicast conversion defaults are, but something seems very broken with how it's registering clients for IPv6 ND / multicast. If I manually restart my Wi-Fi connection, Windows sends a new MLD report which seems to trigger the AP to start behaving properly. Perhaps there are issues immediately updating the MLD table after the client is initially connected? Is there a way to configure MLD snooping at all on the standalone EAP or play with multicast to unicast conversion? Is anyone else seeing issues like this on a standalone setup?
