Sudden disconnection in client mode from the main router

KingCZE · July 11, 2020, 4:07pm

Hi,

I am really new to OpenWRT, so I apologise for any sily questions. I have a Fritz!box 7490 as AP and ASUS RT-AC58U with OpenWRT in client mode (on 5GHz - radio1), with "realayd" bridge (for both IPv4 and IPv6 DL...).

From time to time, my OpenWRT client disconnects from the internet. (It was happening also in pure client mode and with different routers as the main AP) I can still see ASUS in connected devices on Fritz!box, but it says strange speeds:

Asus (OpenWRT) says this:

Signal / Noise
-64/-104 dBm

RX Rate/TX Rate
6.0 Mbit/s, 20 MHz
325 Mbit/s, 80 MHz, VHT-MCS 7, VHT-NSS 1, Short GI

I cannot connect from Asus side to the main AP, neither from the main AP to the client (I cannot ssh to OpenWRT, and I do have traffic rules set, neither https to luci) when this happens. Everything is fine when I restart OpenWRT or radio0 (reconnect to the main AP).

Sys log from a recent drop:

Sat Jul 11 15:31:50 2020 daemon.notice wpa_supplicant[2795]: wlan1: WPA: Group rekeying completed with e0:28:6d:b9:1e:b1 [GTK=TKIP]
Sat Jul 11 15:37:15 2020 kern.info kernel: [  693.118988] ess_edma c080000.edma: eth1: GMAC Link is up with phy_speed=100
Sat Jul 11 15:37:15 2020 kern.info kernel: [  693.119497] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Network device 'eth1' link is up
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Interface 'wan' has link connectivity
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Interface 'wan6' has link connectivity
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Interface 'wan6' is setting up now
Sat Jul 11 15:37:15 2020 daemon.notice netifd: wan (3127): udhcpc: started, v1.30.1
Sat Jul 11 15:37:15 2020 daemon.err odhcp6c[3130]: Failed to send RS (Address not available)
Sat Jul 11 15:37:15 2020 daemon.notice netifd: wan (3127): udhcpc: sending discover
Sat Jul 11 15:37:15 2020 daemon.notice netifd: wan (3127): udhcpc: sending select for 192.168.2.2
Sat Jul 11 15:37:15 2020 daemon.notice netifd: wan (3127): udhcpc: lease of 192.168.2.2 obtained, lease time 85536
Sat Jul 11 15:37:15 2020 daemon.notice netifd: Interface 'wan' is now up
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: reading /tmp/resolv.conf.auto
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain test
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain onion
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain localhost
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain local
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain invalid
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain bind
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using local addresses only for domain lan
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using nameserver fd00::e228:6dff:feb9:1eae#53
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using nameserver 192.168.188.1#53
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using nameserver 192.168.2.1#53
Sat Jul 11 15:37:15 2020 daemon.info dnsmasq[639]: using nameserver 192.168.188.1#53
Sat Jul 11 15:37:15 2020 user.notice firewall: Reloading firewall due to ifup of wan (eth1)
Sat Jul 11 15:37:15 2020 daemon.err odhcp6c[3130]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)

Kernel log:

