Dearest collective knowledge of gentoo-user,

I'm using netifrc with wpa_supplicant (no custom settings in netifrc) for accessing a FRITZ!Box network at my parents house. They have some WiFi repeaters set up, connected via AVM's Meshing capabilities.

Also, I am using OpenVPN to connect to VPN servers from ProtonVPN.

From time to time, I would see this in the syslog:

Jan  3 16:37:01 georgi kernel: wlp0s20f3: disconnect from AP 04:b4:fe:b3:3f:71 
for new auth to 3c:a6:2f:ed:5b:1b
Jan  3 16:37:01 georgi kernel: wlp0s20f3: authenticate with 3c:a6:2f:ed:5b:1b
Jan  3 16:37:01 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
Jan  3 16:37:01 georgi kernel: wlp0s20f3: send auth to 3c:a6:2f:ed:5b:1b (try 
1/3)
Jan  3 16:37:01 georgi kernel: wlp0s20f3: authenticated
Jan  3 16:37:01 georgi kernel: wlp0s20f3: associate with 3c:a6:2f:ed:5b:1b (try 
1/3)
Jan  3 16:37:01 georgi kernel: wlp0s20f3: RX ReassocResp from 3c:a6:2f:ed:5b:1b 
(capab=0x1431 status=0 aid=9)
Jan  3 16:37:01 georgi kernel: wlp0s20f3: associated
Jan  3 16:37:38 georgi kernel: wlp0s20f3: disconnect from AP 3c:a6:2f:ed:5b:1b 
for new auth to 04:b4:fe:b3:3f:71
Jan  3 16:37:39 georgi kernel: wlp0s20f3: authenticate with 04:b4:fe:b3:3f:71
Jan  3 16:37:39 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
Jan  3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try 
1/3)
Jan  3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try 
2/3)
Jan  3 16:37:39 georgi kernel: wlp0s20f3: authenticated
Jan  3 16:37:39 georgi kernel: wlp0s20f3: associate with 04:b4:fe:b3:3f:71 (try 
1/3)
Jan  3 16:37:39 georgi kernel: wlp0s20f3: RX ReassocResp from 04:b4:fe:b3:3f:71 
(capab=0x1431 status=0 aid=3)
Jan  3 16:37:39 georgi kernel: wlp0s20f3: associated

This happens even without setting "bgscan" or similar in wpa_supplicant.conf, so I highly suspect, this is the magic of a Mesh WiFi to pass me to a more fitting AP in the same network from time to time. All fine so far, I don't lose WiFi connection, so this seems normal to me.

What bugs me however is, that OpenVPN loses connection to the VPN server after such an AP change and is not able to reconnect automatically again.

Dec 31 19:06:08 georgi openvpn[14956]: [node-ch-11.protonvpn.net] Inactivity 
timeout (--ping-restart), restarting
Dec 31 19:06:08 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0 
10.96.0.39 255.255.0.0 restart
Dec 31 19:06:08 georgi openvpn[14956]: SIGUSR1[soft,ping-restart] received, 
process restarting
Dec 31 19:06:09 georgi openvpn[14956]: NOTE: the current --script-security 
setting may allow this configuration to call user-defined scripts
Dec 31 19:06:09 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote 
address: [AF_INET]138.199.6.178:1194
Dec 31 19:06:09 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link local: (not bound)
Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link remote: 
[AF_INET]138.199.6.178:1194
Dec 31 19:06:29 georgi openvpn[14956]: Server poll timeout, restarting
Dec 31 19:06:29 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0 
10.96.0.39 255.255.0.0 restart
Dec 31 19:06:29 georgi openvpn[14956]: SIGUSR1[soft,server_poll] received, 
process restarting
Dec 31 19:06:29 georgi openvpn[14956]: NOTE: the current --script-security 
setting may allow this configuration to call user-defined scripts
Dec 31 19:06:29 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote 
address: [AF_INET]138.199.6.179:51820
Dec 31 19:06:29 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link local: (not bound)
Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link remote: 
[AF_INET]138.199.6.179:51820

The lines from 19:06:29 are repeated every 20 seconds (server-poll-timeout 20), with varying IP addresses, so it seems to cycle infinitely through all servers without success.

While this is happening, I cannot access the internet. I suspect, this is because of the "persist-tun" setting in the OpenVPN config, but I don't want to remove it because I'd rather have no internet at all than having suddenly internet without VPN ("kill switch").

I can manually "repair" this situation by sending SIGHUP to OpenVPN, which causes a hard reconnect.

Now, with this background information, I need your help to come up with a strategy to survive an automatic Mesh WiFi reconnect, without the need of manually restarting OpenVPN all the time.

- Might there be a problem with my OpenVPN config? I'm mostly using the default config that can be downloaded from ProtonVPN, with some additional "route" statements to make VPN unfriendly websites happy, and I renamed the device name to have proper logs (see code block directly below this bullet point). Has anyone a similar setup and did some adjustments to make it work properly?

dev proton0
dev-type tun

- If there is nothing wrong with my OpenVPN config, how can I automatically send a SIGHUP on such a reconnect event? It is not a "proper" CONNECTED event, so wpa_cli.conf does not get triggered. How can I monitor such events and respond accordingly?

For now, I used the below statement in OpenVPN config to do a hard reset on server timeout, but for this I need to wait two minutes for the timeout to hit. I'd rather want this immediately when wpa_supplicant reconnects.

remap-usr1 SIGHUP

Any help in this matter would highly be appreciated!

Thanks in advance!

Kind regards

FloGa

Reply via email to