Page MenuHomeVyOS Platform
Create Task
Maniphest T9284

dhcp6c integer overflow / garbage value in pltime causes vyos-netlinkd loop and loss of connectivity
Open, HighPublicBUG
Actions

Description

Note: This report was drafted with AI assistance based on raw system logs and direct CLI outputs. All logs and findings have been human-verified.

VyOS Version: 1.5-rolling-202609010034

Component: dhcp6c / wide-dhcpv6 / vyos-netlinkd

ISP / Environment: Init7 (Fiber, Switzerland) — DHCPv6 IA_NA + IA_PD (/48)

Description

During a periodic DHCPv6 renewal on WAN interface (eth1), dhcp6c parses/calculates an invalid, astronomically high preferred lifetime (pltime) value when updating the prefix and address. This garbage value (pltime=94420561038264) gets passed to /etc/wide-dhcpv6/dhcp6c.eth1.script, which puts vyos-netlinkd into a continuous loop (RTM_NEWADDR) re-applying the IPv6 address every second until the routing table/interface breaks and network connectivity is completely lost.

Configuration (eth1)

set interfaces ethernet eth1 address 'dhcp'
set interfaces ethernet eth1 address 'dhcpv6'
set interfaces ethernet eth1 address '2a02:168:5608:1::99/128'
set interfaces ethernet eth1 description 'WAN - Init7 (10G SFP+)'
set interfaces ethernet eth1 dhcpv6-options pd 0 interface dum0 address '1'
set interfaces ethernet eth1 dhcpv6-options pd 0 length '48'
set interfaces ethernet eth1 hw-id '64:62:66:25:0e:3b'
set interfaces ethernet eth1 ipv6 address autoconf
set interfaces ethernet eth1 offload gro
set interfaces ethernet eth1 offload gso
set interfaces ethernet eth1 offload sg
set interfaces ethernet eth1 offload tso

Steps to Reproduce

Configure WAN interface eth1 with DHCPv6 and Prefix Delegation (IA_PD /48) as shown in the configuration above.

Wait for a DHCPv6 RENEW cycle from the ISP (Init7).

Observe journalctl logs for dhcp6c and vyos-netlinkd.

Relevant Log Extracts

  1. Garbage Lifetime Value in dhcp6c:
Sep 06 21:59:42 vyos dhcp6c[2876]: copyin_option: IA_PD prefix: xxxx:xxxx:xxxx::/48 pltime=3000 vltime=4000
Sep 06 21:59:42 vyos dhcp6c[2876]: update_prefix: update a prefix xxxx:xxxx:xxxx::/48 pltime=94420561038264, vltime=94420561039264
Sep 06 21:59:42 vyos dhcp6c[2876]: client6_recvreply: executes /etc/wide-dhcpv6/dhcp6c.eth1.script

(Note: ISP sends pltime=3000, but dhcp6c internal state transforms it into 94420561038264).

  1. Resulting Netlink Loop (vyos-netlinkd):
Sep 06 23:03:09 vyos vyos-netlinkd[4478]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 06 23:03:17 vyos vyos-netlinkd[4478]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 06 23:03:27 vyos vyos-netlinkd[4478]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
... (repeats indefinitely every few seconds until network drops)

Expected Behavior

dhcp6c should correctly parse and apply the lifetime received from the server (pltime=3000), update the kernel routing table once, and sleep until the next renewal interval without triggering a vyos-netlinkd address loop.

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Related Objects

Event Timeline

je created this task.Mon, Sep 7, 9:26 AM
je triaged this task as Normal priority.
je created this object in space S1 VyOS Public.
Viacheslav raised the priority of this task from Normal to High.Mon, Sep 7, 10:17 AM
Viacheslav changed the subtype of this task from "Task" to "Bug".
Viacheslav added a subscriber: c-po.
pasik subscribed.Mon, Sep 7, 6:25 PM
je added a comment.Tue, Sep 8, 6:43 AM

Update: Additional Log Excerpt & Workaround Observation

Issue confirmed as active on 1.5-rolling-202609010034.

Notice how copyin_option receives valid values (pltime=3000 vltime=4000), but update_address / update_prefix passes pointer-like garbage values (93982474375072 / 0x5573B7E983E0) to the script execution:

