I am having a problem with my travel router.
I use this router to connect via OpenVPN to my local network when I am traveling.
This usually works fine, just in some locations I am randomly experiencing disconnects. It actually depends on the place, meaning in some places everything works all the time as expected but in other places not.
So I am guessing that it is kind of related to the local networks.
The problem I have is that when such a disconnect happens I am also loosing my VPN connection which breaks my internet (because all of my traffic has to go through the VPN).
I captured a log which shows one of these events:
Mon Dec 30 02:14:17 2024 kern.info kernel: [ 1438.933061] phy0-sta0: AP b0:f2:08:d5:48:35 changed bandwidth, new config is 2432.000 MHz, width 2 (2442.000/0 MHz)
Mon Dec 30 02:14:17 2024 kern.info kernel: [ 1438.943512] phy0-sta0: AP b0:f2:08:d5:48:35 changed bandwidth to incompatible one - disconnect
Mon Dec 30 02:14:17 2024 kern.info kernel: [ 1438.952125] phy0-sta0: failed to follow AP b0:f2:08:d5:48:35 bandwidth change, disconnect
Mon Dec 30 02:14:17 2024 daemon.notice netifd: Network device 'phy0-sta0' link is down
Mon Dec 30 02:14:17 2024 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Mon Dec 30 02:14:17 2024 daemon.notice netifd: wwan (2486): udhcpc: received SIGTERM
Mon Dec 30 02:14:17 2024 daemon.notice netifd: wwan (2486): udhcpc: unicasting a release of 192.168.178.48 to 192.168.178.1
Mon Dec 30 02:14:17 2024 daemon.notice netifd: wwan (2486): udhcpc: sending release
Mon Dec 30 02:14:17 2024 daemon.notice netifd: wwan (2486): udhcpc: entering released state
Mon Dec 30 02:14:17 2024 daemon.notice netifd: wwan (2486): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wwan" } (Permission denied)
Mon Dec 30 02:14:17 2024 daemon.notice netifd: Interface 'wwan' is now down
Mon Dec 30 02:14:17 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: CTRL-EVENT-DISCONNECTED bssid=b0:f2:08:d5:48:35 reason=3 locally_generated=1
Mon Dec 30 02:14:18 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: SME: Trying to authenticate with b0:f2:08:d5:48:35 (SSID='FRITZ!Box 7590 HE' freq=2432 MHz)
Mon Dec 30 02:14:18 2024 kern.info kernel: [ 1440.659283] phy0-sta0: authenticate with b0:f2:08:d5:48:35
Mon Dec 30 02:14:18 2024 kern.info kernel: [ 1440.664801] phy0-sta0: 80 MHz not supported, disabling VHT
Mon Dec 30 02:14:19 2024 kern.info kernel: [ 1440.790139] phy0-sta0: send auth to b0:f2:08:d5:48:35 (try 1/3)
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: Trying to associate with b0:f2:08:d5:48:35 (SSID='FRITZ!Box 7590 HE' freq=2432 MHz)
Mon Dec 30 02:14:19 2024 kern.info kernel: [ 1440.800289] phy0-sta0: authenticated
Mon Dec 30 02:14:19 2024 kern.info kernel: [ 1440.808043] phy0-sta0: associate with b0:f2:08:d5:48:35 (try 1/3)
Mon Dec 30 02:14:19 2024 kern.info kernel: [ 1440.826356] phy0-sta0: RX AssocResp from b0:f2:08:d5:48:35 (capab=0x1431 status=0 aid=133)
Mon Dec 30 02:14:19 2024 kern.info kernel: [ 1440.836119] phy0-sta0: associated
Mon Dec 30 02:14:19 2024 daemon.notice netifd: Network device 'phy0-sta0' link is up
Mon Dec 30 02:14:19 2024 daemon.notice netifd: Interface 'wwan' has link connectivity
Mon Dec 30 02:14:19 2024 daemon.notice netifd: Interface 'wwan' is setting up now
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: Associated with b0:f2:08:d5:48:35
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: Unknown event 37
Mon Dec 30 02:14:19 2024 daemon.notice netifd: wwan (3763): udhcpc: started, v1.36.1
Mon Dec 30 02:14:19 2024 daemon.notice netifd: wwan (3763): udhcpc: broadcasting discover
Mon Dec 30 02:14:19 2024 kern.debug kernel: [ 1440.908373] phy0-sta0: Limiting TX power to 20 (20 - 0) dBm as advertised by b0:f2:08:d5:48:35
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: WPA: Key negotiation completed with b0:f2:08:d5:48:35 [PTK=CCMP GTK=CCMP]
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: CTRL-EVENT-CONNECTED - Connection to b0:f2:08:d5:48:35 completed [id=0 id_str=]
Mon Dec 30 02:14:19 2024 daemon.notice wpa_supplicant[1478]: phy0-sta0: Unknown event 37
Mon Dec 30 02:14:22 2024 daemon.notice netifd: wwan (3763): udhcpc: broadcasting discover
Mon Dec 30 02:14:22 2024 daemon.notice netifd: wwan (3763): udhcpc: broadcasting select for 192.168.178.48, server 192.168.178.1
Mon Dec 30 02:14:22 2024 daemon.notice netifd: wwan (3763): udhcpc: lease of 192.168.178.48 obtained from 192.168.178.1, lease time 864000
Mon Dec 30 02:14:22 2024 daemon.notice netifd: Interface 'wwan' is now up
Mon Dec 30 02:14:22 2024 user.notice firewall: Reloading firewall due to ifup of wwan (phy0-sta0)
Try travelmate. There is a vpn reconnect option. I haven't personally tested this particular option, but I'm sure it will work great (based on my experience with the app).
@LilRedDog Thanks a lot for taking a look. I am speculating that my tunneling is not involved in the disconnects, as it works very stable in some locations. I am primarily traveling to one country (Germany), but the router worked well in other European countries.
Radio1 is your AP. Leaves you radio0. Radio0 is 2.4. and it connects to a hotspot. 2.4 does not have 80MHz. It will go up to 40MHz but not with 1 as the center channel and that channel should be picked by the AP it associates with, not your router.
Also, you should change the Country code to whatever country you are in, but there is still no 80MHz in 2.4; that I know of. So who is asking for it needs an answer.
The OP needs a solution to re-establish the VPN when the uplink is not stable. Travelmate monitors the uplink connection(s) and has an option to reconnect to VPNs.
Continuously checks the existing uplink quality, e.g. for conditional uplink (dis)connections
VPN hook supports 'wireguard' or 'openvpn' client setups to handle VPN (re)connections automatically
There is also another big advantage:
STA interfaces operate in an "always off" mode, to make sure that the AP is always accessible
Since I hate pointless arguments, I will withdraw. Feel free to suggest the best solution.
Yes, you are correct, radio1 is my ap and radio0 connects to the router of the place I am visiting.
I accidentally deleted the config for radio0 in my previous post:
I would follow @pavelgl 's advice and install Travelmate.
The problem with OpenVPN is that the tunnel goes down when it is disconnected and it will not recover on its own therefore it needs to be restarted.
Travelmate can do that but if you do not want Travelmate you can use an OpenVPN watchdog script.
This is the one I am using (not only useful when travelling, OpenVPN has a habit of disconnecting depending on provider):
Thank you for the comment. I took a look at the Travelmate description which seems to provide a full solution for a travel router.
Actually I am a bit hesitant to go in this direction because my router "kind of" works well and at least I understand the underlying configs.
So if I could solve the disconnect issue in a less complex manner that would be preferred.
Here is how it usually goes:
It wants a fresh install with all your packages working and only have ever connected to one AP as a client.
It uses that one configuration as a template, so if it is not pristine it leads to surgery or starting over.
Travelmate is worth the time but it is frustratingly persnickety, initially.
Thank you @LilRedDog for the information on how to start with Travelmate.
I have one question regarding the script option @egc mentioned. To me this sounds easier than travelmate, still both of you are suggesting to go for Travelmate.
Why would Travelmate be preferable over the watchdog script?
Since I will be traveling already next week I will try out the watchdog script as a quick fix and invest some time later to familiarize myself with Travelmate