| View previous topic :: View next topic |
| Author |
Message |
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
 Posted: Fri Jun 24, 2016 9:52 am Post subject: [user patch] NetworkManager and dhcp fallback profile |
 |
|
Edit: change title as the issue does not only affect dhcpcd
I'm running into a strange issue assigning a fallback IP address through dhcpcd. The assignment works just fine, but for some reason NetworkManager indicates there was a timeout. What happens next is that it goes into a loop retrying the DHCP request and eventually shuts down the interface.
| Code: | Jun 24 11:20:03 b3 NetworkManager[1417]: <info> Auto-activating connection 'LAN'.
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> (eth1): Activation: starting connection 'LAN' (8aae5b9a-007c-4597-aaa0-f129dadde9ab)
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> (eth1): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> (eth1): device state change: prepare -> config (reason 'none') [40 50 0]
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> (eth1): device state change: config -> ip-config (reason 'none') [50 70 0]
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> Activation (eth1) Beginning DHCPv4 transaction (timeout in 45 seconds)
Jun 24 11:20:03 b3 NetworkManager[1417]: <info> dhcpcd started with pid 4434
Jun 24 11:20:03 b3 dhcpcd[4434]: DUID **********************
Jun 24 11:20:03 b3 dhcpcd[4434]: eth1: IAID ******************
Jun 24 11:20:03 b3 dhcpcd[4434]: eth1: soliciting a DHCP lease
Jun 24 11:20:08 b3 dhcpcd[4434]: eth1: selected profile static_eth1
Jun 24 11:20:08 b3 dhcpcd[4434]: eth1: IAID ******************
Jun 24 11:20:09 b3 dhcpcd[4434]: eth1: probing address 192.168.10.1/24
Jun 24 11:20:14 b3 dhcpcd[4434]: eth1: using static address 192.168.10.1/24
Jun 24 11:20:14 b3 dhcpcd[4434]: eth1: adding route to 192.168.10.0/24
Jun 24 11:20:49 b3 NetworkManager[1417]: <warn> (eth1): DHCPv4 request timed out.
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): DHCPv4 state changed unknown -> timeout
Jun 24 11:20:49 b3 dhcpcd[4434]: received SIGTERM, stopping
Jun 24 11:20:49 b3 dhcpcd[4434]: eth1: removing interface
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): canceled DHCP transaction, DHCP client pid 4434
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): DHCPv4 state changed timeout -> done
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
Jun 24 11:20:49 b3 NetworkManager[1417]: <warn> (eth1): Activation: failed for connection 'LAN'
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): device state change: failed -> disconnected (reason 'none') [120 30 0]
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> Auto-activating connection 'LAN'.
Jun 24 11:20:49 b3 NetworkManager[1417]: <info> (eth1): Activation: starting connection 'LAN' (8aae5b9a-007c-4597-aaa0-f129dadde9ab)
|
If there is a DHCP server, NetworkManager almost instantly registers the assigned values.
- dhcpcd 6.10.1
- networkmanager 1.0.12
Last edited by gordonb3 on Thu Jul 07, 2016 3:19 pm; edited 2 times in total |
|
| Back to top |
|
 |
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Fri Jul 01, 2016 2:58 pm Post subject: |
|
|
Okay,
So I found that similar behaviour has been reported with e.g. wifi connections. The advised route is to use dhclient instead which I really did not want to do because I've had previous issues with one of my hook scripts in dhclient. As it stands, NetworkManager got in the way anyway and I started out by converting them into NM-dispatcher scripts (annoyingly, there are no 'old' values). So I swapped dhcpcd for dhclient today and the only change is that it gives up a lot quicker. NetworkManager simply will not accept the fallback address. |
|
| Back to top |
|
|
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Mon Jul 04, 2016 1:21 pm Post subject: |
|
|
I appear to be only answering myself.
The problem seems to be in the environment returned by the dhcp client
Response from DHCP server
| Code: | interface=eth1
requested_ntp_servers=1
reason=BOUND
new_expiry=1467702329
PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin
|
Fallback address
| Code: | interface=eth1
requested_ntp_servers=1
reason=TIMEOUT
new_expiry=1593561601
PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin
pid=2922
|
So while I do get a valid IP from the client, NetworkManager ignores it because it apparently it doesn't know how to handle "reason". Have to say that reason="TIMEOUT" is quite ugly as it does not state that there is in fact an address. DHCPCD does a better job by returning reason="STATIC", but of course this is also not accepted by NetworkManager. |
|
| Back to top |
|
|
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Wed Jul 06, 2016 8:07 pm Post subject: |
|
|
I reported this issue with the NetworkManager devs and didsome more research myself as well.
As it stands, reason=TIMEOUT as returned by dhclient in the case of fallback is rather useless. As is the fallback mehod itself, because the lease encased in dhclient.conf is overridden by the client lease file that stores the last successful lease. In essence this means that dhclient itself is quite useless for this scenario.
From what I gather, NetworkManager support for dhcpcd does in fact exist and if there were any plans to drop it those do not exist at this time. As dhcpcd does have a consistent falback IP method it is my opinion that Gentoo should change USE flags to favour dhcpcd instead of dhclient as it does now. NetworkManager development appears to be at version 1.2 while Gentoo portage tree only offers 1.0.x and as such I fear that if my suggested change is accepted it will not be in the version supported by Gentoo. Would it therefore be possible for the Gentoo devs to add a patch themselves, that lets nm-dhcp-helper accept reason=STATIC (as returned by dhcpcd) the same way as reason=BOUND? |
|
| Back to top |
|
|
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Thu Jul 07, 2016 3:18 pm Post subject: |
|
|
Turns out this is even simpler than I thought:
User-patch at /etc/portage/patches/net-misc/networkmanager/:
| Code: | --- src/dhcp-manager/nm-dhcp-client.c
+++ src/dhcp-manager/nm-dhcp-client.c
@@ -202,6 +202,7 @@
{
if (g_ascii_strcasecmp (reason, "bound") == 0 ||
g_ascii_strcasecmp (reason, "bound6") == 0 ||
+ g_ascii_strcasecmp (reason, "static") == 0 ||
g_ascii_strcasecmp (reason, "renew") == 0 ||
g_ascii_strcasecmp (reason, "renew6") == 0 ||
g_ascii_strcasecmp (reason, "reboot") == 0 ||
|
As it turns out there is an additional complication. When selecting a fallback profile, dhcpcd ignores the script parameter on its command line. This is easily overcome by adding the corresponding script directive to dhcpcd.conf, resulting in the following snippet:
| Code: | # static profile for eth1
profile default_LAN
static ip_address=192.168.10.1/24
static domain_name=localdomain
script /usr/libexec/nm-dhcp-helper
# config for eth1
interface eth1
fallback default_LAN
noipv4ll
timeout 10
|
|
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Sat Jul 09, 2016 8:18 am Post subject: |
|
|
That looks less trivial to me 
But I suppose you knew almost instantly where to look. Is there a version range I need to take into account for this patch to succeed? I noticed 6.10.1 just got marked stable for my platform (arm). Will try to include it later this weekend. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
|
Networking & Security
