Flint 3 - No IPv6 on LAN but working on WAN after rebooting ISP ONT

Router
1

Hello!

I recently bought a Flint 3, and it has been amazing so far. This is my first GL.iNet router, and I’m really enjoying it.

I am having one issue with IPv6. I am using Native mode, and it works fine in general, but it fails in one specific case:

If I restart the ISP ONT(bridge mode) where the fiber connection terminates, the Flint 3 itself still has working IPv6. I can ping from the Flint, services like AdGuard Home can resolve IPv6 addresses, and nslookup from LAN clients returns IPv6 records as well.

However, LAN devices themselves do not have working IPv6 connectivity until I restart the Flint 3. I created a small hotplug script that restarts wan6, and that fixes the issue, but I’m wondering if there is a cleaner or more permanent fix that does not rely on a hotplug script.

This IPv6 LAN issue does not happen when I restart the Flint 3. It only happens after rebooting the ISP ONT/router.

2 
#!/bin/sh

[ "$ACTION" = ifup -o "$ACTION" = ifdown -o "$ACTION" = ifupdate ] || exit 0
[ "$ACTION" = ifupdate -a -z "$IFUPDATE_ADDRESSES" -a -z "$IFUPDATE_DATA" -a -z "$IFUPDATE_PREFIXES" ] && exit 0

/etc/init.d/firewall enabled || exit 0

fw3 -q network "$INTERFACE" >/dev/null

logger -t firewall "Reloading firewall due to $ACTION of $INTERFACE ($DEVICE)"

if [ "$INTERFACE" = "wan6" ]; then
    (
        sleep 1
        fw3 -q reload

        if [ "$ACTION" = "ifup" ] && [ -e /tmp/wan6-renew-recovery-in-progress ] && [ ! -e /tmp/wan6-needs-renew-after-linkloss ]; then
            rm -f /tmp/wan6-renew-recovery-in-progress
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew

            logger -t wan6-renew-after-firewall "wan6 final ifup after recovery; restarting odhcpd for LAN RA"
            ubus call service restart '{"name":"odhcpd"}'
        fi

        if [ "$ACTION" = "ifdown" ] && [ -e /tmp/wan6-renew-recovery-in-progress ]; then
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew
            touch /tmp/wan6-needs-renew-after-linkloss

            logger -t wan6-renew-after-firewall "wan6 went down during renew recovery; re-arming first renew"
        fi

        if [ "$ACTION" = "ifup" ] && [ -e /tmp/wan6-needs-renew-after-linkloss ]; then
            rm -f /tmp/wan6-needs-renew-after-linkloss
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew
            touch /tmp/wan6-renew-recovery-in-progress
            touch /tmp/wan6-needs-second-renew-after-prefix-update

            logger -t wan6-renew-after-firewall "wan6 ifup after link loss; firewall reload done; forcing first netifd renew"
            ubus call network.interface.wan6 renew
        fi

        if [ "$ACTION" = "ifupdate" ] && [ "$IFUPDATE_PREFIXES" = "1" ] && [ -e /tmp/wan6-restart-odhcpd-after-second-renew ]; then
            if ifstatus wan6 2>/dev/null | grep -q '"ipv6-address"' && ifstatus wan6 2>/dev/null | grep -q '"ipv6-prefix"'; then
                rm -f /tmp/wan6-restart-odhcpd-after-second-renew
                rm -f /tmp/wan6-renew-recovery-in-progress

                logger -t wan6-renew-after-firewall "wan6 ifupdate after second renew; restarting odhcpd for LAN RA"
                ubus call service restart '{"name":"odhcpd"}'
            fi
        fi

        if [ "$ACTION" = "ifupdate" ] && [ "$IFUPDATE_PREFIXES" = "1" ] && [ -e /tmp/wan6-needs-second-renew-after-prefix-update ]; then
            if ifstatus wan6 2>/dev/null | grep -q '"ipv6-address"' && ifstatus wan6 2>/dev/null | grep -q '"ipv6-prefix"'; then
                rm -f /tmp/wan6-needs-second-renew-after-prefix-update
                touch /tmp/wan6-restart-odhcpd-after-second-renew

                logger -t wan6-renew-after-firewall "wan6 valid address and prefix after first renew; forcing second netifd renew"
                ubus call network.interface.wan6 renew
            else
                logger -t wan6-renew-after-firewall "wan6 prefix update seen but IPv6 data not ready; waiting for next ifupdate"
            fi
        fi
    ) &
else
    fw3 -q reload
fi

Final version here.

3

I think I found a cleaner workaroundfor the IPv6 LAN issue after an ONT restart:

After the ONT restarted, wan6 looked fine from OpenWrt:

ifstatus wan6

showed up: true, a valid IPv6 address, a delegated prefix, and LAN also received the delegated prefix correctly. However, IPv6 traffic from LAN clients to the internet did not work.

The strange part was that IPv6 from the router itself worked, but traffic sourced from the LAN delegated prefix did not. For example:

ping -6 -I eth0 2606:4700:4700::1111

worked, but:

ping -6 -I <br-lan IPv6 address> 2606:4700:4700::1111

failed after the ONT came back online.

A manual restart of wan6 fixed it:

ifdown wan6
ifup wan6

After testing, I found that the real fix is not to restart wan6, but to force DHCPv6-PD renewal through netifd after the interface and firewall/kmwan state have settled.

The command that fixes the issue manually is:

ubus call network.interface.wan6 renew

However, one renew immediately after ifup wan6 was not enough in my tests. The first renew triggers an ifupdate event with:

IFUPDATE_PREFIXES=1

Then a second renew after that prefix update fixes LAN IPv6 reliably.

So the working sequence is:

ONT goes down
→ wan6 teardown is detected
→ mark that wan6 needs DHCPv6-PD recovery

ONT comes back
→ wan6 ifup
→ kmwan adds wan6
→ firewall reloads for wan6 ifup
→ first netifd renew

