Skip to content

fix: explicitly activate protection profiles - #29

Open
UglyEgg wants to merge 1 commit into
ProtonVPN:stablefrom
UglyEgg:contrib/protection-profile-activation
Open

fix: explicitly activate protection profiles#29
UglyEgg wants to merge 1 commit into
ProtonVPN:stablefrom
UglyEgg:contrib/protection-profile-activation

Conversation

@UglyEgg

@UglyEgg UglyEgg commented Sep 13, 2026

Copy link
Copy Markdown

Problem

The WireGuard protection helper adds a profile and waits for a device-added signal. Adding a profile does not guarantee activation when autoconnect is no longer eligible. After a manual device disconnect, NetworkManager can retain an inactive profile; startup then waits indefinitely and retries can add more profiles.

NetworkManager documents that adding an unsaved profile starts it only when autoconnect is eligible, while activate_connection_async explicitly starts the connection and returns an NMActiveConnection whose state tracks final activation:

Change

  • Explicitly activate newly added profiles.
  • Reuse only existing profiles whose normalized settings match the request, apart from UUID and timestamp.
  • Reuse an already active or activating matching profile without duplication.
  • Observe NMActiveConnection.state through activation completion.
  • Propagate add/activation failures and retire cancellables and signal handlers after completion or timeout.
  • Preserve mismatched, unrelated, and uncertain profiles; do not delete or weaken protection rules.

Verification

  • 18 focused cases use real libnm settings and fake NetworkManager I/O. They cover inactive, activating, active, duplicate, mismatched, failed, cancelled, timeout, autoconnect-race, and late-callback paths.
  • The retained-inactive-profile regression fails against pristine upstream and passes with this change.
  • Complete upstream suite: 485 passed; two unchanged dependency warnings.
  • Flake8 passes on both changed files.
  • Downstream Fedora 44 acceptance reproduced a retained inactive protection profile after manual disconnect, then verified single-profile recovery and ordinary connect/disconnect behavior with the equivalent patch.

Development disclosure: I developed this patch with material assistance from OpenAI Codex under my direction, then reviewed, tested, and signed the final change.

Adding a protection profile alone relies on device autoconnect and a later
device-added signal. A manual device disconnect disables autoconnect while
leaving the profile in NetworkManager, so startup can wait indefinitely and
later retries can accumulate profiles.

Explicitly activate a newly added or exactly matching existing profile and
observe the returned ActiveConnection. Reuse active or activating profiles,
compare normalized copies without mutating the request, propagate activation
failure, and retire cancellables and signal handlers on bounded-wait timeout.

Cover inactive, activating, active, duplicate, mismatched, failed, cancelled,
and late-callback paths with real libnm settings and fake I/O.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant