fix: name and version from system_information; a CARP address on its MASTER's interface #20

Merged
christianmanivong merged 1 commits from fix/hostname-and-carp-addresses into master 2026-10-16 13:50:03 +00:00
Owner

Two gaps found after NetOrk/netork#1121 went live:

get_facts read hostname and os_version from /api/core/system/status. On OPNsense 26.7 that endpoint only carries metadata/subsystems, so both firewalls read as nameless and unknown, and netOrk kept naming gw-02 "172.22.8.3". The driver now reads /api/diagnostics/system/system_information: name is the FQDN (hostname = first label), versions[0] = OPNsense 26.7.7-amd64, which becomes 26.7.7. The status answer still counts where the new one gives nothing (older version, API key without the diagnostics privilege).

get_interfaces_ip listed each interface's primary address only, so a CARP address never showed up as the holder's address. That is what netOrk's VIP badge hangs on. Now an address bound to a VHID is listed on the node that is MASTER for it and left off a BACKUP, the same way keepalived puts the address on the master alone. A failover moves it with the next poll. get_networks is unchanged.

Checked read-only against both gateways: gw-02 → gw-02 / gw-02.home.manivong.de / 26.7.7. gw-01 carries its 21 CARP addresses (45 IPv4 addresses instead of 24), gw-02 only its own 24.

Tests: tests/unit/test_identity_and_held_addresses.py. Suite 387 passed.

Two gaps found after NetOrk/netork#1121 went live: **`get_facts`** read `hostname` and `os_version` from `/api/core/system/status`. On OPNsense 26.7 that endpoint only carries `metadata`/`subsystems`, so both firewalls read as nameless and `unknown`, and netOrk kept naming gw-02 "172.22.8.3". The driver now reads `/api/diagnostics/system/system_information`: `name` is the FQDN (hostname = first label), `versions[0]` = `OPNsense 26.7.7-amd64`, which becomes `26.7.7`. The status answer still counts where the new one gives nothing (older version, API key without the diagnostics privilege). **`get_interfaces_ip`** listed each interface's primary address only, so a CARP address never showed up as the holder's address. That is what netOrk's VIP badge hangs on. Now an address bound to a VHID is listed on the node that is **MASTER** for it and left off a BACKUP, the same way keepalived puts the address on the master alone. A failover moves it with the next poll. `get_networks` is unchanged. Checked read-only against both gateways: gw-02 → `gw-02` / `gw-02.home.manivong.de` / `26.7.7`. gw-01 carries its 21 CARP addresses (45 IPv4 addresses instead of 24), gw-02 only its own 24. Tests: `tests/unit/test_identity_and_held_addresses.py`. Suite 387 passed.
christianmanivong added 1 commit 2026-10-16 13:37:43 +00:00
fix: name and version from system_information; a CARP address on its MASTER's interface
CI / test (3.10) (push) Successful in 30s
CI / test (3.11) (push) Successful in 29s
CI / test (3.12) (push) Successful in 30s
CI / test (3.10) (pull_request) Successful in 30s
CI / test (3.11) (pull_request) Successful in 28s
CI / test (3.12) (pull_request) Successful in 29s
e3ed0f1bdd
get_facts read hostname and version from /api/core/system/status, which on
OPNsense 26.7 carries neither: every firewall read as nameless and "unknown",
and netOrk kept naming one by its address. /api/diagnostics/system/system_information
has both (name is the FQDN, versions[0] "OPNsense 26.7.7-amd64"). The status
answer still counts where the new one gives nothing.

get_interfaces_ip listed each interface's primary address only, so a CARP address
never showed as the holder's. It now lists an address bound to a VHID on the node
that is MASTER for it, and leaves it off a BACKUP -- as keepalived puts the address
on the master alone. netOrk's VIP badge sits on that interface (netOrk #1121).
christianmanivong force-pushed fix/hostname-and-carp-addresses from b5323e2425 to e3ed0f1bdd 2026-10-16 13:37:43 +00:00 Compare
christianmanivong merged commit 9fe6245940 into master 2026-10-16 13:50:03 +00:00
christianmanivong deleted branch fix/hostname-and-carp-addresses 2026-10-16 13:50:03 +00:00
Sign in to join this conversation.