IPv6 lease doesn't seem to renew #7357

timocapa · 2025-01-10T11:55:21Z

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

DietPi version | DietPi 9.9.0
Distro version | bookworm
Kernel version | Linux DietPi 6.12.6-edge-sunxi #1 SMP Thu Dec 19 17:13:24 UTC 2024 armv7l GNU/Linux
SBC model | Generic Device (armv7l) (OrangePi Zero)
Power supply used | Power adapter, micro USB (sorry don't have exact details)
SD card used | Samsung something 64 GB

Additional Information (if applicable)

Can this issue be replicated on a fresh installation of DietPi?
Not tested

Bug report ID | 374cc0a4-9d66-44e7-b48d-34b8b05b226b (pre-reboot)

Steps to reproduce

Unknown since I don't know if this was present for longer already

Expected behaviour

IPv6 IP lease gets renewed

Actual behaviour

Upon a reboot, the Pi has an IPv6 as expected. If I check a day or two later, the IPv6 is gone and just the link-local address remains.

Pre-reboot:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:42:13:45:8d:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.198/24 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 37711sec preferred_lft 37711sec
    inet6 fe80::42:13ff:fe45:8d39/64 scope link
       valid_lft forever preferred_lft forever

Post-reboot:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:42:13:45:8d:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.198/24 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 43148sec preferred_lft 43148sec
    inet6 2003:104:2f01:a800:42:13ff:fe45:8d39/64 scope global dynamic mngtmpaddr
       valid_lft 45691sec preferred_lft 45691sec
    inet6 fe80::42:13ff:fe45:8d39/64 scope link
       valid_lft forever preferred_lft forever

(I don't really care about the MAC or v6 being being visible)

Extra details

The following tools / packages / services were installed by me:

PiHole (development branch, IPv6-enabled)
Docker (in which Dockge, and an Uptime Kuma instance runs)

Misc info:

My router is an Ubiquiti Cloud Gateway Ultra. DHCPv6 is enabled, SLAAC is also allowed.
I run the beta armbian repo for mainline Linux kernels.
IPv6 is enabled in dietpi-config.

I recall this being an issue prior to switching kernel to the latest available.

Falls ich irgendwas wichtiges nicht gepostet hab, bescheid sagen :)

The text was updated successfully, but these errors were encountered:

MichaIng · 2025-01-10T12:19:24Z

Do you have IP forwarding enabled, like for a hotspot or VPN?

sysctl -a | grep -E forward|accept_ra

timocapa · 2025-01-10T12:25:02Z

sysctl -a | grep -E forward|accept_ra

I'll be omitting IPv4 and unrelated interfaces (br-x from docker, wlan and lo)

net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.accept_ra_defrtr = 1
net.ipv6.conf.default.accept_ra_from_local = 0
net.ipv6.conf.default.accept_ra_min_hop_limit = 1
net.ipv6.conf.default.accept_ra_min_lft = 0
net.ipv6.conf.default.accept_ra_mtu = 1
net.ipv6.conf.default.accept_ra_pinfo = 1
net.ipv6.conf.default.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.default.accept_ra_rt_info_min_plen = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_from_local = 0
net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1
net.ipv6.conf.eth0.accept_ra_min_lft = 0
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rt_info_min_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.eth0.mc_forwarding = 0

No VPN set up either

Also probably worth pointing out that this is the only device this seems to happen on, so I'm gonna assume my router is not at fault. I will however still check things on it if you want me to (also CLI, it just runs Debian and allows SSH)

MichaIng · 2025-01-10T13:05:37Z

Okay, no firwarding, hence RAs should be accepted with accept_ra=1.

Does the router answer with an RA when requested?

apt install ndisc6
rdisc6

If so, to see whether it sends one regulaly without request:

apt install radvdump
radvdump

This should happen at latest every 30 minutes. The IPv6 GUA is valid for over 12 hours, but the default route is usually valid for 30 minutes only:

ip -6 r

timocapa · 2025-01-10T13:52:32Z

Both seem to work as expected

root@DietPi:~# rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :         high
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 Prefix                   : 2003:104:2f01:a800::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :        82168 (0x000140f8) seconds
  Pref. time              :        82168 (0x000140f8) seconds
 MTU                      :         1500 bytes (valid)
 Source link-layer address: 9E:05:D6:59:92:F4
 Recursive DNS server     : 2003:104:2f01:a800:42:13ff:fe45:8d39
  DNS server lifetime     :        82168 (0x000140f8) seconds
 from fe80::9c05:d6ff:fe59:92f4
root@DietPi:~#

v6 DNS is itself as it is the PiHole

root@DietPi:~# radvdump
#
# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::9c05:d6ff:fe59:92f4
# received by interface eth0
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 1800;
        AdvHomeAgentFlag off;
        AdvDefaultPreference high;
        AdvLinkMTU 1500;
        AdvSourceLLAddress on;

        prefix 2003:104:2f01:a800::/64
        {
                AdvValidLifetime 81822;
                AdvPreferredLifetime 81822;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        }; # End of prefix definition


        RDNSS 2003:104:2f01:a800:42:13ff:fe45:8d39
        {
                AdvRDNSSLifetime 81822;
        }; # End of RDNSS definition

}; # End of interface definition
^C
root@DietPi:~#