first renew causes:
→ ifupdate wan6 with IFUPDATE_PREFIXES=1
→ firewall reloads again
→ second netifd renew

LAN IPv6 works again

The important detail is that /etc/hotplug.d/iface/20-firewall originally ignores ifupdate events that only contain prefix changes, because it only checks IFUPDATE_ADDRESSES and IFUPDATE_DATA. In this case the important event is IFUPDATE_PREFIXES=1, so that condition needs to include IFUPDATE_PREFIXES.

The changes I made were:

In /lib/netifd/proto/dhcpv6.sh, mark a real wan6 teardown:

proto_dhcpv6_teardown() {
        local interface="$1"

        if [ "$interface" = "wan6" ]; then
                touch /tmp/wan6-needs-renew-after-linkloss
                logger -t dhcpv6.sh "wan6 teardown marked; will force DHCPv6 renew after firewall and prefix update"
        fi

        proto_kill_command "$interface"
}

Then in /etc/hotplug.d/iface/20-firewall, allow prefix-only updates and run two staged renews:

#!/bin/sh

[ "$ACTION" = ifup -o "$ACTION" = ifdown -o "$ACTION" = ifupdate ] || exit 0
[ "$ACTION" = ifupdate -a -z "$IFUPDATE_ADDRESSES" -a -z "$IFUPDATE_DATA" -a -z "$IFUPDATE_PREFIXES" ] && exit 0

/etc/init.d/firewall enabled || exit 0

fw3 -q network "$INTERFACE" >/dev/null

logger -t firewall "Reloading firewall due to $ACTION of $INTERFACE ($DEVICE)"

if [ "$INTERFACE" = "wan6" ]; then
    (
        sleep 1
        fw3 -q reload

        if [ "$ACTION" = "ifup" ] && [ -e /tmp/wan6-renew-recovery-in-progress ] && [ ! -e /tmp/wan6-needs-renew-after-linkloss ]; then
            rm -f /tmp/wan6-renew-recovery-in-progress
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew

            logger -t wan6-renew-after-firewall "wan6 final ifup after recovery; restarting odhcpd for LAN RA"
            ubus call service restart '{"name":"odhcpd"}'
        fi

        if [ "$ACTION" = "ifdown" ] && [ -e /tmp/wan6-renew-recovery-in-progress ]; then
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew
            touch /tmp/wan6-needs-renew-after-linkloss

            logger -t wan6-renew-after-firewall "wan6 went down during renew recovery; re-arming first renew"
        fi

        if [ "$ACTION" = "ifup" ] && [ -e /tmp/wan6-needs-renew-after-linkloss ]; then
            rm -f /tmp/wan6-needs-renew-after-linkloss
            rm -f /tmp/wan6-needs-second-renew-after-prefix-update
            rm -f /tmp/wan6-restart-odhcpd-after-second-renew
            touch /tmp/wan6-renew-recovery-in-progress
            touch /tmp/wan6-needs-second-renew-after-prefix-update

            logger -t wan6-renew-after-firewall "wan6 ifup after link loss; firewall reload done; forcing first netifd renew"
            ubus call network.interface.wan6 renew
        fi

        if [ "$ACTION" = "ifupdate" ] && [ "$IFUPDATE_PREFIXES" = "1" ] && [ -e /tmp/wan6-restart-odhcpd-after-second-renew ]; then
            if ifstatus wan6 2>/dev/null | grep -q '"ipv6-address"' && ifstatus wan6 2>/dev/null | grep -q '"ipv6-prefix"'; then
                rm -f /tmp/wan6-restart-odhcpd-after-second-renew
                rm -f /tmp/wan6-renew-recovery-in-progress

                logger -t wan6-renew-after-firewall "wan6 ifupdate after second renew; restarting odhcpd for LAN RA"
                ubus call service restart '{"name":"odhcpd"}'
            fi
        fi

        if [ "$ACTION" = "ifupdate" ] && [ "$IFUPDATE_PREFIXES" = "1" ] && [ -e /tmp/wan6-needs-second-renew-after-prefix-update ]; then
            if ifstatus wan6 2>/dev/null | grep -q '"ipv6-address"' && ifstatus wan6 2>/dev/null | grep -q '"ipv6-prefix"'; then
                rm -f /tmp/wan6-needs-second-renew-after-prefix-update
                touch /tmp/wan6-restart-odhcpd-after-second-renew

                logger -t wan6-renew-after-firewall "wan6 valid address and prefix after first renew; forcing second netifd renew"
                ubus call network.interface.wan6 renew
            else
                logger -t wan6-renew-after-firewall "wan6 prefix update seen but IPv6 data not ready; waiting for next ifupdate"
            fi
        fi
    ) &
else
    fw3 -q reload
fi

I think the underlying bug is that after an ONT/link recovery, DHCPv6-PD appears valid locally, but the delegated prefix path is not fully restored for LAN traffic until netifd performs additional DHCPv6 renew handling after the prefix update event.

4

GL-BE9300 is running 4.9.0.

What I tried:

A simple odhcpd restart is not enough. A single:

ubus call network.interface.wan6 renew

also does not always fix it.

The reliable recovery sequence I found is:

1. wan6 comes back up after link loss
2. run: ubus call network.interface.wan6 renew
3. wait for ifupdate on wan6 with IFUPDATE_PREFIXES=1
4. confirm wan6 has both ipv6-address and ipv6-prefix
5. run a second: ubus call network.interface.wan6 renew
6. after the second ifupdate, restart odhcpd so LAN RA/DHCPv6 is refreshed

So it looks like after ONT/link recovery there is a race or stale state between odhcp6c, netifd, kmwan, firewall reload, and odhcpd. wan6 appears valid too early, but the delegated prefix is not fully usable for LAN traffic until a second DHCPv6 renew after the prefix update event.

It would be good if GL.iNet could fix this in firmware so that after wan6 link recovery, DHCPv6-PD and LAN RA are properly refreshed without requiring manual workarounds.

5

Hi

This seems a bit unusual.

The QSDK version of /etc/hotplug.d/iface/20-firewall does not appear to be significantly different from the one in vanilla OpenWrt:

Based on your description, is the issue you're experiencing the following?

  • After the ONT reboots, the DHCPv6 PD provided by the upstream ISP changes, and the old prefix is no longer valid.
  • However, the br-lan/LAN devices continue using the old delegated prefix, causing IPv6 connectivity to stop working.
  • You then need to either run ifdown wan6 && ifup wan6 or execute ubus call network.interface.wan6 renew twice to restore IPv6 connectivity.

We tested this locally using a Flint 3 running v4.9.0 in a simulated environment, but we were unable to reproduce the issue:

  1. Before the simulated ONT reboot:

    image
    image1092×125 4.6 KB

  2. During the simulated ONT reboot:

    image
    image1083×100 4.83 KB

    (The affected addresses are marked as Deprecated.)

  3. After the simulated ONT reboot, with a changed DHCPv6 PD:

    image
    image1085×151 6.11 KB

    (The old addresses are marked as Deprecated, while the new addresses become available.)

6

Hi,

Yes, that is close, but with one important difference: in my case it does not look like the LAN clients simply keep using an old delegated prefix.

After the ONT comes back online, wan6 appears valid from OpenWrt’s point of view:

  • wan6 is up

  • the router itself has IPv6 connectivity

  • ifstatus wan6 shows an IPv6 address and an IPv6 delegated prefix

  • br-lan also has the delegated prefix

  • LAN clients receive IPv6 addresses from that prefix

However, IPv6 traffic sourced from the LAN prefix does not work.

For example, after the ONT restart, this works from the router:

ping -6 -I eth0 2606:4700:4700::1111

but this fails:

ping -6 -I <br-lan IPv6 address> 2606:4700:4700::1111

Then, if I run:

ubus call network.interface.wan6 renew

it triggers an ifupdate on wan6 with IFUPDATE_PREFIXES=1, but this alone is not always enough. What reliably restores LAN IPv6 is:

1. wan6 comes back up after ONT/link loss
2. run ubus call network.interface.wan6 renew
3. wait for ifupdate on wan6 with IFUPDATE_PREFIXES=1
4. verify that ifstatus wan6 contains both ipv6-address and ipv6-prefix
5. run ubus call network.interface.wan6 renew again
6. wait for the second ifupdate
7. restart odhcpd so LAN RA/DHCPv6 is refreshed

Also, to clarify why I used /etc/hotplug.d/iface/20-firewall for the workaround: I do not think the firewall itself is the root cause.

I used that file because it is a convenient hotplug point that runs after wan6 interface events, and it sees both:

ifup wan6
ifupdate wan6 with IFUPDATE_PREFIXES=1

Those are exactly the events needed to reproduce the recovery sequence.

Also let me give you some context regarding my IPv6 configuration:

The ONT receives two /56 IPv6 prefixes: one prefix is used by the ONT itself, and the other is the prefix I want to use directly on my Flint 3.

To avoid using anything delegated or advertised by the ONT, I added two firewall rules in LuCI to block:

ICMPv6 Router Advertisement from the ONT
DHCPv6-PD from the ONT

This way, my router does not use the ONT-provided IPv6 information. It uses the prefix coming directly from the Orange DHCPv6 server instead.

7

Update on the situation: Tonight I realized my ipv6 stopped working again on lan even without an ONT restart and I ran a series of commands to show you the situation. Hope it helps.

I ran these commands after i realised ipv6 was not working on lan.

In the broken state, the router itself still has working IPv6 connectivity on WAN:

root@GL-BE9300:~# ping -6 -c 3 -I eth0 2606:4700:4700::1111
PING 2606:4700:4700::1111 (2606:4700:4700::1111): 56 data bytes
64 bytes from 2606:4700:4700::1111: seq=0 ttl=60 time=16.182 ms
64 bytes from 2606:4700:4700::1111: seq=1 ttl=60 time=16.007 ms
64 bytes from 2606:4700:4700::1111: seq=2 ttl=60 time=15.740 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

A normal IPv6 ping from the router also works:

root@GL-BE9300:~# ping -6 -c 3 2606:4700:4700::1111
PING 2606:4700:4700::1111 (2606:4700:4700::1111): 56 data bytes
64 bytes from 2606:4700:4700::1111: seq=0 ttl=60 time=16.091 ms
64 bytes from 2606:4700:4700::1111: seq=1 ttl=60 time=15.602 ms
64 bytes from 2606:4700:4700::1111: seq=2 ttl=60 time=15.960 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

wan6 also looks valid. It is up, has an IPv6 address, and has a delegated prefix:

{
        "up": true,
        "available": true,
        "l3_device": "eth0",
        "proto": "dhcpv6",
        "device": "eth0",
        "delegation": true,
        "ipv6-address": [
                {
                        "address": "2a02:a58:8906:xxxx::1",
                        "mask": 128,
                        "preferred": 44285,
                        "valid": 47885
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2a02:a58:96be:xx00::",
                        "mask": 56,
                        "preferred": 44285,
                        "valid": 47885,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2a02:a58:96be:xx00::",
                                        "mask": 60
                                }
                        }
                }
        ],
        "route": [
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::2621:24ff:feXX:XXXX",
                        "metric": 512,
                        "source": "2a02:a58:96be:xx00::/56"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::2621:24ff:feXX:XXXX",
                        "metric": 512,
                        "source": "2a02:a58:8906:xxxx::1/128"
                }
        ],
        "dns-server": [
                "2a02:a58:21:21::1",
                "2a02:a58:21:21::2"
        ]
}

br-lan also has an address from the delegated public prefix:

