Bad IPv6 route in dumb AP causing issues

I am running latest master as dumb AP. I created a DHCPv6 interface so I can configure my AP over IPv6. However, this created a weird route for the gateway on the lo interface:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
fd00:0001:0:1::/64                          ::                                      U     256    1        0 lanbridge
fd00:0001:0:1::/64                          ::                                      !n    2147483647 1        0 lo
fd00:0001:0:1::/128                         ::                                      Un    0      3        0 lanbridge

The second entry is unexpected and causes issues, as the AP now responds to neighbor solicitation requests for that IP address, which is my gateway. Now clients won't contact the gateway but instead try to reach one of my APs. The only solution I found so far is disabling IPv6 entirely. Why is this happening and how can I prevent that behavior? The AP shouldn't respond to any "foreign" solicit requests IMO.

Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have

ubus call system board; \
uci export network; \
uci export dhcp; uci export firewall; \
ip -6 addr ; ip -6 ro li tab all ; ip -6 ru; \
ls -l  /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/* ; head -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*
1 Like

I've done additional information and somehow a ubus call is made to send a request to netifd, which then inserts the route. A minimal example call to show the issue is this one:

ubus call network.interface notify_proto '{ "action": 0, "link-up": true, "data": { "passthru": "00170010fd001902000000010000000000000000" }, "keep": false, "ip6addr": [ { "ipaddr": "fd00:0000:0:123:ff00:1234:1234:1234", "mask": "128", "preferred": 4500, "valid": 7200, "offlink": true }, { "ipaddr": "fd00:0000:0:123:1234:1234:1234:1234", "mask": "64", "preferred": 14398, "valid": 86398, "offlink": true } ], "interface": "lan6" }'

The culprit appears to be the second ipaddr here. I have no clue where it's coming from though, the first address is the one coming from dhcpv6.

I guess we'll find out when you post the requested information.

The information is not at all required, just a deep understanding of how openWRT does the network configuration: Apparently that address is configured by SLAAC, and the "fix" for my issue is the same as mentioned in Cascading routers, dhcpv6 and unwanted EUI64 w/SLAAC on wan6 - #8 by rwberger