Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity

task-49: measured on the phone — #1 holds, #2 broke and is fixed

Browse source 
home_ssids needs a list: Samaritan Solutions and TheTholianWeb both lease from
10.10.20/24 (.234 and .245). Three defects only hardware showed: reapply clat
wipes the CLAT daemon's routes including the MMS /32; the gsm connection is the
wrong lever because the v4 carrier default comes from the clat tun at 2048; and
wg show needs CAP_NET_ADMIN that a user unit will never have.
This commit is contained in:
Fimeg 2026-08-01 14:59:13 -04:00
commit 55a44239ff
1 changed files with 44 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

46
docs/tasks/49-bearer-selection-as-device-state.md
View file

@ -335,8 +335,50 @@ the real reason the tunnel does not return after a reboot, and flipping it is
the user's call, not this task's — the constraint above says the switch stays
the user's authority. Worth a decision, not a silent default.
Still to do, in order: set `home_ssids` on the device (`set_policy`), then work
the acceptance list. `dns=systemd-resolved` remains untouched and is what makes
### Measured on the phone, 2026-08-01, running the real thing
`home_ssids` is set to `["Samaritan Solutions", "TheTholianWeb"]`. It needed to
be a *list*: both lease from the home LAN — `Samaritan Solutions` gave
`10.10.20.234` (the phone's documented home address) and `TheTholianWeb` gave
`10.10.20.245`. A single-SSID answer would have been wrong half the time. The
evidence is in NM's own lease files under `/var/lib/NetworkManager/`, which is
the identity check the /16 prefix test should always have been.
**Acceptance #1 holds.** On `Mabee 19` with cellular also up:
`default via 10.10.30.1 dev wlan0 metric 600`, wifi profile at 600 and the
readout at `applied: wifi`, `home: false`, `ssid: "Mabee 19"`.
`ip route get 1.1.1.1` leaves by wlan0. That is the 2026-07-31 inversion
corrected.
**Acceptance #2 was broken by the first action and is now fixed.** Two defects,
both only visible on hardware:
1. **`nmcli device reapply clat` destroys the carrier's routes.** After one
`PreferLink` the clat device was up with its `192.0.0.1/32` and *zero*
routes — no default, and no `205.151.11.13/32`. `ip route get
205.151.11.13` went out wlan0. `reapply` resets a device to its
*connection's* config, and every clat route is written by the CLAT daemon
outside NM. Restored with `systemctl restart blueline-clat.service`; the
code now reapplies only `wlan0`. **Never reapply a device whose routes NM
did not write.**
2. **The `gsm` connection is the wrong lever.** The modem is v6-only; the v4
default for the carrier is `default dev clat scope link metric 2048`,
installed by the CLAT daemon. A `route-metric` on the gsm connection is a
number nothing reads. Wifi's metric is the only lever there is — under 2048
wifi wins, over it the carrier does — which is also why 2048 belongs in the
code as a named reference rather than a guess.
**And a privilege defect the tests could not catch.** The tunnel read `off`
while `wiufph` was up and handshaking (`4.11 KiB received`). `wg show` needs
`CAP_NET_ADMIN` and sessiond is a systemd *user* unit, so it can never read
peer data — "Unable to access interface wiufph: Operation not permitted".
Replaced with `/sys/class/net/*/statistics/rx_bytes` plus `DEVTYPE=wireguard`,
both world-readable and the same number. The endpoint lookup had it too, and
is now read from `nmcli -g wireguard.peers` — where it turns out to be a
*hostname* (`sub.wiuf.net:51822`), not the address the old gate hardcoded.
Still open: acceptance #3–#5, and `dns=systemd-resolved`, which nothing here
touches and which is what makes `~wiuf.net` mean anything. `dns=systemd-resolved` remains untouched and is what makes
`~wiuf.net` mean anything; nothing here addresses split DNS.
## Acceptance