root@GL-BE9300:~# ip -6 addr show br-lan
16: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 2a02:a58:96be:xx00::1/60 scope global dynamic noprefixroute
       valid_lft 47875sec preferred_lft 44275sec
    inet6 fe80::9683:c4ff:feXX:XXXX/64 scope link
       valid_lft forever preferred_lft forever

However, traffic sourced from the LAN delegated prefix does not work:

root@GL-BE9300:~# ping -6 -c 3 -I 2a02:a58:96be:xx00::1 2606:4700:4700::1111
PING 2606:4700:4700::1111 (2606:4700:4700::1111) from 2a02:a58:96be:xx00::1: 56 data bytes

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

The IPv6 routing table also looks correct. There is a default route for the delegated prefix via the upstream link-local gateway:

root@GL-BE9300:~# ip -6 route show
default from 2a02:a58:8906:xxxx::1 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 pref medium
default from 2a02:a58:96be:xx00::/56 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 pref medium
2a02:a58:96be:xx00::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2a02:a58:96be:xx00::/56 dev lo proto static metric 2147483647 pref medium
default via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 10 pref medium
default via fe80::2621:24ff:feXX:XXXX dev eth0 proto ra metric 1024 expires 3984sec hoplimit 64 pref medium

Even route lookup for traffic sourced from the LAN IPv6 address selects the correct WAN path:

root@GL-BE9300:~# ip -6 route get 2606:4700:4700::1111 from 2a02:a58:96be:xx00::1 iif br-lan
2606:4700:4700::1111 from 2a02:a58:96be:xx00::1 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 iif br-lan pref medium

So the visible configuration looks correct:

  • router WAN IPv6 works

  • wan6 is up

  • wan6 has an IPv6 address

  • wan6 has a delegated prefix

  • br-lan has an IPv6 address from the delegated prefix

  • route lookup for traffic from the LAN prefix selects the correct upstream route

But traffic sourced from the LAN delegated prefix still fails.

Then I ran a manual renew:

root@GL-BE9300:~# ubus call network.interface.wan6 renew

Immediately after that, the same ping sourced from the LAN IPv6 address started working:

root@GL-BE9300:~# ping -6 -c 3 -I 2a02:a58:96be:xx00::1 2606:4700:4700::1111
PING 2606:4700:4700::1111 (2606:4700:4700::1111) from 2a02:a58:96be:xx00::1: 56 data bytes
64 bytes from 2606:4700:4700::1111: seq=0 ttl=60 time=15.806 ms
64 bytes from 2606:4700:4700::1111: seq=1 ttl=60 time=16.006 ms
64 bytes from 2606:4700:4700::1111: seq=2 ttl=60 time=16.060 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

This suggests that the problem is not simply missing IPv6 configuration on LAN. The IPv6 address, delegated prefix, and routes are present and look correct, but the delegated prefix is not actually usable for LAN-sourced traffic until wan6 is renewed again.

The router appears to have the correct IPv6 information, but traffic from the delegated LAN prefix does not work until ubus call network.interface.wan6 renew is executed.

8

Small update after more testing:

I narrowed the issue down further. While LAN IPv6 was broken but WAN IPv6 was still working, I tested several recovery actions:

fw3 reload only       -> did not fix it
kmwan restart only    -> did not fix it
kill -USR1 odhcp6c    -> fixed it immediately
ubus wan6 renew       -> also works, but odhcp6c USR1 had already restored it

The key finding is that sending SIGUSR1 directly to the odhcp6c process restores LAN IPv6 immediately:

kill -USR1 $(pidof odhcp6c)

After this, traffic sourced from the br-lan IPv6 address starts working again.

So this now looks like an odhcp6c / DHCPv6-PD renew-state issue. The delegated prefix is visible in netifd and assigned to LAN, but traffic from that prefix is not usable until odhcp6c performs a renew.

I also tested a much simpler workaround: after wan6 ifup, after the normal firewall reload, send SIGUSR1 to the odhcp6c process for eth0.

Simplified sequence:

wan6 ifup
→ firewall reload
→ SIGUSR1 to odhcp6c

This restored LAN IPv6 after ONT restart in my tests, without needing the previous more complex two-renew sequence.

9

I captured the broken state with tcpdump on eth0.

When LAN IPv6 was broken, packets sourced from the delegated LAN prefix were actually leaving the router correctly:

2a02:a58:96be:xx00::1 > 2606:4700:4700::1111 ICMPv6 echo request

They were sent to the ISP gateway MAC

But no echo replies came back.

After forcing a renew on odhcp6c, the exact same test immediately started receiving replies:

2606:4700:4700::1111 > 2a02:a58:96be:xx00::1 ICMPv6 echo reply

So the router is sending LAN-prefix traffic out correctly, but the upstream return path for the delegated prefix appears inactive/stale until odhcp6c renews the DHCPv6-PD state.

I created a case with my ISP to see if they have something missconfigured. Will keep you updated.

10

Ok, I have closed the case with my ISP, it seems everything is correct on their side. I have also talked to other people using the same ipv6 config, but different routers and they have no issues after ONT restarts. Please investigate and if you want more information, logs, contact me. Thank you!

11

And another update…

The funny part is that after that call, I reset the ONT again, and somehow everything started working correctly.

Now, when I restart the ONT, LAN IPv6 continues to work normally. The delegated prefix stays usable on LAN, and I no longer need to force a DHCPv6-PD renew manually.

So it looks like something was stuck on the ISP/ONT side, even though they said everything looked fine. After the call and the ONT reset, the exact same router configuration now works properly.

I will keep monitoring it, but at the moment the issue seems gone.

Also, thank you for staying with me through all of this, and sorry for making you check things that were probably working fine. I was just trying to understand what was going on and get my setup working properly.

1 Like
12

Ok, sadly it is back today but after all of my testing I managed to find the perfect fix for it in this script(It basically never breaks), which I hope maybe it can help someone who has a similar issue:

/////////////////////////////////////////////

