# [user patch] NetworkManager and dhcp fallback profile

## gordonb3

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.

```
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.12Last edited by gordonb3 on Thu Jul 07, 2016 3:19 pm; edited 2 times in total

----------

## gordonb3

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.

----------

## gordonb3

I appear to be only answering myself.

The problem seems to be in the environment returned by the dhcp client 

Response from DHCP server

```
interface=eth1

requested_ntp_servers=1

reason=BOUND

new_expiry=1467702329

PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin

```

Fallback address

```
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.

----------

## gordonb3

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?

----------

## gordonb3

Turns out this is even simpler than I thought:

User-patch at /etc/portage/patches/net-misc/networkmanager/:

```
--- 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:

```
# 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

```

----------

## UberLord

 *gordonb3 wrote:*   

> As it turns out there is an additional complication. When selecting a fallback profile, dhcpcd ignores the script parameter on its command line.

 

Sorry about that.

Luckily, the fix is almost as trivial as your one to NetworkManager ..... here:

http://roy.marples.name/projects/dhcpcd/vpatch?from=9a7d4ae7c8cb2387&to=676037aa5b82146d

----------

## gordonb3

That looks less trivial to me  :Laughing: 

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.

----------

## UberLord

Should apply to apply 6.x versions.

----------

