Hi! Am 02.10.2017 um 17:02 schrieb Francesco Giudici:
[...] increase the DHCP timeout, which seems to translate into the time "NetworkManager keeps dhclient alive before killing it".That's right, this is the way we think should be addressed.
Ok - that seems a possible solution.
Sadly, this can only be set per connection, which makes it hard to roll this out onto a large set of servers which should use default DHCP configuration.Well, you can set it system wide. See: https://bugzilla.redhat.com/show_bug.cgi?id=1350830#c7
Sadly, also -EPERM here. We use CentOS 7, so there's no RHEL support contract. Could you maybe describe the solution given there? I would be curious to implement that on our systems.
The fact that an ipv4 connection may fail (also one with dhcp) is a feature: this would allow for instance to setup multiple connections with different priorities on the same interface, giving first a try to the dhcp connection and then falling back to another one with static ipv4 address or with 802.1x configuration.
Understood. Still I would strongly prefer it if there was an option to keep trying forever, as all other network managers I know do (dhclient, dhcpcd, any device I have encountered so far). I think this "option" I am longing for is the suggestion you describe in your last paragraph. If there is only one (DHCP) connection configured for the interface, I would even expect "trying DHCP forever" to be the default behaviour, since there is no fallback to fall back to. Does that sound reasonable? Alternatively: Is it possible to tell network manager to retry the complete activation cycle, i.e. retry all configured connections for the interface (in order) again after all have failed? In case only one connection (DHCP) is configured, this would effectively result in trying DHCP forever.
If you really want your dhcp connection to keep trying forever the only viable solution at present seems to be the ipv4.dhcp-timeout property. Maybe we could manage to keep trying also with a brand new value to the ipv4.method... see: https://bugzilla.redhat.com/show_bug.cgi?id=1350830#c1 Apart from that, there is nothing I would change.
That sounds like a good idea (for the future). Sadly, -EPERM for your link from my side. Cheers and many thanks for your detailed reply! Much appreciated! Oliver
Attachment:
signature.asc
Description: OpenPGP digital signature