Skip to content

v1.2.0 - passive watchdog (stability)

Choose a tag to compare

View all tags
@enesilhaydin enesilhaydin released this 11 Jun 10:53
· 7 commits to main since this release
v1.2.0
d763408

Reworks the watchdog to be passive, fixing iptables churn and a self-inflicted leak window introduced by over-aggressive order-policing.

What was wrong

Previous versions ran a 10s sweep plus an ip monitor link listener, both policing FORWARD rule order and re-lifting the hook to the top whenever another module (e.g. vpn-gateway) inserted a rule above it. On a device running both, this became a tug-of-war over the top slot:

  • constant iptables -D/-I churn + high CPU
  • a sweep storm on every link event
  • brief windows where the kill switch was momentarily removed during the delete-then-reinsert — i.e. the safety mechanism created its own leak window

Why order never mattered

Every vpn-gateway ACCEPT is qualified with -o tun0 / -i tun0. With the VPN down, tun0 has no route, those ACCEPTs can't match, and the packet still reaches our REJECT — regardless of where our hook sits. With the VPN up, the traffic is meant to pass anyway. Verdict is identical either way: blocked when VPN down, allowed when VPN up.

Changes

  • Removed ensure_top() (order policing) entirely.
  • Removed the ip monitor link event listener (sweep-storm source).
  • Watchdog cadence 10s → 60s, fully passive: writes to iptables only when a hook is genuinely missing or duplicated. Steady state = read-only checks, zero writes.
  • post-fs-data hook install made idempotent too (no churn across the 90s boot retry).
  • README: new Why the watchdog is passive section with the position-irrelevance proof.

Guarantees unchanged

Kill-switch behaviour is identical: VPN down → hotspot blocked, VPN up → traffic flows. This release only removes harmful churn; it does not relax protection. In fact it removes the order-churn leak window.

Note

If your hotspot internet drops ~20-60s after connecting, that is most likely a WireGuard endpoint routing-loop / handshake issue (the routing module's domain), not this kill switch. Use scripts/diag.sh up / down to confirm — it auto-flags wg_endpoint_via_tunnel=LOOP_BAD.

Assets 3
Loading