-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DHCP6: lastlease behavior after Confim non-response #387
base: master
Are you sure you want to change the base?
Conversation
If lastlease is enabled, and dhcpcd is unable to confirm its prior lease, after timeout, don't continue to solicit. Confine lastlease behavior to only the CONFIRM state.
dhcp6_bind(ifp, NULL, NULL); | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why return?
We couldn't find any DHCPv6 server, so we do use the last lease, but we should retry and DISCOVER yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Soliciting for a lease while using the current one could lead to problems if the DHCPv6 server has ping checking enabled, in the case where you come back up on the same network. We've seen it fail the ping check (ie, gets a response) and issue a new IP address when that happens, thinking there's an address conflict. I think making this behavior optional with the lastlease option allows everybody to choose which way they want to go, since it is kind of a couple of competing requirements we're trying to untangle here. What do you think?
@@ -1760,8 +1760,9 @@ dhcp6_fail(struct interface *ifp, bool drop) | |||
dhcp_unlink(ifp->ctx, state->leasefile); | |||
dhcp6_addrequestedaddrs(ifp); | |||
eloop_timeout_delete(ifp->ctx->eloop, NULL, ifp); | |||
} else if (state->recv && ifp->options->options & DHCPCD_LASTLEASE) { | |||
} else if (state->state == DH6S_CONFIRM && ifp->options->options & DHCPCD_LASTLEASE) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also allow the state DH6S_REBIND please?
IF you ask for a Prefix Delegation you REBIND, otherwise CONFIRM and ideally we want the behavior in both states.
And we should still check state->recv to ensure we ARE using the last lease in this state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'm not seeing any issues with those changes in my own testing.
If lastlease is enabled, and dhcpcd is unable to confirm its prior lease, after timeout, don't continue to solicit. Confine lastlease behavior to only the CONFIRM state.
This cleans up some minor issues with the initial commit for DHCPv6 lastlease.