Description of problem: When I resume my system from suspend the DHCP lease is not re-aquired. I've been having this problem for a long time now and finally decided enough is enough and file a bug. This is 100% reproducible when resuming past the lease expiry time. Version-Release number of selected component (if applicable): NetworkManager-1.0.10-3.fc23.x86_64 How reproducible: always Steps to Reproduce: 1. see description 2. 3. Actual results: Expected results: Additional info: # cat ifcfg-br0 DEVICE=br0 STP=yes DELAY=2 BRIDGING_OPTS=priority=32768 TYPE=Bridge BOOTPROTO=dhcp DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no NAME=br0 UUID=f800560b-c921-4988-b247-576e27be5c69 ONBOOT=yes # cat ifcfg-enp3s0 HWADDR=BC:5F:F4:88:F9:3F TYPE=Ethernet NAME=enp3s0 UUID=66860be1-8c9b-4b1e-a1f7-d3d1dfff4725 ONBOOT=yes BRIDGE=f800560b-c921-4988-b247-576e27be5c69
To make it a bit clearer: not re-acquiring the lease results in loss of connectivity since the IP addresses disappear. This goes for both IPv4 and IPv6. Only the IPv6 LL address remains
(In reply to Ferry Huberts from comment #0) > Description of problem: > When I resume my system from suspend the DHCP lease is not re-aquired. I'm not able to reproduce this, can you please attach debug logs (to enable debug logging set level=DEBUG in the [logging] section of /etc/NetworkManager/NetworkManager.conf and restart NM). Thanks.
(In reply to Beniamino Galvani from comment #2) > (In reply to Ferry Huberts from comment #0) > > Description of problem: > > When I resume my system from suspend the DHCP lease is not re-aquired. > > I'm not able to reproduce this, can you please attach debug logs (to enable > debug logging set level=DEBUG in the [logging] section of > /etc/NetworkManager/NetworkManager.conf and restart NM). Thanks. Did you try to resume _later_ than the lease expiry time?
(In reply to Ferry Huberts from comment #3) > > Did you try to resume _later_ than the lease expiry time? Yes, but since I ATM I don't have available a physical ethernet giving short leases I used a veth pair with the DHCP server on one end in a different net namespace. That seems to work, the address is renewed properly after the resume. Maybe using physical interfaces it's different though, because we unmanage them before going to sleep.
What I see is that the interface comes back with all IP addresses, only to lose them again once the renewing starts (and fails) I'll try a debug run over the weekend on this machine.
(In reply to Ferry Huberts from comment #5) > What I see is that the interface comes back with all IP addresses, only to > lose them again once the renewing starts (and fails) > > I'll try a debug run over the weekend on this machine. Thanks. Is there any clue in normal logs about why the renewal is failing?
Created attachment 1142087 [details] NM debug log Finally it triggered. This file contains the log between last evening and this morning. The system was suspended this night and resumed this morning. It triggered almost instantly.
Probably related to https://bugzilla.gnome.org/show_bug.cgi?id=764398
yes it is, so that one is a dup of this one (or the other way around)
please apply the fix to F23 :-)
Upstream bugzilla patch applied to branch nm-1-0: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-0&id=5476ea5c452a67c0ec12a94d26a1e8321c6a1b6b
Just had this again this morning. NetworkManager-1.0.12-1.fc23.x86_64
And again. I think this one is reproducible. I woke the system from suspend, worked a bit, and then started a VPN connection. At that exact moment my bridge lost its IPv4 address (the VPN is IPv4). Please re-open the bug
And again. Same scenario NetworkManager-1.0.12-2.fc23.x86_64 Please re-open!
(In reply to Ferry Huberts from comment #14) > And again. > Same scenario > > NetworkManager-1.0.12-2.fc23.x86_64 Hi, it's strange that the patch from comment 11 didn't solve the problem as now after waking up the DHCP should be unconditionally restarted. Do you see in logs if this is the case? Also, I don't think that the lease could expire during suspend, because kernel measures the lease in jiffies (which stop during suspend). I will try to set up a test to reproduce this. > Please re-open! Well, this is not closed yet, only in POST, meaning that there's a proposed fix under review.
This is reasonably well reproducible for me, same scenario: resume, do some work, open VPN connection: boom, IPv4 address gone. Just had it again
(In reply to Ferry Huberts from comment #16) > This is reasonably well reproducible for me, same scenario: resume, do some > work, open VPN connection: boom, IPv4 address gone. I tried the same scenario again today with 1.0.12: bridge with ipv4 and ipv6 set to auto, and a physical ethernet interface enslaved. For me the result is that DHCP is restarted after the resume. Since version 1.0.12, NM should force the renew after a sleep, could you please attach again debug logs so that we can analyze why that is not happening? And maybe also the output of 'ip a' for the bridge and ethernet immediately after the resume and when the connectivity is lost? Thanks!
It doesn't happen after resume nowadays: it happens when I open up a VPN connection after working for a while after resume. And the bridge only loses its IPv4 address, all IPv6 address are still there (the VPN is IPv4) So clearly there is something else going on.
I'm not seeing this on F24. I've reinstalled the affected F23 system with F24 a while ago.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.