Send immediate handshake when endpoint address changes#148
Open
pappz wants to merge 1 commit into
Open
Conversation
When a peer's endpoint is changed via UAPI to a new, non-nil address while a handshake retry cycle is still mid-RekeyTimeout, force a handshake initiation right away instead of waiting out the remaining ~5s. The retry timer and the RekeyTimeout throttle are tied to the old, no-longer-valid endpoint, so the throttle is skipped on purpose: SendHandshakeInitiationOnEndpointChange() resets handshakeAttempts and calls sendHandshakeInitiation() directly, bypassing the RekeyTimeout check in SendHandshakeInitiation(). The send is guarded by needsHandshake() so an address change on a live, working session does not trigger an unnecessary rekey. Only an actual change of an already-set endpoint takes this path; first-time endpoint assignment and no-op reassignment keep using SendStagedPackets(). Signed-off-by: Zoltán Papp <zoltan.pmail@gmail.com>
Author
|
I sent the same patch to the mailing list too, but I did not get a denial or any feedback. |
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
1 participant
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.
Summary
The goal is to bring peer connections up as quickly as possible. Setting
a peer's endpoint via UAPI gives us a fresh, reachable address and is a
potential trigger for initiating a handshake.
The problem happens when the peer is already retrying a handshake with
its old, no longer valid address. The retry timer is still tied to that
old endpoint, and the RekeyTimeout throttle blocks a new handshake.
Because of this, a new working address can still wait up to one
RekeyTimeout (~5s) before a handshake is started. This delay is
unnecessary because the timer belongs to the old endpoint.
Change
This change starts a handshake from handlePostConfig() when the endpoint
address changes, so the new address is used immediately. To do this, it
skips the RekeyTimeout throttle on purpose and resets handshakeAttempts.
This is safe because the throttle was counting retries to the old
endpoint, which no longer matters.
It makes sure we only start a handshake when there is no usable session.
A healthy active session does not trigger an unnecessary rekey after an
address change.
Only changes to an existing endpoint trigger this path. Initial endpoint
setup and no-op updates keep using SendStagedPackets().