Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 lease doesn't seem to renew #7357

Open
1 task done
timocapa opened this issue Jan 10, 2025 · 4 comments
Open
1 task done

IPv6 lease doesn't seem to renew #7357

timocapa opened this issue Jan 10, 2025 · 4 comments

Comments

@timocapa
Copy link

timocapa commented Jan 10, 2025

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 :)

@MichaIng
Copy link
Owner

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

sysctl -a | grep -E forward|accept_ra

@timocapa
Copy link
Author

timocapa commented Jan 10, 2025

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
Copy link
Owner

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
Copy link
Author

timocapa commented Jan 10, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants