mysticalsoap/aqomui
Watch
1
0
Fork
You've already forked aqomui
 0
Code Issues 36 Pull requests 1 Releases 2 Packages Wiki Activity Actions

change: set the tunnel device name in the config instead of parsing the log #64

Merged
mysticalsoap merged 1 commit from change/set-tun-device-name into trunk 2026-08-19 14:23:33 -04:00
Conversation 0 Commits 1 Files changed 2 +102 -28
mysticalsoap commented 2026-08-19 13:43:41 -04:00
Owner
Copy link

Problem

ovpn() discovers the tunnel interface by regex-matching OpenVPN's log (parse_tun_device, the #15 stopgap). The name is parsed out of output we produce the config for ourselves.

Fix

write_config now sets the dev line in every config aqomui writes, and returns the name; ovpn() announces it up front the way the WireGuard path already announces wg_aqomui. The regex stays only as a fallback for configs aqomui does not write (the raw custom-provider paths and tap configs).

Findings from the issue's "check first" questions:

  • Concurrent tunnels: up to three OpenVPN processes can run at once (main, hop, bypass), so there are three fixed names — tun_aqomui, tun_aqomui_h, tun_aqomui_b — keyed off the config role write_config already distinguishes.
  • The name is tun_aqomui, not the issue's ovpn-aqomui: firewall_default.json opens the firewall with iptables tun+ wildcards, so a name not starting with tun would have every packet dropped by the default deny — and users may carry customized firewall configs, so editing the shipped default wouldn't cover upgrades. The tun prefix also lets OpenVPN infer --dev-type, and it matches the existing wg_aqomui naming. All three names fit IFNAMSIZ.
  • tap-based custom configs keep their own device: the firewall only opens tun+, so renaming them buys nothing, and their type must not be clobbered.

Verification

  • New TestWriteConfigDevice pytest class: per-role names, missing-dev-line insertion, tap passthrough, IFNAMSIZ/prefix invariants. Existing parse tests unchanged (the fallback keeps working).
  • write_config exercised manually against a ProtonVPN-style template: main/hop/bypass configs each carry their dev line, remote/proto rewriting unaffected.
  • Live verification pending before merge (per process rule): connect, confirm ip link shows tun_aqomui, DNS lands on it, and bypass comes up as tun_aqomui_b with egress IPs correct.

Closes #21

🤖 Generated with Claude Code

**Problem** `ovpn()` discovers the tunnel interface by regex-matching OpenVPN's log (`parse_tun_device`, the #15 stopgap). The name is parsed out of output we produce the config for ourselves. **Fix** `write_config` now sets the `dev` line in every config aqomui writes, and returns the name; `ovpn()` announces it up front the way the WireGuard path already announces `wg_aqomui`. The regex stays only as a fallback for configs aqomui does not write (the raw custom-provider paths and tap configs). Findings from the issue's "check first" questions: - **Concurrent tunnels**: up to three OpenVPN processes can run at once (main, hop, bypass), so there are three fixed names — `tun_aqomui`, `tun_aqomui_h`, `tun_aqomui_b` — keyed off the config role `write_config` already distinguishes. - **The name is `tun_aqomui`, not the issue's `ovpn-aqomui`**: `firewall_default.json` opens the firewall with iptables `tun+` wildcards, so a name not starting with `tun` would have every packet dropped by the default deny — and users may carry customized firewall configs, so editing the shipped default wouldn't cover upgrades. The `tun` prefix also lets OpenVPN infer `--dev-type`, and it matches the existing `wg_aqomui` naming. All three names fit IFNAMSIZ. - tap-based custom configs keep their own device: the firewall only opens `tun+`, so renaming them buys nothing, and their type must not be clobbered. **Verification** - New `TestWriteConfigDevice` pytest class: per-role names, missing-`dev`-line insertion, tap passthrough, IFNAMSIZ/prefix invariants. Existing parse tests unchanged (the fallback keeps working). - `write_config` exercised manually against a ProtonVPN-style template: main/hop/bypass configs each carry their `dev` line, remote/proto rewriting unaffected. - **Live verification pending before merge** (per process rule): connect, confirm `ip link` shows `tun_aqomui`, DNS lands on it, and bypass comes up as `tun_aqomui_b` with egress IPs correct. Closes #21 🤖 Generated with [Claude Code](https://claude.com/claude-code)
change: set the tunnel device name in the config instead of parsing the log
All checks were successful
ci / test (pull_request) Successful in 37s
Details
193e8c298f
 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mysticalsoap force-pushed change/set-tun-device-name from 193e8c298f
All checks were successful
ci / test (pull_request) Successful in 37s
Details
to 4629f56e02
All checks were successful
ci / test (pull_request) Successful in 41s
Details
ci / test (push) Successful in 44s
Details
2026-08-19 13:49:35 -04:00 Compare
mysticalsoap deleted branch change/set-tun-device-name 2026-08-19 14:23:33 -04:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
architecture
Structural change, not a local fix

  
bug
Defect in existing behaviour

  
cleanup
Tidying with no behaviour change

  
docs
Documentation and repo standards

  
packaging
distro packages and their build tooling

  
security
Vulnerability or hardening

  
testing
Test coverage or infrastructure

  
upstream
Needs action on someone else's project

  
ux
Interface behaviour and clarity

No labels
architecture
bug
cleanup
docs
packaging
security
testing
upstream
ux
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
mysticalsoap/aqomui!64
No description provided.