IPv6 in Access Point Mode (Flint 2) illegal ND from ::1

kerrnel · January 14, 2026, 3:44am

TL;DR - When Flint 2 is plugged in and configured as an Access Point in IPv6 + IPv4 environment like a home LAN:

There is no way to specify any IPv6 settings, which is probably fine, as in AP mode, it moves IPv6 packets fine between interfaces.
The Router begins sending illegal neighbor discovery messages, with targets that seem to be in Google, Amazon & Facebook ranges, but whose source address is ::1 ; presumably because there is no IPv6 stack built up to do SAS (send from the correct IPv6 assigned address).

Most devices silently drop these packets as illegal. Firewalls often contain block all in from ::1 ; since sending anywhere but to ::1 from ::1 is illegal in IPv6. In that way, ::1 is not like 127.0.0.1 in IPv4. At a minimum the br-lan would in IPv6 mode (which per #1, can not turn on), assign itself an fe80: address to be LANv6 “present” if it wanted to do ND.

I only noticed this because in our LAN are some NetBSD machines who begin every ~10 seconds flooding their dmesg with lines of the form:

[ 20110.421029] in6_setscope: can't set scope for not loopback interface re1 and loopback address ::1
[ 20110.421029] in6_setscope: can't set scope for not loopback interface re1 and loopback address ::1
[ 20120.661206] in6_setscope: can't set scope for not loopback interface re1 and loopback address

Which is basically complaining that a src of ::1 not match the “scope” (i.e. can not hop through) an ethernet device; which it is not allowed.

My guess is the fix is an IPv6 option (or default on, probably harmless) on br-lan with an assigned fe80: and/or turning off whatever service is causing the Neighbor Discovery to happen.

I will paste some technical analysis info below. I’m sure you don’t consider this a “P1” issue, but it may be the symptom of other problems I have not mentioned.

Thanks,
Greg

tcpdump capturing the guilty packets

16:33:58.577105 IP6 ::1 > 2620:149:a16:2000::521: ICMP6, neighbor solicitation, who has 2620:149:a16:2000::521, length 32

16:33:58.577141 IP6 ::1 > 2607:f8b0:4004:c06::bc: ICMP6, neighbor solicitation, who has 2607:f8b0:4004:c06::bc, length 32

16:33:58.577177 IP6 ::1 > 2607:f8b0:4002:c06::bc: ICMP6, neighbor solicitation, who has 2607:f8b0:4002:c06::bc, length 32

16:33:58.577213 IP6 ::1 > 2001:4860:4802:34::223: ICMP6, neighbor solicitation, who has 2001:4860:4802:34::223, length 32

16:33:58.577248 IP6 ::1 > 2001:4860:4802:36::223: ICMP6, neighbor solicitation, who has 2001:4860:4802:36::223, length 32

16:33:58.577285 IP6 ::1 > 2a03:2880:f203:c6:face:b00c:0:7260: ICMP6, neighbor solicitation, who has 2a03:2880:f203:c6:face:b00c:0:7260, length 32

Here you can see your MAC address (the Flint 2 br-lan MAC)

**
sudo tcpdump -ni re1 icmp6 and 'icmp6[0] == 135' -vv**

      0x0000:  9483 c4a7 2e24

16:47:06.960183 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) ::1 > 2603:6081:8100:324e:5207:c3ff:fe99:d252: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2603:6081:8100:324e:5207:c3ff:fe99:d252

      source link-address option (1), length 8 (1): 94:83:c4:a7:2e:24

        0x0000:  9483 c4a7 2e24

16:47:06.960219 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) ::1 > 2603:6081:8100:324e:b197:f9b9:e73:e990: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2603:6081:8100:324e:b197:f9b9:e73:e990

      source link-address option (1), length 8 (1): 94:83:c4:a7:2e:24

        0x0000:  9483 c4a7 2e24

16:47:06.960256 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) ::1 > 2603:6081:8100:324e:c4af:d43b:f511:a20a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2603:6081:8100:324e:c4af:d43b:f511:a20a

      source link-address option (1), length 8 (1): 94:83:c4:a7:2e:24