[  187.282634] wlan1: Limiting TX power to 21 (24 - 3) dBm as advertised by e0:28:6d:b9:1e:b1
[  257.628172] wlan1: deauthenticating from e0:28:6d:b9:1e:b1 by local choice (Reason: 3=DEAUTH_LEAVING)
[  257.629707] ath10k_ahb a800000.wifi: peer-unmap-event: unknown peer id 1
[  257.636388] ath10k_ahb a800000.wifi: peer-unmap-event: unknown peer id 1
[  259.798562] ath10k_ahb a800000.wifi: 10.4 wmi init: vdevs: 16  peers: 48  tid: 96
[  259.798641] ath10k_ahb a800000.wifi: msdu-desc: 2500  skid: 32
[  259.834152] ath10k_ahb a800000.wifi: wmi print 'P 48/48 V 16 K 144 PH 176 T 186  msdu-desc: 2500  sw-crypt: 0 ct-sta: 0'
[  259.835076] ath10k_ahb a800000.wifi: wmi print 'free: 56528 iram: 23400 sram: 32520'
[  260.109264] ath10k_ahb a800000.wifi: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
[  260.110333] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[  263.531185] wlan1: authenticate with e0:28:6d:b9:1e:b1
[  263.716947] wlan1: send auth to e0:28:6d:b9:1e:b1 (try 1/3)
[  263.719298] wlan1: authenticated
[  263.729967] wlan1: associate with e0:28:6d:b9:1e:b1 (try 1/3)
[  263.732802] wlan1: RX AssocResp from e0:28:6d:b9:1e:b1 (capab=0x1511 status=0 aid=3)
[  263.735692] wlan1: associated
[  263.759834] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[  263.776578] wlan1: Limiting TX power to 21 (24 - 3) dBm as advertised by e0:28:6d:b9:1e:b1
[  693.118988] ess_edma c080000.edma: eth1: GMAC Link is up with phy_speed=100
[  693.119497] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

I am sorry, I never know in what time in the kernel log I am...

Can anybody explain me what and why happens, and how to solve it?
Thank you very much, guys!

lleachii · July 12, 2020, 12:35pm

@KingCZE, welcome to the community!

Are you saying you use the same device to:

connect to an upstream SSID; and
provide WiFi to clients?

If so, do you loose clients when you disconnect from the upstream SSID?

(If so, that's normal.)

???

Is this the WAN of the OpenWrt? (If so, you didn't allow this in the firewall.)

Your descriptions are quite unclear...

KingCZE · July 12, 2020, 1:12pm

[FIBRE MODEM] ----LAN----> [Fritz!box AP at 192.168.188.1] -----5G WIFI-----> [OpenWRT ASUS at 192.168.188.3 / 192.168.1.1], then several devices on LAN on ASUS bridged with [192.168.188....].

I use 2.4G wifi AP on OpenWRT client (with bridged IPs from 192.168.188.1, but it does not matter at all) just so I could connect remotely to luci and restart 5G card when the client OpenWRT "disconnects" from the main AP (it is still connected, but unable to reach ASUS from outside, neither Fritz!box AP from inside). Clients stay connected to OpenWRT, but cannot reach the Internet or 192.168.188.1. When I connect any new devide to OpenWRT LAN, it cannot get any reasonable IP, because it cannot go through the WIFI to DHCP on 192.168.188.1, of course.

When it disconnects, RX of 5G on OpenWRT suddenly switches from 300+ Mbit/s with 80 MHz to some 6 Mbit/s with 20 MHz (but it is obviously fake as it cannot reach AP at all, even though it says connected on AP (Fritz!box 192.168.188.1) as well as on OpenWRT client (Asus 192.168.188.3).

This is only to connect to OpenWRT (192.168.188.3) from the AP side (192.168.188....) without the need to be on LAN of the OpenWRT. This has nothing in common with the problem, it is just that I cannot reach the other router through WIFI when this happens (even though it says connected, but with strange throughput and on 20 MHz instead of 80 which is set in the settings).

lleachii · July 12, 2020, 1:25pm

OK...odd...

Did you allow access from this side (which is blocked by default for security reasons)?

KingCZE · July 12, 2020, 1:40pm

This is not the issue. I am able to access luci on Asus client (192.168.188.3) from devices connected to the main AP (192.168.188.1), but when something happens (the issue), the wifi connection between the routers just does not work (they are connected to each other, but nothing can go through till I reconnect / restart wifi on OpenWRT.

lleachii · July 12, 2020, 2:06pm

Ahhhh!

It's because it's bridged...it goes up and down.

KingCZE · July 12, 2020, 2:10pm

Unfortunately, it is not, the same thing happens also when it is set as a plain Client, not bridged.

KingCZE · July 12, 2020, 2:25pm

I am not sure if we can solve it with logs from client bridge - when it is set to pure client, it seems to log many more events (and not the mess around the bridging). Should I set it to pure client (second layer with its own DHCP) instead of bridge, and report logs when it happens?

lleachii · July 12, 2020, 2:37pm

Let me be clear. Perhaps we need to see your /etc/config/wireless.

I'm trying to ensure that you don't have the LAN and WAN on the same band (it seems they're both on 5.4 GHz from your descriptions). If so, the LAN SSID will always go down while WAN SSID is disconnected/reconnected. If this is the case, it would be normal behavior - as the WiFi chip needs to know the channel of the upstream WAN connection before it can establish a client AP for LAN on the same channel.

Also, if a DFS channel is being used on the upstream router, the channel may be changing. I notice none of your posts note the channel.

If it's a non-DFS channel problem...the Travelmate package is known to help with issues like this.

EDIT: Lastly I think the logged errors you expect to find may be in the upstream router (if any exist).

KingCZE · July 12, 2020, 2:54pm

Here is the config:

root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.hwmode='11g'
wireless.radio0.path='platform/soc/a000000.wifi'
wireless.radio0.channel='auto'
wireless.radio0.legacy_rates='0'
wireless.radio0.htmode='HT40'
wireless.radio0.country='NZ'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.disassoc_low_ack='0'
wireless.default_radio0.encryption='psk2'
wireless.default_radio0.key='BBBBBBBBBB'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.hwmode='11a'
wireless.radio1.path='platform/soc/a800000.wifi'
wireless.radio1.htmode='VHT80'
wireless.radio1.channel='auto'
wireless.radio1.legacy_rates='0'
wireless.radio1.country='NZ'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'
wireless.default_radio1.disassoc_low_ack='0'
wireless.default_radio1.disabled='1'
wireless.wifinet2=wifi-iface
wireless.wifinet2.key='AAAAAAAAAAAA'
wireless.wifinet2.ssid='Huntly_5G'
wireless.wifinet2.device='radio1'
wireless.wifinet2.mode='sta'
wireless.wifinet2.bssid='E0:28:6D:B9:1E:B1'
wireless.wifinet2.network='wwan'
wireless.wifinet2.encryption='psk2'
wireless.wifinet2.disassoc_low_ack='0'

Both the main AP (Fritz!box, 192.168.188.1, Huntly_5G) and the OpenWRT Client (192.168.188.3) are set to automatic channel. But as I said, the same thing happens even if I use any band as Client and no band as AP, only LAN ports...

lleachii · July 12, 2020, 2:57pm

Upstream router must have a non DFS channel set.

mk24 · July 12, 2020, 3:06pm

Yes simultaneous AP and STA will not work on a DFS channel. The channel selection on the client router does not matter, it will search channels until the main AP is found. So set the main AP specifically to a non-DFS channel.

What version of OpenWrt and ath10k are you using?

KingCZE · July 12, 2020, 3:29pm

Interesting. There are not many 5G networks here:

And the local regulatory is like this:

I guess, if I set channel 58 (80 MHz) on the main AP (it is set to NZ as well), I should be good, right?

OpenWRT: 19.07.3 r11063-85e04e9f46
ath10k: I do not know, where can I find it?

KingCZE · July 12, 2020, 3:32pm

Actually, I cannot set right 58:

And I have never noticed any message in Fritz!box log like this:

What do you suggest?

lleachii · July 12, 2020, 3:38pm

I'm not sure how that's relevant...and yes, you'd pick a non-radar channel...seems like 36-64 may be your only choice...(or >132); but not familiar with DFS in NZ.

This is not the OpenWrt, you should ask them
The Channels appear Listed in their 20 MHz bandwidths

It seems like you probably want 52 or 56.

KingCZE · July 12, 2020, 3:50pm

Perfect, thank you very much! I will report back in a day or 2, if everything goes fine. I appreciate your help and patience.

KingCZE · July 12, 2020, 4:00pm

Ok, it did not help. I am on ch 56, but it has just happened again. I was also wondering - it was happening on 2.4G as well, so I suppose it was not associated with DFS.

KingCZE · July 12, 2020, 4:35pm

I will try one more thing - it seems ch 56 is a DFS channel after all (diagnosis from AP):

I will try ch 153.

Mfuad · January 20, 2022, 5:12pm

try to add T1 and T2