After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770329 - dhcp=internal never gives up on unresponsive DHCP server, activation never completes
dhcp=internal never gives up on unresponsive DHCP server, activation never co...
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-08-24 11:26 UTC by Tore Anderson
Modified: 2016-08-25 13:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dhcp=internal connection attempt that doesn't complete (64.66 KB, text/plain)
2016-08-24 11:26 UTC, Tore Anderson
  Details
successful connection attempt using default dhcp client (38.83 KB, text/plain)
2016-08-24 11:27 UTC, Tore Anderson
  Details
[PATCH] dhcp/systemd: honor timeout for DHCPv6 (881 bytes, patch)
2016-08-24 13:27 UTC, Beniamino Galvani
none Details | Review

Description Tore Anderson 2016-08-24 11:26:58 UTC
Created attachment 334072 [details]
dhcp=internal connection attempt that doesn't complete

When using dhcp=internal and attempting to activate a connection where the RA indicates that there's information to be found in DHCP (O-flag set) but the DHCP server isn't responding, the connection activation never completes. Instead it keeps retrying the DHCP request forever. The general state is stuck in "activating", dispatcher scripts aren't invoked, and so on.

While activating the same connecting sing the default DHCP implementation, the DHCP request quickly reaches a timeout, and the connection activation completes successfully, the dispatcher scripts are invoked, and all is well.

It is admittedly a network misconfiguration to have an RA say there's information in DHCP while not actually have a functioning DHCP service, but it's probably not that uncommon, and I think it would be best if NM w/dhcp=internal handled it as well as it does with the default DHCP client. For what it's worth, in my case the misconfiguration is caused by a firmware bug in my laptop's 3G WWAN module so it's not really something I can easily fix.

I'm attaching two logs, one with a connection attempt with dhcp=internal (that I manuall cancel after over 30 minutes), and then a connection attempt with the default DHCP client where a timeout is reached after 20 seconds after which the connection completes activation.
Comment 1 Tore Anderson 2016-08-24 11:27:31 UTC
Created attachment 334073 [details]
successful connection attempt using default dhcp client
Comment 2 Beniamino Galvani 2016-08-24 13:27:09 UTC
Created attachment 334079 [details] [review]
[PATCH] dhcp/systemd: honor timeout for DHCPv6
Comment 3 Thomas Haller 2016-08-24 13:42:27 UTC
lgtm