DHCP: Add an upper bound to the renew/rebind timeout in RetryConfig
#835
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.
Description
This lets the user set an upper bound on the duration between times smoltcp sends a renew or rebind by setting a
max_renew_timeout
field to DHCPRetryConfig
struct, which defaults to not imposing a cap unless the user explicitly sets one.Design questions
Use of this feature doesn't follow the official DHCP spec, but the
RetryConfig
struct already has amin_renew_timeout
field which breaks the same spec by allowing the user to change the lower-bound imposed, so I think this is reasonable to add. Feel free to close this PR if you disagree.I also added
#[non_exhaustive]
to theRetryConfig
struct because this addition will necessarily be backwards incompatible and ineligible for inclusion untilv0.11.0
, but marking it as#[non_exhaustive]
will allow anyone else in the future who wants more configuration options to add them without breaking backwards-compatibility. I can remove this attribute and let any future additions also require a major change instead.I also didn't put any checks for the user putting
max_renew_duration
smaller than the existingmin_renew_duration
. If they do, then they'll silently getmax_renew_duration
as the chosen value every time. I think this is a reasonable response to an unlikely scenario, but I can do something else instead if you prefer.Validation
The existing unit tests cover logic in the case where no upper bound is set. I added a new unit test that covers the user setting a custom upper- and lower- bound to ensure that this behavior acts correctly.
I also have a firmware setup which uses this DHCP client that I switched to using this branch and set the maximum, and observed it capping at the maximum like expected.