[systemd-bugs] [Bug 90260] New: networkd: DHCP lease file gets deleted after carrier is lost then gained again

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Apr 30 13:59:54 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=90260

            Bug ID: 90260
           Summary: networkd: DHCP lease file gets deleted after carrier
                    is lost then gained again
           Product: systemd
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: general
          Assignee: systemd-bugs at lists.freedesktop.org
          Reporter: Jeremie.Detrey at loria.fr
        QA Contact: systemd-bugs at lists.freedesktop.org

Dear all,

I've encountered this bug on systemd 219, but it seems to still be present on
the current Git version. On a machine with a wired network connection managed
by systemd-networkd using DHCP, unplugging then plugging back the network cable
makes the corresponding DHCP lease file in /run/systemd/netif/leases disappear.

The main steps to reproduce are the following:

1. Start systemd-networkd while the machine is connected to the network and
wait for the DHCP lease. The networkd log output (with 
SYSTEMD_LOG_LEVEL=debug) for the corresponding interface (eth0 here) should
read something like:

  eth0 : flags change: +MULTICAST +BROADCAST
  eth0 : link 2 added
  eth0 : udev initialized link
  eth0 : saved original MTU: 1500
  eth0 : link state is up-to-date
  eth0 : found matching network '/etc/systemd/network/eth0.network'
  eth0 : bringing link up
  eth0 : flags change: +UP
  eth0 : flags change: +LOWER_UP +RUNNING
  eth0 : gained carrier
  eth0 : acquiring DHCPv4 lease
  eth0 : Adding address: fe80::225:22ff:fe21:c546/64 (valid for ever)
  eth0 : DHCPv4 address 192.168.10.10/24 via 192.168.10.1
  eth0 : Setting transient hostname: 'stout'
  eth0 : Adding address: 192.168.10.10/24 (valid for 12h)
  eth0 : link configured

Check the link file (/run/systemd/netif/links/2):

  # This is private data. Do not parse.
  ADMIN_STATE=configured
  OPER_STATE=routable
  NETWORK_FILE=/etc/systemd/network/eth0.network
  DNS=192.168.10.1
  NTP=
  DOMAINS=
  WILDCARD_DOMAIN=no
  LLMNR=yes
  DHCP_LEASE=/run/systemd/netif/leases/2

And the lease file (/run/systemd/netif/leases/2):

  # This is private data. Do not parse.
  ADDRESS=192.168.10.10
  NETMASK=255.255.255.0
  ROUTER=192.168.10.1
  SERVER_ADDRESS=192.168.10.1
  NEXT_SERVER=192.168.10.1
  DNS=192.168.10.1
  NTP=
  DOMAINNAME=xxxxx.lan
  HOSTNAME=stout
  CLIENTID=ff897524c100020000ab1156dbe94ec3ad23d8

2. Unplug the network cable. The log reads:

  eth0 : flags change: -LOWER_UP -RUNNING
  eth0 : lost carrier
  eth0 : DHCP lease lost
  eth0 : Setting transient hostname: ''

The lease file hasn't changed, and the link file now has
`OPER_STATE=no-carrier' (but the rest of the file is identical).

3. Plug the network cable back in. The log reads:

  eth0 : flags change: +LOWER_UP +RUNNING
  eth0 : gained carrier
  eth0 : acquiring DHCPv4 lease
  eth0 : DHCPv4 address 192.168.10.10/24 via 192.168.10.1
  eth0 : Setting transient hostname: 'stout'
  eth0 : Updating address: 192.168.10.10/24 (valid for 12h)

However, the lease file was removed:

  # ls /run/systemd/netif/leases/2
  ls: cannot access /run/systemd/netif/leases/2: No such file or directory

And even though the link file still mentions the link as configured, it has
lost its DNS configuration:

  # This is private data. Do not parse.
  ADMIN_STATE=configured
  OPER_STATE=routable
  NETWORK_FILE=/etc/systemd/network/eth0.network
  DNS=
  NTP=
  DOMAINS=
  WILDCARD_DOMAIN=no
  LLMNR=yes

>From a quick look through the source code, I think I've indentified a possible
reason for this.

In fact, the link doesn't lose its CONFIGURED state when the carrier is lost.
Then, when the cable is plugged back in, the function `link_update_flags' (in
src/network/networkd-link.c) first gets called, which in turn calls
`link_save'. At this point, the DHCP client was not restarted yet, and
`link_save' thus deletes the former lease file, as per l.2313:

        if (link->dhcp_lease) {
                [...]
        } else
                unlink(link->lease_file);

Then the DHCP client is started and eventually obtains a new lease, at which
point the function `link_client_handler' gets called. However, this function
(l.492-493) reads:

        if (link->state != LINK_STATE_CONFIGURED)
                link_enter_configured(link);

Therefore, `link_enter_configured' (which is the one responsible for calling
`link_save' after lease acquisition) never gets called, and the new lease file
never gets created.

I don't know which fix should be applied:
- either mark the link as UNMANAGED upon carrier lost, and clean up the
obsolete lease file,
- or, alternatively, allow `link_enter_configured' to be called even if the
link is already in the CONFIGURED state.

The latter requires just a quick and dirty patch in the code, but the former
sounds much more like the behaviour one might expect from networkd.

Kind regards,
Jérémie.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20150430/8c01dd08/attachment.html>


More information about the systemd-bugs mailing list