Networkd fixes related to carrier status #6116
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the link comes up it assigns addresses by checking whether the address is 0.0.0.0, and if so pulling a new address range out of the pool. If the addresses aren't removed from the pool when the link goes down then the set of addresses allocated will grow until all the local address ranges are exhausted, while it gets a different IP address every time. This patch frees the addresses when link config is dropped to fix the address leak, and on systems which can expect all interfaces to be brought up or down in a deterministic order this conveniently makes use the same address each time.
For containers the link is effectively always up, but for virtual and physical machines networkd may have started before the link has gained carrier. Networkd will configure addresses when carrier is gained, but should also configure addresses if the link is already up. Without this patch the addresses are set unconditionally. Normally this isn't a problem since addresses are either fixed, set over DHCP, or is never without carrier. But for machines that gain carrier and are configured to select an address from the unallocated local address pool this causes them to pick an address from the pool twice. This change to skip address configuration when a link is added before it has a carrier fixes having multiple addresses assigned if the machine starts networkd before it has gained carrier and is configured with an address from the pool.
In normal operation this would trigger an assertion when a DHCP server is configured every time the link goes up. This change makes sd_dhcp_server_configure_pool idempotent and stops the DHCP server when the link loses carrier. In addition to this stopping the assertion being triggered, this has the useful side-effect of allowing the link to be taken down and then brought back up as a way to have it use DNS from an "upstream" interface that got its DNS configuration via DHCP after the downstream link was configured.
|
The error from the xenial-i386 autopkgtest appears to be a failure to start the virtual machine in openstack rather than a test failure. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I encountered issues while using networkd's picking an address form a pool and DHCP server when used on a dev-board. I've been able to reproduce these issues with virtual machines too.
Apart from the issues fixed with the patches below, the DHCP lease DNS record propagation logic is interface enumeration order dependant, so if the downstream link is configured before the upstream one then the downstream link won't get the DNS records.
I've not yet had time to look at how to fix that, but being able to take the downstream link down and bring it back up again provides a work-around.