Travel router disconnects from WiFi

Hello Forum

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)

Any ideas would be much appreciated!

Would you please diagram your home network?

It looks like your router is loosing its connection to WWAN which is taking down the whole system until it recovers.

Not sure how tunneling in could cause it but maybe the layout will provide some insight.

Also:

Conflict with frequencies:

:spiral_notepad:
Are you traveling to different countries?

spiral_notepad^2
Sorry, It is hard to read the log: it is too long and wide but the issue is there:

Let's see the configs and what router you are using from the cat calls.

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.

Here are the configs

root@OpenWrt:~# ubus call system board
{
        "kernel": "5.15.162",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "GL.iNet GL-MT3000",
        "board_name": "glinet,gl-mt3000",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.4",
                "revision": "r24012-d8dd03c46f",
                "target": "mediatek/filogic",
                "description": "OpenWrt 23.05.4 r24012-d8dd03c46f"
        }
}
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd5f:f4a4:4a01::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '10.12.34.11'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'

config interface 'wwan'
        option proto 'dhcp'

config interface 'openvpn'
        option proto 'none'
        option device 'tun0'
        option auto '0'
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wifi'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option txpower '20'
        option country 'CH'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/18000000.wifi+1'
        option channel '36'
        option band '5g'
        option htmode 'VHT40'
        option cell_density '0'
        option country 'CH'
        option txpower '23'

config wifi-iface 'wifinet0'
        option device 'radio1'
        option mode 'ap'
        option ssid 'redacted'
        option encryption 'psk2'
        option key 'redacted'
        option network 'lan'

redacted some disabled wifi connections
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list device 'tun0'
        list network 'wan'
        list network 'wan6'
        list network 'openvpn'
        list network 'wwan'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

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.

Is that how you set it up?

I just do not find it to be a simple answer for people that are not well versed in it.

Maybe it would clear up an 80MHz request but I fail to see how.

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.

1 Like

If you want to tutor Travelmate, go for it.

I like Travelmate; I just do not like the learning curve.

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:

config wifi-iface 'wifinet8'
        option device 'radio0'
        option mode 'sta'
        option network 'wwan'
        option ssid 'redacted'
        option encryption 'psk2'
        option key 'redacted'

Thanks for the comment with the country code, I will make sure to adjust them in the future.

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):

2 Likes

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.

Just how is the question :weary:

Change the channel option to 'auto' or zero if you want to go into the config .
The AP you connect to should be picking channel .

Thank you for pointing it out, makes sense and I will make sure to select auto in the future.

I think when I scan for a AP OpenWrt sets the channel to 1 by default. I just checked it and all saved WiFis have channel 1.

So, this is where we get to Travelmate...

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.

Try manually setting, the next session, to auto

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?

I'd prefer to figure out the drop and give you time to learn Travelmate.

If you drop for another reason, then Travelmate will do all the things said, and you may not care.

You can do this by saving your config, doing a reset, playing around and then restoring known-working.
:spiral_notepad:

My concern is if you do not figure out the drop, it will contaminate Travelmate

Thank you very much for all of your support @LilRedDog @pavelgl @egc .

Since I will be traveling already next week I will try out the watchdog script as a quick fix :see_no_evil: and invest some time later to familiarize myself with Travelmate :sweat_smile:

2 Likes
1 Like