* Skip network re-activation on startup when settings are unchanged
Since #3528 Supervisor re-applies its network defaults on every startup: it
rewrites the NetworkManager connection profile of each enabled interface and
re-activates the connection so the settings take effect. The re-activation
runs unconditionally, so every Supervisor start causes a full connection
cycle (routes torn down, DHCP re-negotiated, Wi-Fi reassociation) even when
the profile did not change, which is the common case.
Make NetworkSetting.update() report whether the profile actually changed by
comparing NetworkManager's normalized view of the settings before and after
the update call. Comparing Supervisor's generated payload against the
current profile would not work here since NetworkManager omits properties at
their default value from GetSettings. On the startup path, skip
re-activation when the profile is unchanged and the connection is currently
activated. Out-of-date profiles (e.g. after a change of Supervisor's
defaults) are still rewritten and re-activated, and user-initiated updates
via the API re-activate unconditionally as before.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reapply changed network settings in place on startup
When the startup profile update does change the NetworkManager connection
profile (e.g. after a change of Supervisor's defaults), the settings were
applied through a full re-activation cycle, briefly disrupting connectivity.
Use NetworkManager's Device.Reapply() instead, which applies the updated
profile to the active connection without disconnecting. Not all settings can
be reapplied (e.g. wireless security changes), in which case NetworkManager
raises an error and Supervisor falls back to the full re-activation as
before. User-initiated updates via the API are unaffected and still
re-activate the connection.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Log network connection activation and reapply at info level
Activating or reapplying a connection affects host connectivity, but was
only visible in debug logs. Log at info level when Supervisor activates a
connection, reapplies changed settings in place, or creates a new
connection, so the Supervisor log shows when and why the host network
configuration was touched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reapply changed settings in place for user-initiated updates too
Extend the in-place reapply from the startup path to user-initiated network
settings updates via the API. Changing e.g. IP or DNS configuration no
longer drops connectivity, which also matters when the update is made
remotely over the interface being reconfigured.
Payloads containing a Wi-Fi PSK always re-activate the connection: secrets
are excluded from GetSettings and ignored by NetworkManager's Reapply (the
diff runs with NM_SETTING_COMPARE_FLAG_IGNORE_SECRETS), so an updated PSK
would otherwise be written to the profile but never applied or validated.
Unchanged settings also still re-activate on the user path, both to keep
resubmitting settings working as a way to force a reconnect and to cover
secret-only changes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Clarify settings variable naming in NetworkSetting.update()
The dict fetched from GetSettings was named new_settings and mutated by the
merges into the payload sent to Update, so the name was only accurate for
half of the function. Keep the fetched state pristine as current_settings,
merge into a copy named new_settings, and compare current_settings against
the normalized result.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Extract in-place settings application into a helper method
Review feedback on #7043 noted the conditional block in apply_changes() had
grown confusing with the added nesting. Move the decision whether updated
settings are effective without a full re-activation cycle into a dedicated
_apply_settings_in_place() method using early returns, so apply_changes()
reads linearly: update settings, then activate unless they were applied in
place.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* tests: enable flake8-pytest-style (PT) ruff rules
Enable the `PT` ruff rule set and fix the resulting violations across the
test suite:
- PT006: pass parametrize argument names as tuples instead of a single
comma-separated string.
- PT022: switch fixtures that have no teardown from `yield` to `return`
so the lack of cleanup is obvious at a glance.
- PT011: add `match=` to broad `pytest.raises(ValueError)` blocks so the
expected error is anchored to a specific message.
- PT012: hoist setup (patches, branching) out of `pytest.raises()`
blocks so only the call that is expected to raise remains inside.
- PT013: replace `from pytest import X` with `import pytest` and access
attributes via the module.
- PT015: replace `try/except` + `assert False` patterns with
`pytest.raises(...)`.
- PT017: replace `assert` on exceptions inside `except` blocks with
`pytest.raises(...) as exc_info` and assert on `exc_info.value`.
No behavioral changes to the tests; the full suite still passes.
* tests: address review feedback on PT ruff rule enablement
- Fix fixture return-type annotations after switching `yield` to `return`
in tests/conftest.py: drop the `Generator[...]`/`AsyncGenerator[...]`
wrapper for `dns_manager_service`, `supervisor_internet`, `websession`,
and `mock_update_data` so the annotation matches what the fixture
actually returns.
- Correct the return-type annotation of `fixture_ip6config_service` from
`IP4ConfigService` to `IP6ConfigService`.
- Fix recurring "excepiton" typo in tests/utils/test_exception_helper.py.
* tests: verify backup cleanup on permission error
After `test_new_backup_permission_error` raises `BackupPermissionError`,
assert that no tarfile was left behind and `tmp_path` is empty. The
previous version only checked that the exception was raised, which
missed any regression where a partial tarfile would survive the failed
create.
* tests: rename DNS_GOOD_V6 to DNS_V6_UNSUPPORTED
The constant was named "good" but its tests assert that the URLs are
rejected by the DNS validator. The IPv6 URLs are well-formed but
currently rejected because IPv6 doesn't work with the Docker network
(see `dns_url` in supervisor/validate.py). Rename the constant and the
related test to make the intent obvious.
* Add D-Bus tolerant enum base classes to prevent crashes on unknown values
D-Bus services (systemd, NetworkManager, RAUC, UDisks2) can introduce
new enum values at any time via OS updates. Standard Python enum
construction raises ValueError for unknown values, which would crash
the Supervisor.
Introduce DBusStrEnum and DBusIntEnum base classes that use Python's
_missing_ hook to create pseudo-members for unknown values. These
pseudo-members pass isinstance checks (satisfying typeguard), preserve
the original value, don't pollute __members__, and report unknown
values to Sentry (deduplicated per class+value) for observability.
Migrate 17 D-Bus enums in dbus/const.py and udisks2/const.py to the
new base classes. Enums only sent TO D-Bus (StopUnitMode, StartUnitMode,
etc.) are left unchanged. Remove the manual try/except workaround in
NetworkInterface.type now that DBusIntEnum handles it automatically.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add explicit enum conversions for systemd-resolved D-Bus properties
The resolved properties (dns_over_tls, dns_stub_listener, dnssec, llmnr,
multicast_dns, resolv_conf_mode) were returning raw string values from
D-Bus without converting to their declared enum types. This would fail
runtime type checking with typeguard.
Now safe to add explicit conversions since these enums use DBusStrEnum,
which tolerates unknown values from D-Bus without crashing.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Avoid blocking I/O in D-Bus enum Sentry reporting
Move sentry_sdk.capture_message out of the event loop by adding a
fire_and_forget_capture_message helper that offloads the call to the
executor when a running loop is detected.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Handle exceptions when reporting message to Sentry
* Narrow typing of reported values
Use str/int explicitly since that is what the two existing Enum classes
can actually report.
* Adjust test style
* Apply suggestions from code review
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Improve connection settings fixture
Make the connection settings fixture behave more closely to the actual
NetworkManager. The behavior has been tested with NetworkManager 1.42.4
(Debian 12) and 1.44.2 (HAOS 13.1). This likely behaves similar in older
versions too.
* Introduce separate skeleton and settings for wireless
Instead of having a combined network settings object which has
Ethernet and Wirless settings, create a separate settings object for
wireless.
* Handle addresses/address-data property like NetworkManager
* Address ruff check
* Improve network API test
Add a test which changes from "static" to "auto". Validate that settings
are updated accordingly. Specifically, today this does clear the DNS
setting (by not providing the property).
* ruff format
* ruff check
* Complete TEST_INTERFACE rename
* Add partial network update as test case
* Migrate to Ruff for lint and format
* Fix pylint issues
* DBus property sets into normal awaitable methods
* Fix tests relying on separate tasks in connect
* Fixes from feedback
Mike DegatanoandGitHub
