clanService/router: init #1

2026-09-21T17:05:14+07:00

kurogeek commented

2026-09-21 17:05:14 +07:00

Move modules/router to clanService, add more feature such as WiFi.

kurogeek added 8 commits 2026-09-21 17:05:14 +07:00

services/router: init 60aac6efb2

router/wifi: match BSS .network files on WLANInterfaceType=ap d4e98d8dd5

networkd enslaves the radio to br0 once, at link init. On real hardware
(GL-MT6000, mt798x-wmac) that happens while the netdev is still in station
mode, so the kernel rejects the bridge join (IFF_DONT_BRIDGE), the link is
parked in networkd's failed state and never retried: link_reconfigure_impl()
is a no-op while the matching .network file is unchanged, and the udev
'iw set type __ap' hook meant to pre-empt this loses the race. Wireless
clients associate but their DHCP never reaches vlan-lan.

Match on WLANInterfaceType=ap as well as the name. The station-mode netdev
then matches nothing (unmanaged) and the file first matches when hostapd
has switched the radio to AP and raised carrier, so the enslave succeeds
on the first try. Drop the udev hook.

Verified with checks.x86_64-linux.router (hwsim STA lease over the bridge).

router/wifi: assert no supplicant/NetworkManager owns the radios f98226bc6e

With the AP-typed match, the station-mode netdev is unmanaged until
hostapd flips it, so any wpa_supplicant/iwd/NetworkManager in the
importing config would grab the radio first and keep resetting it to
managed mode under hostapd. Fail at eval instead of at runtime.

router/dhcp: make Kea wait for its VLAN sockets 9ea058bfb8

kea-dhcp4-server orders after network-online.target, which under networkd
only waits for the WAN carrier: the vlan-* links are RequiredForOnline=no.
On stellio Kea started before networkd had addressed vlan-lan/vlan-mgmt,
failed both binds and, per its default, kept running with no socket at
all (ss -ulnp showed nothing on :67). Wireless and wired clients'
DISCOVERs reached vlan-lan and were never answered.

Set service-sockets-require-all with a bounded retry so Kea keeps trying
while networkd catches up, and Restart=on-failure on the unit for the
case it still gives up.

Verified with checks.x86_64-linux.router.

router/dhcp: drop Restart= already set by the nixpkgs kea unit 4146f2c878

router: let allowWan VLANs out through the staging uplink 8090ab3e6d

With stagingPort set, the box itself had internet over the staging DHCP
uplink but LAN/Wi-Fi clients had none: forward and masquerade were scoped
to ppp0 only. Worse, pppd's `defaultroute` refuses to install its route
while the staging DHCP default route (metric 1024) exists ("not replacing
existing default route"), so even a live PPPoE session was never used.

- firewall: forward-allow + masquerade allowWan VLANs -> stagingPort in a
  separate `router-staging-nat` postrouting chain (networking.nat only
  takes one external interface). Same allowWan set as nixos-nat.
- pppoe: `defaultroute-metric 0`, so pppd only checks for a metric-0
  default route, installs ppp0 as the preferred exit and removes it on
  hangup, leaving the staging route as the fallback.

router/tests: cover the staging uplink as NATed fallback exit e1e18dd9f3

Neither regression fixed by the previous commit was observable: the VM
test had no staging port, and pinging the ISP's PPPoE address only needs
ppp0's connected route, not the default route pppd refused to install.

Add a fifth node, `oldlan`: a networkd DHCP server on vlan 4 handing gw
its staging lease, with a second address (203.0.113.1) that gw can only
reach through that lease's default route. It has no route back to the
VLANs, so client pings only work if gw masquerades.

Proven: pppd's metric-0 default wins over the DHCP one while ppp0 is up;
lan reaches the old LAN via the staging port and iot (allowWan = false)
does not; after stopping pppd the staging route carries WAN traffic with
the same allowWan split; restarting pppd makes ppp0 preferred again.

router: make CrowdSec opt-in (crowdsec.enable, default off) 596ac1f4bb

Not every site wants the ban engine (hub sync needs internet at
activation, and it is one more moving part on a small box). Gate
crowdsec.nix on a new `crowdsec.enable` option like `omada.enable`.

gw-cnx-1 keeps it on; the VM test drops its mkForce overrides.

kurogeek requested review from grabowski 2026-09-21 17:05:29 +07:00

grabowski marked the pull request as work in progress 2026-09-22 03:21:17 +07:00

grabowski commented

2026-09-22 03:52:37 +07:00

ah so you want to connect enp3s0 to the current OPNsense and then switch everything to the new machine.
Thats a good way to do it.

looks good to me

ah so you want to connect enp3s0 to the current OPNsense and then switch everything to the new machine. Thats a good way to do it. looks good to me

kurogeek commented

2026-09-23 12:58:33 +07:00

Well, that's one way to look at it also. But my perspective is to test if things work on clients. And it's working so far.

kurogeek marked the pull request as ready for review 2026-09-23 12:58:40 +07:00

kurogeek merged commit d8f7d4e9ca into main

2026-09-23 12:58:54 +07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: B4L/cnx-network-clan#1