Letting it run and it does quite frequently show updates

root@DietPi:~# ip -6 r
2003:104:2f01:a800::/64 dev eth0 proto kernel metric 256 expires 81052sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev veth7279c48 proto kernel metric 256 pref medium
fe80::/64 dev br-7db8682da30d proto kernel metric 256 pref medium
fe80::/64 dev veth8d8bdb7 proto kernel metric 256 pref medium
fe80::/64 dev br-520c93b0cb97 proto kernel metric 256 pref medium
default via fe80::9c05:d6ff:fe59:92f4 dev eth0 proto ra metric 1024 expires 1705sec hoplimit 64 pref high

MichaIng · 2025-01-11T04:38:52Z

Okay also the default route is quite fresh, so right now it seems to receive and apply RA info regularly as it should. Question then is when and why it stops to do so.

Maybe let radvdump run throughout the time it lost the IPv6 address before, to see when it stops receiving (or applying) a new prefix. At least we have a timestamp then to check in system logs, in case also router logs.

timocapa · 2025-01-22T20:14:58Z

Hey, I just wanna chime in that this hasn't happened again since. I currently have an uptime of 4 days, and I still have a normal v6 (hence no replies since).

I wonder if it's just the installation of the packages you mentioned above? Maybe some Debian update? Either way, I'll keep it open for another week or two and if nothing happens I'll close this issue if I remember.

MichaIng · 2025-01-23T19:44:04Z

So far so good. The packages have no effect on this, they are only tools to monitor or actively trigger RAs, but do/should not change something, as long as you do not actively run rdisc6 to request an RA.

But maybe another library update, who knows 🤔. Yeah, good to keep an eye on it for another week, to be sure.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IPv6 lease doesn't seem to renew #7357

IPv6 lease doesn't seem to renew #7357

timocapa commented Jan 10, 2025 •

edited

Loading

MichaIng commented Jan 10, 2025

timocapa commented Jan 10, 2025 •

edited

Loading

MichaIng commented Jan 10, 2025

timocapa commented Jan 10, 2025 •

edited

Loading

MichaIng commented Jan 11, 2025

timocapa commented Jan 22, 2025

MichaIng commented Jan 23, 2025

IPv6 lease doesn't seem to renew #7357

IPv6 lease doesn't seem to renew #7357

Comments

timocapa commented Jan 10, 2025 • edited Loading

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

Expected behaviour

Actual behaviour

Extra details

MichaIng commented Jan 10, 2025

timocapa commented Jan 10, 2025 • edited Loading

MichaIng commented Jan 10, 2025

timocapa commented Jan 10, 2025 • edited Loading

MichaIng commented Jan 11, 2025

timocapa commented Jan 22, 2025

MichaIng commented Jan 23, 2025

timocapa commented Jan 10, 2025 •

edited

Loading

timocapa commented Jan 10, 2025 •

edited

Loading

timocapa commented Jan 10, 2025 •

edited

Loading