Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

upstream auto-manager races manual 'upstream connect' — counter-switches back to a disabled section mid-join

Open
#880 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Amperstrand is already working on this.

Since Oct 14, 2026.

  • #936 by @Amperstrand — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go

Research direction

Start in src/cli/server.go at handleUpstreamConnectStreaming and trace how it calls SwitchUpstream and PauseConnectivityChecks; then inspect the manager’s periodic connectivity tick. Reproduce the race described in the issue with a manual connect that waits for DHCP while a tick fires. Done means the manager cannot counter-switch during the manual join and the behavior is covered for completion and failure paths.

Written by the indexing model from the issue text.

Description

Summary

The upstream connectivity manager's periodic tick can fire during a manual tollgate upstream connect's DHCP wait and switch the radio to a different section — in the measured case, back to the stale foreign section the connect flow had just disabled — re-enabling it and preventing the join from ever completing.

Evidence (bench, 2026-10-11)

From the #817/#848 gate-run session (Pi 4 / brcmfmac / single radio; logread timeline):

08:20:41 tollgate-wrt: Creating new named STA interface   interface=upstream_2 ssid=2
08:20:41 tollgate-wrt: Switching upstream                 active=tollgate_uplink candidate=upstream_2 ssid=2
08:21:08 tollgate-wrt: Switching upstream                 active=upstream_2 candidate=tollgate_uplink ssid=2
08:23:42 tollgate-wrt: WARN Timed out waiting for DHCP, reverting to previous upstream  candidate=upstream_2 ssid=2

The manual flow disabled tollgate_uplink (its competitor sweep, #848) and enabled upstream_2; 27 seconds later — one 30 s connectivity tick (upstream_wifi.fast_check_seconds) — the auto-manager observed the transient loss, picked the known candidate tollgate_uplink, and switched to it (its own switch path re-enables its candidate). The join never had a stable radio after that.

Root cause

handleUpstreamConnectStreaming pauses the manager only after success — src/cli/server.go calls s.upstreamManager.PauseConnectivityChecks(s.manualPauseDuration()) after SwitchUpstream returns nil. During the switch window — up to dhcp_timeout_seconds (default 180 s) — the manager is live, and with a 30 s tick it is essentially guaranteed to fire mid-join whenever the churn reads as a connectivity loss.

Interaction with #848: the manager's counter-switch re-enables exactly the section the competitor sweep disabled, so this race can undo those guarantees on single-radio devices.

Repro / workaround

Any manual connect on a radio where the tick observes the churn. Bench workaround used during the gate run: park the tick first ("fast_check_seconds" and "scan_interval_seconds" set large in the service config, then restart).

Suggested fix shape

Either pause the connectivity checks for the manual-pause window before the switch starts (the handler already computes the duration — move the pause ahead of the SwitchUpstream call and unpause on completion/failure), or make the manager decline to act on radios with an in-flight manual switch. Either way, the connect flow and the manager must not both drive the radio.

Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 6h
Merged PRs (30d)
235

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenTollGate/tollgate-module-basic-go

All issues in OpenTollGate/tollgate-module-basic-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.