… repeats ad nauseam

OpenWrt 24.10.4, r28959-29397011cc

root@airport:~# ifconfig br-lan
br-lan Link encap:Ethernet HWaddr 94:83:C4:A7:2E:24
inet addr:10.6.6.5 Bcast:10.6.6.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37971 errors:0 dropped:1584 overruns:0 frame:0
TX packets:14808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3833088 (3.6 MiB) TX bytes:1855108 (1.7 MiB)

root@airport:~#

will.qiu · January 14, 2026, 7:27am

Hi

Please try switching back to Router Mode and enabling IPv6, then switch back to AP Mode to see if this resolves the issue for you.

kerrnel · January 14, 2026, 6:58pm

I think this seems to quash the issue:

root@airport:~# ip addr del ::1 dev lo
root@airport:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:22 brd ff:ff:ff:ff:ff:ff
4: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
5: lan3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
6: lan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
7: lan5@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
8: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 94:83:c4:a7:2e:24 brd ff:ff:ff:ff:ff:ff
inet 10.6.6.5/24 brd 10.6.6.255 scope global br-lan
valid_lft forever preferred_lft forever
10: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 32:8b:eb:23:36:c4 brd ff:ff:ff:ff:ff:ff permaddr 94:83:c4:a7:2e:25
11: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether 4e:b8:60:76:da:89 brd ff:ff:ff:ff:ff:ff permaddr 94:83:c4:a7:2e:26

When ipv6 is disabled, it should also be disabled on lo to be complete. That stops the “storm” in my dmesg logs and is probably the easiest solution.

kerrnel · January 14, 2026, 7:00pm

Via SSH:

First I tried updating to the dd-wrt 24 based release, but no change.

I enabled ipv6 - but it does not stay enabled. Some script bumps it back every 10 seconds or so in AP Mode.

I tried

sysctl disable_ipv6=1/disable_ipv6=0
sysctl net.ipv6.conf.br-lan.disable_ipv6=0
ifup lan6

I tried

sed -i 's/disable_ipv6=1/disable_ipv6=0/g' /etc/sysctl.d/99-disable-ipv6.conf
echo "net.ipv6.conf.br-lan.disable_ipv6=0" >> /etc/sysctl.d/99-disable-ipv6.conf

Which for a while (it did not stay long, some process set them back to 1), worked to assign fe80:: addresses to br-lan and other devices.

root@airport:~# ifconfig br-lan
br-lan    Link encap:Ethernet  HWaddr 94:83:C4:A7:2E:24
          inet addr:10.6.6.5  Bcast:10.6.6.255  Mask:255.255.255.0
          inet6 addr: fe80::9683:c4ff:fea7:2e24/64 Scope:Link

This didn’t’ seem to produce the “correct” outcome as br-lan, lanX and ethX all got the same fe80::9683:c4ff:fea7:2e24 address /64 assigned without a :: suffix.

It introduced a new problem at my gateway as now illegal packets from fe80:: on these devices were arriving at the gateway LAN interface and complaining every 10 seconds, but it was better than the ::1 storm.

It seemed very briefly someone did a router solicitation as br-lan flashed with proper (for my LAN) ipv6 numbers, but then all ipv6 were removed and the sysctl’s reset (by some script checking periodically I presume).

I can try the swtch to router, enable, and back as you suggest, but I think whatever killed my manually setting will also kill whatever remains from setting IPv6 in Router Mode.

Thank you for your attention,

Greg

will.qiu · January 15, 2026, 4:24am

We have conducted a preliminary local check. By enabling IPv6 in the Admin Panel as previously mentioned, the device no longer sends NS (Neighbor Solicitation) requests externally using the ::1 address. During our 10-minute test, it also did not switch back.

Regarding the ::1 issue, we have successfully reproduced it locally and will be investigating it further with our R&D team.

system · April 15, 2026, 4:25am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.