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

upgrade clobbers a correct gatewayinterface rename: setup_nodogsplash unconditionally resets it to br-lan (#757 stack-interaction)

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

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

Research direction

Start in the setup_nodogsplash function in the 99-tollgate-setup script, where gatewayinterface is set to br-lan unconditionally. Read the adoption pattern in #785 and #786, and check where the 00-defs renderer reads gatewayinterface relative to the setup pass. Done means an installed, existing bridge is kept across upgrades, stock br-lan is used only for fresh or invalid cases, and each non-stock decision is logged.

Written by the indexing model from the issue text.

Description

Class: upgrade-time config clobber on a correctly-renamed router

setup_nodogsplash in 99-tollgate-setup runs uci set nodogsplash.@nodogsplash[0].gatewayinterface='br-lan' unconditionally. A full setup pass — which every package upgrade performs — therefore reverts an operator's correct, working portal-bridge rename to the stock literal.

Evidence (rc1-cluster rel-cluster transcript, #757 re-verify leg)

  • Renamed router: bridge br-portal, network.portal.device='br-portal', nodogsplash…gatewayinterface='br-portal' — a coherent, working renamed state (the #784 defines render $tg_portal_if = "br-portal", NDS serves).
  • Package upgrade runs the full setup pass: BEFORE=br-portal AFTER=br-lan — the gatewayinterface is reverted while network.portal still owns br-portal.
  • The mixed state is the worst of both: NDS dies outright (gatewayinterface no longer exists as a bridge — the #757/#756 verdict signature), and on the next renderer pass the 00-defs flip $tg_portal_if to br-lan, so the nft guards and the zone resolver follow a bridge that isn't the portal. Nothing warns that the rename was discarded.

Why this is its own issue (not folded silently into #784)

The #757 bench-verify verdict flagged it as a stack-interaction finding needing a follow-up before merge: the fix touches install-vs-upgrade convergence semantics and the renderers' read timing — the defs renderer reads gatewayinterface from uci mid-setup, before the setup pass commits (staged state is readable and is what the renderers should see, but the ordering inside setup_nodogsplash must keep the adoption decision ahead of the render calls).

Fix shape (the verdict's recommendation, and the in-tree precedent)

Adopt-if-installed, exactly the pattern #785 shipped for firewall zone refs and #786 for the AP binding: when an installed gatewayinterface exists, is a usable ifname, and its bridge exists on the router, keep it (it is the deployed portal plane); set br-lan only for a fresh install, an empty/garbage value, or a bridge that does not exist — and log every non-stock decision. The adoption must run before the two renderers in the same setup pass so the defs and allowlist fragments follow the adopted interface, not the stock one.

References: #757 (the verdict's stack-interaction note), #784 (the defines that make the clobber's blast radius whole-router), #785/#786 (the adoption pattern), #755 (same convergence discipline).

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

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.