DHCPv6 suspend fixes - #1356
Merged
Merged
Conversation
Prevent modifications to index, MAC address, DUID and Information Request while the DHCPv6 client is running. Require the DHCPv6 client to be stopped first instead of always unconditionally restarting it if the caller calls sd_dhcp6_client_start() more than once. With this change, handling of for example incoming Router Advertisments becomes much easier.
Update the test case to stop the ongoing Information Request exchange before unsetting its state. To keep the test case callback verification simpler, temporarily unset the callback function before stopping.
Whenever a Router Advertisement is received, dhcp6_configure() will be called. A Router Advertisment can also instruct DHCPv6 to start acquiring IPv6 addresses in manged mode, if it previously was handling only other information. As an Router Advertisment is also received after the DHCPv6 client has resumed from a suspend, fix the function not to assume DHCPv6 is currently running, but instead try to restart it. Handle sd_dhcp6_start() returning -EALREADY indicating that the DHCPv6 client was already running. Collect all client unrefs in one place to unclutter the error handling. Fixes systemd#963
Wait until DHCPv6 has acquired an address before announcing the link to be configured. Log the DHCPv6 lease lost event.
Contributor
Author
|
I try to remember - or actually unlearn - those nitpicks in the future... |
Contributor
|
This caused a regression, see issue #1368 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This patch set fixes DHCPv6 to reacquire and address after a resume and fixes the issue reported in #963.
The third patch in the series fixes handling of a received Router Advertisment by updating the DHCPv6 client if the client was doing an Information Request, and starts the client DHCPv6 address acquisition procedure if a link->dhcp6_client already existed. In order not to restart the DHCPv6 client all the time, patch 1/4 prevents a running client from re-starting by returning -EALREADY in situations where it is already running. This makes subsequent Router Advertisment handling much easier.
Since patch 1/4 checks the client status before allowing it to start, other similar checks were implemented at the same time for settings that should not be changed run-time. Patch 2/4 updates the test case to account for these changes.
As an added bonus, the fourth patch updates link configuration to wait for DHCPv6 to acquire an address before declaring that the link is configured.