Sep 08 08:31:10 vyos dhcp6c[5055]: copyin_option:   IA_NA address: 2a02:168:2000:b::2b pltime=3000 vltime=4000
...
Sep 08 08:31:10 vyos dhcp6c[5055]: update_address: update an address 2a02:168:2000:b::2b pltime=3000, vltime=93982474375072
...
Sep 08 08:31:10 vyos dhcp6c[5055]: copyin_option:   IA_PD prefix: 2a02:168:5608::/48 pltime=3000 vltime=4000
...
Sep 08 08:31:10 vyos dhcp6c[5055]: update_prefix: update a prefix 2a02:168:5608::/48 pltime=93982474374072, vltime=93982474375...
Sep 08 08:31:10 vyos dhcp6c[5055]: client6_recvreply: executes /etc/wide-dhcpv6/dhcp6c.eth1.script

Configuration Update / Workaround Note:
I applied the following configuration adjustments on eth1:

text
set interfaces ethernet eth1 dhcpv6-options no-release
set interfaces ethernet eth1 dhcpv6-options pd 0 interface eth0 address '1'
set interfaces ethernet eth1 dhcpv6-options pd 0 interface eth0 sla-id '1'

Observation: With these settings, while the garbage pltime/vltime calculations are still occurring in dhcp6c, the network connectivity itself no longer drops completely.

je added a comment.Tue, Sep 8, 9:18 AM

Seems to be the same as T7795: dhcp6c doesn't update pltime and vltime for dynamic ipv6 prefix

je added a comment.Tue, Sep 15, 3:30 PM

Update: Unfortunately, the system went offline again today (September 15) with a complete freeze/loss of connectivity, requiring a manual reboot.

It turns out that the previously mentioned configuration adjustments (no-release and prefix delegation settings) do not fully prevent the issue. Although they might mitigate some symptoms, the underlying dhcp6c integer overflow / garbage pltime still triggers the continuous vyos-netlinkd address re-application loop, which eventually brings down the system.

Here is the snippet from journalctl -b -1 right before the system stopped responding, showing the exact same RTM_NEWADDR loop on eth1:

Sep 15 04:52:59 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:07 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:16 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:26 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:30 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:38 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:47 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:53:55 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:54:00 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64
Sep 15 04:54:09 vyos vyos-netlinkd[4189]: RTM_NEWADDR -> eth1, addr=2a02:168:2000:b:6662:66ff:fe25:e3b/64

This remains a critical issue since it can completely knock out routers over time. Let me know if you need any further logs.

xTITUS_MAXIMUSx subscribed.Tue, Sep 29, 12:50 AM

I tried to reproduce this on 2026.09.23-0027-rolling (wide-dhcpv6-client 20080615-23). On a test link, Kea handed out an IA_NA address and a /48 IA_PD with pltime 3000 / vltime 4000 and T1=20, and radvd sent RAs on the same link.

I don't think the pltime/vltime values are actually wrong. They're only printed wrong. If you convert the numbers from your log to hex you get 0x55E0_00000BB8 and 0x55E0_00000FA0. The low 32 bits are exactly 3000 and 4000, and the top half is junk. dhcp6c stores these as u_int32_t but logs them with %lu (prefixconf.c and addrconf.c), so the log picks up garbage in the upper bits. I saw the same thing here: the server sent 3000/4000 and dhcp6c logged pltime=94527935220664. Every renew after that counted down normally (2980/3980, 2960/3960, 2940/3940).

The timers use the real values too. I reran with vltime=60 and killed the server. dhcp6c tried renew and rebind, then removed the address and the delegated prefix exactly 60 seconds later. I think T7795 is the same log artifact.

The RTM_NEWADDR lines aren't a loop either. 2a02:168:2000:b:6662:66ff:fe25:e3b is the EUI-64 address built from your eth1 MAC, so it comes from "ipv6 address autoconf", not DHCPv6 (your DHCPv6 address is ::2b). The kernel sends RTM_NEWADDR every time an RA refreshes that address. I got the same message every 4-8 seconds before dhcp6c even had a lease. For ethX interfaces, vyos-netlinkd just writes a debug line and moves on. It doesn't restart anything or touch addresses.

So I don't think either of these is what's killing the router, and the real cause is still unknown. I also haven't reproduced Init7's actual replies or a long-running lease. If it happens again, could you grab the following while the box is down:

  • ip -6 addr
  • ip -6 route
  • dmesg
  • the full journal for that boot (journalctl -b -1 after the reboot)
  • whether the console still responds