cat > /etc/hotplug.d/iface/99-fix-pd-renew

/////////////////////////////////////////////

#!/bin/sh

[ "$INTERFACE" = "wan6" ] || exit 0

case "$ACTION" in
    ifup|ifupdate) ;;
    *) exit 0 ;;
esac

WAN_DEV="$(ifstatus wan6 | jsonfilter -e '@.l3_device' 2>/dev/null)"
BRLAN_IP="$(ip -6 addr show dev br-lan scope global | awk '/inet6/ {print $2}' | cut -d/ -f1 | head -n1)"
PID="$(pgrep -f "odhcp6c.*${WAN_DEV}")"

[ -n "$WAN_DEV" ] || exit 0
[ -n "$BRLAN_IP" ] || exit 0
[ -n "$PID" ] || exit 0

ping -6 -I "$BRLAN_IP" -c 2 -W 2 2606:4700:4700::1111 >/dev/null 2>&1 && exit 0

logger -t pd-fix "LAN IPv6 prefix not receiving replies; forcing DHCPv6-PD renew"
kill -USR1 "$PID"

/////////////////////////////////////////////

chmod +x /etc/hotplug.d/iface/99-fix-pd-renew

/////////////////////////////////////////////
1 Like
13

By reading the IPV6 logs i found something:

After the ONT is restarted, the router removes the WAN IPv6 address and the routes related to the delegated prefix:

Tue Jun  9 19:04:11 avahi-daemon[11129]: Leaving mDNS multicast group on interface eth0.IPv6 with address 2a02:a58:8906:xxxx::1.
Tue Jun  9 19:04:11 avahi-daemon[11129]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:feXX:XXXX.

Tue Jun  9 19:04:12 IPv6 event: Deleted 4: eth0    inet6 2a02:a58:8906:xxxx::1/128 scope global dynamic noprefixroute
Tue Jun  9 19:04:12 IPv6 event: Deleted local 2a02:a58:8906:xxxx::1 dev eth0 table local proto kernel metric 0 pref medium

Tue Jun  9 19:04:12 IPv6 event: Deleted default from 2a02:a58:96be:xx00::/56 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 dead linkdown pref medium
Tue Jun  9 19:04:12 IPv6 event: Deleted default from 2a02:a58:8906:xxxx::1 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 dead linkdown pref medium
Tue Jun  9 19:04:12 IPv6 event: Deleted 2a02:a58:96be:xx00::/64 dev br-lan proto static metric 1024 pref medium

But then br-lan keeps the delegated-prefix address in a deprecated state:

Tue Jun  9 19:04:12 IPv6 event: 16: br-lan    inet6 2a02:a58:96be:xx00::1/60 scope global deprecated dynamic
Tue Jun  9 19:04:12 IPv6 event: 2a02:a58:96be:xx00::/60 dev br-lan proto kernel metric 256 expires 7200sec pref medium

This looks like the important part of the issue: after the WAN side goes down, the delegated prefix is not fully cleared from LAN. It remains on br-lan as deprecated and still has a kernel route with an expiry timer.

Then, when the ONT/WAN side comes back, the router restores the WAN IPv6 address, the LAN address from the delegated prefix, and the source-specific default routes:

Tue Jun  9 19:05:30 avahi-daemon[11129]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:feXX:XXXX.
Tue Jun  9 19:05:30 avahi-daemon[11129]: Joining mDNS multicast group on interface eth0.IPv6 with address 2a02:a58:8906:xxxx::1.

Tue Jun  9 19:05:30 IPv6 event: 4: eth0    inet6 2a02:a58:8906:xxxx::1/128 scope global tentative dynamic noprefixroute
Tue Jun  9 19:05:30 IPv6 event: 16: br-lan    inet6 2a02:a58:96be:xx00::1/60 scope global dynamic noprefixroute
Tue Jun  9 19:05:30 IPv6 event: 2a02:a58:96be:xx00::/64 dev br-lan proto static metric 1024 pref medium

Tue Jun  9 19:05:30 IPv6 event: default from 2a02:a58:96be:xx00::/56 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 pref medium
Tue Jun  9 19:05:30 IPv6 event: default from 2a02:a58:8906:xxxx::1 via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 512 pref medium

Tue Jun  9 19:05:31 IPv6 event: Deleted default via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 10 pref medium
Tue Jun  9 19:05:31 IPv6 event: default via fe80::2621:24ff:feXX:XXXX dev eth0 proto static metric 10 pref medium
Tue Jun  9 19:05:31 IPv6 event: 4: eth0    inet6 2a02:a58:8906:xxxx::1/128 scope global dynamic noprefixroute
Tue Jun  9 19:05:31 IPv6 event: local 2a02:a58:8906:xxxx::1 dev eth0 table local proto kernel metric 0 pref medium

So the router brings the IPv6 state back locally, but the delegated prefix appears to have been left in a badstate during the transition.

Shouldn’t the LAN prefix be fully refreshed when eth0 loses and regains IPv6, instead of keeping the old deprecated LAN prefix state during the transition?

14

Ok, I found something very interesting.

wan6 is set to Request IPv6-address: try, so it requested both a WAN /128 IA_NA address and the delegated /56 IA_PD prefix; after an ONT reboot, the prefix stayed visible locally but LAN IPv6 stopped working until a manual DHCPv6 renew.

After changing Request IPv6-address to disabled, the router requests only the delegated /56 prefix, and IPv6 now recovers correctly after ONT reboot without any manual renew. So basically no script, nothing. Why would the /128 address cause this?

The only thing that i do not like is that the menu does not reflect a working ipv6 only ipv4, but ipv6 works fine on every device, even the router which has no ipv6 address.

Please investigate. Thank you!

15

We still have not been able to reproduce the issue, as the test environment we built always receives a /128 IPv6 address on the WAN interface via DHCPv6.

Perhaps you could check whether the routing table or neighbor table is being updated correctly before and after the issue occurs, or whether they remain unchanged, causing traffic to be forwarded incorrectly.

ip route show table all
ip neigh
16

Router is reset, has no custom scripts, and the configuration used in these tests is the standard LuCI configuration(minus the ONT block RA and DHCPv6).

The first log is from the broken state, after rebooting the ONT. LAN IPv6 was broken at this point.

The IPv6 router log is from a router reboot followed by the same ONT reboot used for the first test.

===== BEFORE manual DHCPv6 renew - LAN IPv6 broken after ONT reboot =====

root@GL-BE9300:~# ip route show table all
default via 90.95.128.1 dev eth0 proto static src 90.95.140.xxx metric 10
90.95.128.0/20 dev eth0 proto static scope link metric 10
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
broadcast 90.95.128.0 dev eth0 table local proto kernel scope link src 90.95.140.xxx
local 90.95.140.xxx dev eth0 table local proto kernel scope host src 90.95.140.xxx
broadcast 90.95.143.255 dev eth0 table local proto kernel scope link src 90.95.140.xxx
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.8.0 dev br-lan table local proto kernel scope link src 192.168.8.1
local 192.168.8.1 dev br-lan table local proto kernel scope host src 192.168.8.1
broadcast 192.168.8.255 dev br-lan table local proto kernel scope link src 192.168.8.1
default from 2a02:a58:8906:1eXX::1 via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 512 pref medium
default from 2a02:a58:96be:5aXX::/56 via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 512 pref medium
2a02:a58:96be:5aXX::/64 dev br-lan proto static metric 1024 pref medium
2a02:a58:96be:5aXX::/60 dev br-lan proto kernel metric 256 expires 6956sec pref medium
unreachable 2a02:a58:96be:5aXX::/56 dev lo proto static metric 2147483647 pref medium
unreachable fd3d:c443:48XX::/48 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
fe80::/64 dev wlan2 proto kernel metric 256 pref medium
fe80::/64 dev wlan1 proto kernel metric 256 pref medium
fe80::/64 dev eth1.1 proto kernel metric 256 pref medium
default via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 10 pref medium
default via fe80::2621:24ff:fe91:XXXX dev eth0 proto ra metric 1024 expires 4334sec hoplimit 64 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2a02:a58:8906:1eXX::1 dev eth0 table local proto kernel metric 0 pref medium
anycast 2a02:a58:96be:5aXX:: dev br-lan table local proto kernel metric 0 pref medium
local 2a02:a58:96be:5aXX::1 dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev eth1 table local proto kernel metric 0 pref medium
anycast fe80:: dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan0 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan2 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan1 table local proto kernel metric 0 pref medium
anycast fe80:: dev eth1.1 table local proto kernel metric 0 pref medium
local fe80::84f7:bfff:fe74:XXXX dev wlan1 table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev eth0 table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev br-lan table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev eth1.1 table local proto kernel metric 0 pref medium
local fe80::c6ce:abff:fe0e:XXXX dev eth1 table local proto kernel metric 0 pref medium
local fe80::d89a:b8ff:fefa:XXXX dev wlan2 table local proto kernel metric 0 pref medium
local fe80::d8af:96ff:fe7d:XXXX dev wlan0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev eth1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev br-lan table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan2 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eth1.1 table local proto kernel metric 256 pref medium

root@GL-BE9300:~# ip neigh
192.168.8.125 dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
192.168.8.148 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.162 dev br-lan lladdr ba:15:a2:97:e4:xx STALE
90.95.128.1 dev eth0 lladdr 00:00:5e:00:01:xx REACHABLE
192.168.8.191 dev br-lan lladdr fc:5f:49:1c:8c:xx REACHABLE
192.168.8.183 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.133 dev br-lan lladdr 4c:d5:77:25:1c:xx REACHABLE
192.168.8.199 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.164 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.138 dev br-lan lladdr ba:15:a2:97:e4:xx STALE
192.168.8.135 dev br-lan lladdr 0c:dc:91:ff:25:xx STALE
192.168.8.121 dev br-lan lladdr 4e:23:92:82:c7:xx REACHABLE
192.168.8.156 dev br-lan lladdr d6:15:ed:87:6c:xx REACHABLE
192.168.8.226 dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
2a02:a58:96be:5aXX:4c23:92ff:fe82:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx STALE
2a02:a58:96be:5aXX:88d3:e031:82c5:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::2621:24ff:fe91:XXXX dev eth0 lladdr 00:00:5e:00:01:xx router REACHABLE
fe80::4c23:92ff:fe82:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx REACHABLE
2a02:a58:96be:5aXX:d0ee:a077:4719:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx REACHABLE
2a02:a58:96be:5aXX:b65b:35fd:52d4:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::9c1a:45c9:2212:XXXX dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
fe80::9683:c4ff:fece:XXXX dev eth0 lladdr 94:83:c4:ce:ab:xx STALE
2a02:a58:96be:5aXX:3c66:4b09:f8e7:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
2a02:a58:96be:5aXX:18b8:dcff:fee7:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::dc50:87e7:ab4:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
fe80::f024:21b9:5a02:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::18b8:dcff:fee7:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
2a02:a58:96be:5aXX::1 dev br-lan FAILED
2a02:a58:96be:5aXX:6db1:2384:b662:XXXX dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
2a02:a58:96be:5aXX:4a26:4cff:fe0a:XXXX dev br-lan FAILED
fe80::fe5f:49ff:fe1c:XXXX dev br-lan lladdr fc:5f:49:1c:8c:xx REACHABLE
2a02:a58:96be:5aXX:393a:123:36c7:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx STALE


===== Manual DHCPv6 renew =====

root@GL-BE9300:~# kill -USR1 $(ps w | awk '/[o]dhcp6c/ && $NF == "eth0" {print $1; exit}')


===== AFTER manual DHCPv6 renew - LAN IPv6 working =====

