Page MenuHomeVyOS Platform

dhcp6c service cannot recover when it fails
Closed, ResolvedPublicBUG


I'm sorry to reopen this bug, but a bug report I replied in T421 has now been re generated. I have inquired the relevant service file and found that the file has been passive, and an invalid setting has been generated. The content of file /lib/systemd/system/dhcp6c@.service is as follows:

Description=WIDE DHCPv6 client on %i
Documentation=man:dhcp6c(8) man:dhcp6c.conf(5)

ExecStart=/usr/sbin/dhcp6c -D -k /run/dhcp6c/dhcp6c.%i.sock -c /run/dhcp6c/dhcp6c.%i.conf -p /run/dhcp6c/ %i


It appears that the following settings exist for automatic recovery:


But the directive:


I don't know why dhcpv6-pd doesn't seem to work when PPPoE dials and uses dhcpv6-pd after the router is started. When dhcp6c starts, PPPoE link has not been established. I've been waiting for at least half a minute, but it doesn't work until I manually restart it by typing the following command:

sudo systemctl restart dhcp6c@pppoe0

The following is a reference to the original modified file of @c-po:


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

Strange, I found that this service may not have been started at all!

Changing the systemd defaults is a thing I hesitate to do! It will have a ton of unexpected sideeffects. I guess you have an error in your entire setup as multiple sites of mine work flawlessly

I want to do it and have to re explore the cause of the failure, but I haven't found out why dhcp6c can't start, I have to start it manually.

Loaded: loaded (/lib/systemd/system/dhcp6c@.service; disabled; vendor preset: enabled)
Active: inactive (dead)
  Docs: man:dhcp6c(8)

By the way, a new problem has also been identified, see T2681

PPPoE is configured as follows (account password is hidden):

pppoe pppoe0 {
    authentication {
        password pass
        user userid
    default-route force
    description ISP
    dhcpv6-options {
        prefix-delegation {
            interface br1 {
                address 101
                sla-id 2
                sla-len 8
            interface br2 {
                address 101
                sla-id 1
                sla-len 8
            length 56
    firewall {
        in {
            ipv6-name WAN-IN
            name wan
        local {
            ipv6-name WAN-LOCAL
            name wan-local
    idle-timeout 30
    ipv6 {
        address {
    mtu 1492
    source-interface eth5

@c-po The problem was found when upgrading to the latest version, and the reason is not clear.

Oddly enough, whether I change the service settings or change the default settings of systemd, there are problems.

@c-po The basic cause of the failure has been determined.This time, the problem may be relatively serious, because it is not the configuration of the service, but the execution of commit will not start the dhcp6c service at all.

Since I don't know how the designer calls dhcp6c, it will take more time if I try to find out by myself, so I hope @c-po can start to investigate in person.

The minimum scale test code command is as follows:

sudo systemctl stop dhcp6c@pppoe0
set interfaces bridge br3
set interfaces pppoe pppoe0 dhcpv6-options prefix-delegation interface br3 sla-len 8
set interfaces pppoe pppoe0 dhcpv6-options prefix-delegation interface br3 sla-id 3
set interfaces pppoe pppoe0 dhcpv6-options prefix-delegation interface br3 address 101

If it is normal, after br3 is created, dhcp6c should be restarted after commit because the configuration of dhcp6c is changed, but it is not restarted.

dhcp6c@pppoe0 It is still in the following state:

● dhcp6c@pppoe0.service - WIDE DHCPv6 client on pppoe0

Loaded: loaded (/lib/systemd/system/dhcp6c@.service; disabled; vendor preset: enabled)
Active: inactive (dead)
  Docs: man:dhcp6c(8)

@c-po When you submit the following commit, the problem seems to be solved, when I need to do further testing tomorrow, waiting for tomorrow's daily build

jack9603301 changed the task status from Open to Needs testing.Jul 5 2020, 1:58 PM

There is already a new build containing the fix.

erkin renamed this task from Dhcp6c service can not recover when it fails. to dhcp6c service cannot recover when it fails.Aug 29 2021, 1:56 PM
erkin set Issue type to Bug (incorrect behavior).
erkin removed a subscriber: Active contributors.