On Mon, Oct 02, Andrei Borzenkov wrote:
02.10.2017 18:22, Olaf Hering пишет:On Mon, Oct 02, Francesco Giudici wrote:With that anyway you miss the option of having different connections that could fallback if the "primary" one with dhcp fails.How is it a failure if the DHCP server disappears, perhaps right after it provided a lease? Well, there is likely some blurb in the RFCs about what must be done when the lease expired.RFC requires that when upon lease expiration client stop using address (actually it literally says "stop any network activity") and return to initial state of acquiring address.
Thanks for digging into it. I vaguely remember it from my work on wicked. I assume the dhcpcd binary assigns the address to the kernel inteface. If thats the case, then it is most likely also the responsibility to remove the address again. I think thats not done, but I have not verified when this happened. But whatever dhcpcd does, it is not relevant to the bug discussed here. At some point the configuration worked as expected: "the interface" got a DHCP reply and was therefore "up and running and fine", from NM point of view. Just because the DHCP server is not available at some point does not make "the interface" configuration broken or wrong. NM has to keep going with what was configured. It is the job of dhcpcd to reobtain a lease. In the other replies it sounds like it is a requirement to specifically configure NM not to fail in this scenario. This sounds backwards. But it matches what must be done in other places, like autostart of bridge slaves. In other words, the common case must be explicitly configured... Olaf
Attachment:
signature.asc
Description: PGP signature