Re: Loss of Network Adress is DHCP Server failed for some hours

Hash: SHA256

On 02/10/2017 17:53, Oliver Freyermuth wrote:

[...] 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.

Sorry, I did not realized access to that bugzilla was restricted.
Put the relevant info in the answer to Olaf.

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

Something is already there on upstream master. You can do:
nmcli con mod $CON ipv4.dhcp-timeout infinity

but it is available via nmcli only...

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.

Yes, this seems reasonable.
Maybe keep periodically trying activation of connection with
auto-activate enabled that point to an interface with no active
connections on top of it.

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: 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.
Sorry, link to the same bugzilla as above.
Summing up, basically, what could be taken into account is to review
the meaning of ipv4/ipv6.may-fail=yes: we can keep retrying dhcp while
keeping the connection active.
This would solve all the complains while leaving the "stop" behavior
there if one chooses may-fail=no.



Cheers and many thanks for your detailed reply! Much appreciated!




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]