root@GL-BE9300:~# ip route show table all
default via 90.95.128.1 dev eth0 proto static src 90.95.140.xxx metric 10
90.95.128.0/20 dev eth0 proto static scope link metric 10
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
broadcast 90.95.128.0 dev eth0 table local proto kernel scope link src 90.95.140.xxx
local 90.95.140.xxx dev eth0 table local proto kernel scope host src 90.95.140.xxx
broadcast 90.95.143.255 dev eth0 table local proto kernel scope link src 90.95.140.xxx
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.8.0 dev br-lan table local proto kernel scope link src 192.168.8.1
local 192.168.8.1 dev br-lan table local proto kernel scope host src 192.168.8.1
broadcast 192.168.8.255 dev br-lan table local proto kernel scope link src 192.168.8.1
default from 2a02:a58:8906:1eXX::1 via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 512 pref medium
default from 2a02:a58:96be:5aXX::/56 via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 512 pref medium
2a02:a58:96be:5aXX::/64 dev br-lan proto static metric 1024 pref medium
2a02:a58:96be:5aXX::/60 dev br-lan proto kernel metric 256 expires 6471sec pref medium
unreachable 2a02:a58:96be:5aXX::/56 dev lo proto static metric 2147483647 pref medium
unreachable fd3d:c443:48XX::/48 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
fe80::/64 dev wlan2 proto kernel metric 256 pref medium
fe80::/64 dev wlan1 proto kernel metric 256 pref medium
fe80::/64 dev eth1.1 proto kernel metric 256 pref medium
default via fe80::2621:24ff:fe91:XXXX dev eth0 proto static metric 10 pref medium
default via fe80::2621:24ff:fe91:XXXX dev eth0 proto ra metric 1024 expires 3849sec hoplimit 64 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2a02:a58:8906:1eXX::1 dev eth0 table local proto kernel metric 0 pref medium
anycast 2a02:a58:96be:5aXX:: dev br-lan table local proto kernel metric 0 pref medium
local 2a02:a58:96be:5aXX::1 dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev eth1 table local proto kernel metric 0 pref medium
anycast fe80:: dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan0 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan2 table local proto kernel metric 0 pref medium
anycast fe80:: dev wlan1 table local proto kernel metric 0 pref medium
anycast fe80:: dev eth1.1 table local proto kernel metric 0 pref medium
local fe80::84f7:bfff:fe74:XXXX dev wlan1 table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev eth0 table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev br-lan table local proto kernel metric 0 pref medium
local fe80::9683:c4ff:fece:XXXX dev eth1.1 table local proto kernel metric 0 pref medium
local fe80::c6ce:abff:fe0e:XXXX dev eth1 table local proto kernel metric 0 pref medium
local fe80::d89a:b8ff:fefa:XXXX dev wlan2 table local proto kernel metric 0 pref medium
local fe80::d8af:96ff:fe7d:XXXX dev wlan0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev eth1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev br-lan table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan2 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wlan1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev eth1.1 table local proto kernel metric 256 pref medium

root@GL-BE9300:~# ip neigh
192.168.8.125 dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
192.168.8.148 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.162 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
90.95.128.1 dev eth0 lladdr 00:00:5e:00:01:xx REACHABLE
192.168.8.191 dev br-lan lladdr fc:5f:49:1c:8c:xx REACHABLE
192.168.8.183 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.133 dev br-lan lladdr 4c:d5:77:25:1c:xx REACHABLE
192.168.8.199 dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
192.168.8.164 dev br-lan lladdr ba:15:a2:97:e4:xx STALE
192.168.8.138 dev br-lan lladdr ba:15:a2:97:e4:xx STALE
192.168.8.135 dev br-lan lladdr 0c:dc:91:ff:25:xx STALE
192.168.8.121 dev br-lan lladdr 4e:23:92:82:c7:xx REACHABLE
192.168.8.156 dev br-lan lladdr d6:15:ed:87:6c:xx REACHABLE
192.168.8.226 dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
2a02:a58:96be:5aXX:4c23:92ff:fe82:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx STALE
2a02:a58:96be:5aXX:88d3:e031:82c5:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::2621:24ff:fe91:XXXX dev eth0 lladdr 00:00:5e:00:01:xx router DELAY
fe80::4c23:92ff:fe82:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx REACHABLE
2a02:a58:96be:5aXX:d0ee:a077:4719:XXXX dev br-lan lladdr 4e:23:92:82:c7:xx STALE
2a02:a58:96be:5aXX:b65b:35fd:52d4:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
2a02:a58:96be:5aXX:37c4:9eb0:5a02:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::9c1a:45c9:2212:XXXX dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
fe80::9683:c4ff:fece:XXXX dev eth0 lladdr 94:83:c4:ce:ab:xx STALE
2a02:a58:96be:5aXX:3c66:4b09:f8e7:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
2a02:a58:96be:5aXX:18b8:dcff:fee7:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx STALE
fe80::dc50:87e7:ab4:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx REACHABLE
fe80::f024:21b9:5a02:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
fe80::18b8:dcff:fee7:XXXX dev br-lan lladdr ba:15:a2:97:e4:xx REACHABLE
2a02:a58:96be:5aXX::1 dev br-lan FAILED
2a02:a58:96be:5aXX:6db1:2384:b662:XXXX dev br-lan lladdr 8c:86:dd:61:21:xx REACHABLE
2a02:a58:96be:5aXX:4a26:4cff:fe0a:XXXX dev br-lan FAILED
fe80::fe5f:49ff:fe1c:XXXX dev br-lan lladdr fc:5f:49:1c:8c:xx REACHABLE
2a02:a58:96be:5aXX:393a:123:36c7:XXXX dev br-lan lladdr 28:a0:6b:72:a7:xx STALE


===== IPv6-related router log - router reboot, then ONT reboot from the same test =====

