If kill-switch is enabled and PVPN_WAIT is set to any positive integer value, protonvpn-cli tries uselessly till WAIT time is reached for establishing a connection although connection shall never establish anyway.
For more technical evidence, this is caused by the code at cli.py:106. It's no brainer to understand how that code affects.
To Reproduce
Steps to reproduce the behavior:
Enable Kill switch
Set PVPN_DEBUG=1 to see the logs.
Set PVPN_WAIT to any value greater than 0
Issue pkill -x openvpn to artifice an abnormal connection drop.
Gaze at the logs
See pvpn being looped at
Waiting 'x' seconds for connectionInitiating api call: https://api.protonvpn.com/test/ping
untill PVPN_WAIT time is reached.
The connection shall never establish. Only way out is to manually hit protonvpn disconnect
My point
Why should kill-switch block the pvpn-cli itself and its internal affairs? What it'd be doing basically is that, locking itself inside doors and swallowing keys afterwards. Instead, a better approach would be to
1) whitelist a specific api address/ip address (like api.protonvpn.com^); although this poses a security problem in case it is enough for a malware/advisory to know he's behind a vpn.
2) whitelist the whole app (alert almost at red-level)
3) whitelist call_api() only? Maybe run some spaghetti coding to fake the real use of the function?
However, this env variable, PVPN_WAIT, works as expected (wait for network to be usable) when started afresh but not when a kill switch is already enabled. This one point takes it into consideration:
4) Use some logic with the PVPN_WAIT thing. For example, look for any connected valid network device (like eth0, wlp2s0, etc, but not lo) and whether any TUN device named proton0 is available.
=> If there's a valid connected device and no proton0 device, and if connection isn't working then wait till PVPN_WAIT.
=> However, if there is a proton0 device regardless of any valid device exists, [there must have been an abnormal disconnect from vpn lately. Maybe the internet was cut off intentionally/unintentionally] initiate a disconnect (a ready solution at hand) and then wait till PVPN_WAIT.
=> IF there isn't any valid device connected, I don't know whether it is logical to wait at all. This keeps a door open though for, let's say, kernel or system manager bugs and all.
5) insert your great idea here
Major Request
Remove the PVPN_WAIT line from USAGE.md#via-systemd-wait until this is fixed. Some users may suffer from this if they choose to use kill-switch.
If kill-switch is enabled and PVPN_WAIT is set to any positive integer value, protonvpn-cli tries uselessly till WAIT time is reached for establishing a connection although connection shall never establish anyway.
For more technical evidence, this is caused by the code at cli.py:106. It's no brainer to understand how that code affects.
To Reproduce Steps to reproduce the behavior:
PVPN_DEBUG=1to see the logs.PVPN_WAITto any value greater than 0pkill -x openvpnto artifice an abnormal connection drop.Waiting 'x' seconds for connectionInitiating api call: https://api.protonvpn.com/test/pinguntillPVPN_WAITtime is reached.protonvpn disconnectMy point Why should kill-switch block the pvpn-cli itself and its internal affairs? What it'd be doing basically is that, locking itself inside doors and swallowing keys afterwards. Instead, a better approach would be to 1) whitelist a specific api address/ip address (like api.protonvpn.com^); although this poses a security problem in case it is enough for a malware/advisory to know he's behind a vpn.
2) whitelist the whole app (alert almost at red-level)
3) whitelist
call_api()only? Maybe run some spaghetti coding to fake the real use of the function?However, this env variable,
PVPN_WAIT, works as expected (wait for network to be usable) when started afresh but not when a kill switch is already enabled. This one point takes it into consideration:4) Use some logic with the
PVPN_WAITthing. For example, look for any connected valid network device (likeeth0,wlp2s0, etc, but notlo) and whether any TUN device namedproton0is available.=> If there's a valid connected device and no
proton0device, and if connection isn't working then wait tillPVPN_WAIT.=> However, if there is a
proton0device regardless of any valid device exists, [there must have been an abnormal disconnect from vpn lately. Maybe the internet was cut off intentionally/unintentionally] initiate a disconnect (a ready solution at hand) and then wait tillPVPN_WAIT.=> IF there isn't any valid device connected, I don't know whether it is logical to wait at all. This keeps a door open though for, let's say, kernel or system manager bugs and all.
5) insert your great idea here
Major Request Remove the
PVPN_WAITline from USAGE.md#via-systemd-wait until this is fixed. Some users may suffer from this if they choose to use kill-switch.I hope this helps