Network Modes

Network-Modes — how the box sits on the network 🔵

EN | FR | 🔵 MESH | package secubox-netmodes

What it is for

Network-Modes chooses and shows the topology of the box: router, inline or passive sniffer, access point, relay. The page tells the truth about the current state: a mode is never invented, the Internet exit is read from the default route, and applying a mode needs an explicit confirmation that warns the connection may be cut.

Demonstration capture (fictitious data). Panel: /netmodes/ · API: /api/v1/netmodes/ · config: /etc/secubox/netmodes.toml. It ships in the secubox-lite profile (see Modules-by-Profile).

---

The modes

Id	Name	Role
router	Router	full NAT router with DHCP, NAC and DPI
sniffer-inline	Inline sniffer	transparent bridge with dual-stream DPI (tc mirred)
sniffer-passive	Passive sniffer	out-of-band monitoring on a SPAN/TAP port
access-point	Access point	Wi-Fi AP 802.11r/k/v with band steering
relay	Relay/Extender	network relay with WireGuard VPN and tuned MTU

What changed in 1.3.0

• The mode is never made up. With no recorded state, GET /status and GET /get_current_mode answer "unknown" (mode_connu: false) instead of the former default "router".
• The WAN comes from the default route. /status adds the interface and gateway of the default route with the lowest metric. Blocking ip calls run in a thread, because the module is served inside the aggregator.
• Confirmed application. Applying a mode and restoring the backup go through an in-page confirmation (never confirm()), with a warning that the connection may be cut.
• Honest page. The WAN, LAN and bridge forms saved nothing yet displayed "saved": they are removed. The page called two routes that do not exist (/interfaces, /current_mode, hence "No interfaces"); it now uses /status and /get_available_modes.
• Hardware detection is shown from secubox-net-detect when present. That helper is shipped by no package at the moment, and the page explains its absence without raising an alarm.

How a change is applied

1. POST /set_mode records a pending mode without applying it.
2. POST /apply_mode backs up the current netplan files, renders the mode template into 00-secubox.yaml (if the template exists, otherwise netplan is left unchanged), runs netplan apply, then records the mode only if it succeeded.
3. POST /confirm_mode confirms the new mode works; POST /rollback restores the last backup and applies it again.

GET /preview_changes?mode=… returns the netplan YAML that would be applied. MSS clamping goes through a dedicated nftables table (secubox_netmodes_mss), never iptables.

The routes above need an administrator token (require_jwt).

See also

Architecture · NAC · DPI-Vivant · Hardware-Matrix · Modules-by-Profile · Modules-by-Family · Admin-Panels-Gallery