doublehop: switching from an active connection races the old tunnel's teardown #202

New issue

Closed

opened 2026-08-29 00:48:35 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-29 00:48:35 -04:00

Owner

The race: establish_connection kills the current main tunnel and immediately launches the hop leg, whose pin via the physical link only lands at --up. Its handshake traffic therefore rides the dying tunnel's def1 routes; when they vanish mid-handshake, the PUSH reply is lost. OpenVPN would retry — but both clients kill the attempt on the first conn_attempt_failed_hop (the gui always has; the cli since #201), so the attempt dies. A single-hop switch survives the same race because nothing kills it before the retry succeeds.

Fix shapes, in rough preference order:

Pin the hop endpoint via the physical gateway before launch (tunnel.py already does exactly this pre-launch pin for the bypass role) — folds naturally into the #176 reshape, where all hop routing moves into Python anyway.
Have the service delay the new attempt until the old tunnel's teardown completes.
Make clients tolerate the first hop-leg retry instead of killing on it.

Probably best absorbed into #176 rather than fixed standalone.

Seen live 2026-08-29 while validating #201: with a single-hop connection up, launching a doublehop attempt fails after ~60s with no-push-reply, while the same pair connects reliably from a fresh disconnect. The race: establish_connection kills the current main tunnel and immediately launches the hop leg, whose pin via the physical link only lands at --up. Its handshake traffic therefore rides the dying tunnel's def1 routes; when they vanish mid-handshake, the PUSH reply is lost. OpenVPN would retry — but both clients kill the attempt on the first conn_attempt_failed_hop (the gui always has; the cli since #201), so the attempt dies. A single-hop switch survives the same race because nothing kills it before the retry succeeds. Fix shapes, in rough preference order: 1. Pin the hop endpoint via the physical gateway before launch (tunnel.py already does exactly this pre-launch pin for the bypass role) — folds naturally into the #176 reshape, where all hop routing moves into Python anyway. 2. Have the service delay the new attempt until the old tunnel's teardown completes. 3. Make clients tolerate the first hop-leg retry instead of killing on it. Probably best absorbed into #176 rather than fixed standalone.

mysticalsoap referenced this issue from a commit

2026-08-29 14:27:01 -04:00

change: route the double hop from Python, not --up hooks

mysticalsoap referenced this issue from a pull request that will close it,

2026-08-29 14:27:14 -04:00

change: route the double hop from Python, not --up hooks #211

mysticalsoap referenced this issue

2026-08-29 18:06:43 -04:00

change: route the double hop from Python, not --up hooks #211

mysticalsoap referenced this issue

2026-08-30 11:55:10 -04:00

change: route the double hop from Python, not --up hooks #211