Fri Jun 12 13:07:50 2026 kern.info kernel: [    3.679414] Segment Routing with IPv6
Fri Jun 12 13:07:50 2026 kern.info kernel: [   12.696534] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
Fri Jun 12 13:07:50 2026 kern.info kernel: [   12.711736] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
Fri Jun 12 13:07:50 2026 kern.info kernel: [   12.730454] ip6_gre: GRE over IPv6 tunneling driver
Fri Jun 12 13:07:52 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:07:57 2026 daemon.warn netifd: You have delegated IPv6-prefixes but haven't assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
Fri Jun 12 13:07:59 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface br-lan.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: New relevant interface br-lan.IPv6 for mDNS.
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::c6ce:abff:fe0e:XXXX.
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: New relevant interface eth1.IPv6 for mDNS.
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface lo.IPv6 with address ::1.
Fri Jun 12 13:08:00 2026 daemon.info avahi-daemon[11143]: New relevant interface lo.IPv6 for mDNS.
Fri Jun 12 13:08:01 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:08:02 2026 kern.info kernel: [   29.609681] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Fri Jun 12 13:08:04 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:08:04 2026 daemon.info avahi-daemon[11143]: New relevant interface eth0.IPv6 for mDNS.
Fri Jun 12 13:08:08 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:08:09 2026 daemon.info avahi-daemon[11143]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:08:09 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth0.IPv6 with address 2a02:a58:8906:1eXX::1.
Fri Jun 12 13:08:09 2026 daemon.info avahi-daemon[11143]: Leaving mDNS multicast group on interface br-lan.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:08:09 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface br-lan.IPv6 with address 2a02:a58:96be:5aXX::1.
Fri Jun 12 13:08:14 2026 user.warn ddns-scripts[15882]: glddnsv6: Error in 'expand_ipv6()' - invalid IPv6 found: '' expanded: ''
Fri Jun 12 13:08:51 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::d8af:96ff:fe7d:XXXX.
Fri Jun 12 13:08:51 2026 daemon.info avahi-daemon[11143]: New relevant interface wlan0.IPv6 for mDNS.
Fri Jun 12 13:08:55 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface wlan1.IPv6 with address fe80::84f7:bfff:fe74:XXXX.
Fri Jun 12 13:08:55 2026 daemon.info avahi-daemon[11143]: New relevant interface wlan1.IPv6 for mDNS.
Fri Jun 12 13:08:55 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface wlan2.IPv6 with address fe80::d89a:b8ff:fefa:XXXX.
Fri Jun 12 13:08:55 2026 daemon.info avahi-daemon[11143]: New relevant interface wlan2.IPv6 for mDNS.
Fri Jun 12 13:08:58 2026 daemon.info avahi-daemon[11143]: Interface wlan1.IPv6 no longer relevant for mDNS.
Fri Jun 12 13:08:58 2026 daemon.info avahi-daemon[11143]: Leaving mDNS multicast group on interface wlan1.IPv6 with address fe80::84f7:bfff:fe74:XXXX.
Fri Jun 12 13:08:59 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:09:00 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface wlan1.IPv6 with address fe80::84f7:bfff:fe74:XXXX.
Fri Jun 12 13:09:00 2026 daemon.info avahi-daemon[11143]: New relevant interface wlan1.IPv6 for mDNS.
Fri Jun 12 13:09:02 2026 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Fri Jun 12 13:09:05 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth1.1.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:09:05 2026 daemon.info avahi-daemon[11143]: New relevant interface eth1.1.IPv6 for mDNS.
Fri Jun 12 13:12:07 2026 daemon.info avahi-daemon[11143]: Leaving mDNS multicast group on interface eth0.IPv6 with address 2a02:a58:8906:1eXX::1.
Fri Jun 12 13:12:07 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:12:20 2026 user.warn ddns-scripts[30618]: glddnsv6: Error in 'expand_ipv6()' - invalid IPv6 found: '' expanded: ''
Fri Jun 12 13:12:33 2026 user.warn ddns-scripts[32334]: glddnsv6: Error in 'expand_ipv6()' - invalid IPv6 found: '' expanded: ''
Fri Jun 12 13:13:26 2026 daemon.info avahi-daemon[11143]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::9683:c4ff:fece:XXXX.
Fri Jun 12 13:13:26 2026 daemon.info avahi-daemon[11143]: Joining mDNS multicast group on interface eth0.IPv6 with address 2a02:a58:8906:1eXX::1.
Fri Jun 12 13:13:31 2026 user.warn ddns-scripts[3256]: glddnsv6: Error in 'expand_ipv6()' - invalid IPv6 found: '' expanded: ''

Also keep in mind that disabling the request of ip adress in wan6 for now seems to be the stable way of achieving ipv6 on my devices, because it never breaks. The one showed in these logs with the manual renew and request of ipv6 adress on try in wan6 will break eventually after some time, with nothing to be shown in logs. I’m here to give you anything you need. Thank you!

17

Are you dialing pppoe from the bridged glinet router?

18

No, Both are DHCP

19

Also regarding the IPv6 log from the router we can see something interesting:

After the router reboot, IPv6 comes up normally:

13:08:09 eth0 leaves fe80::... and joins 2a02:a58:8906:1eXX::1
13:08:09 br-lan leaves fe80::... and joins 2a02:a58:96be:5aXX::1

Then, after the ONT reboot, the WAN IPv6 address is removed and later added back:

13:12:07 eth0 leaves 2a02:a58:8906:1eXX::1
13:12:07 eth0 joins fe80::...

13:13:26 eth0 leaves fe80::...
13:13:26 eth0 joins 2a02:a58:8906:1eXX::1

What I find interesting is that the log clearly shows the WAN IA_NA /128 address being removed and restored, but I do not see an equally clear refresh of the delegated IA_PD prefix on br-lan at that time.

20

Yes I had faced these kinds of errors on old versions of openwrt when the br-lan interface holds stale pd configs. Are you running the op21 version? If so it may help trying out the op24 version of the same.