Dumb AP with linksys e8450 / Belkin RT3200 occasionaly client associates but no connectivity

I am on OpenWrt SNAPSHOT r18777-1847382456 i have not stumbled yet on that issue yet, the wlan0 went completely down if I get it correctly ...
I got also a phew "unknown event 139" but wifi did not not went down.
Which snapshot are you using ?

Forum user @ex-git suggested at [Belkin RT3200/Linksys E8450 WiFi AX discussion] for another issue I don't know if it is related.
(Belkin RT3200/Linksys E8450 WiFi AX discussion - #1719 by ex-git)

echo 0 > /sys/kernel/debug/ieee80211/phy0/aql_enable
echo 0 > /sys/kernel/debug/ieee80211/phy1/aql_enable
1 Like

this time wlan0 didn't go down completely. More than 16 devices are sitting on wlan0. Communication lost 14

OpenWrt SNAPSHOT r18752-1b311aab31

I am using the latest snapshot download for the E8450, OpenWrt SNAPSHOT r19040-247eaa4416.

After a clean flash with the default configuration and installing luci package, I setup radios ending with this /etc/config/wireless:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT40'
        option country 'US'
        option cell_density '0'
        option noscan '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid '2G'
        option encryption 'sae-mixed'
        option key 'arandomwifikey'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'HE160'
        option country 'US'
        option cell_density '0'
        option noscan '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid '5G'
        option encryption 'sae-mixed'
        option key ''arandomwifikey'

Well, 2G works fine, but not 5G. The output of iw event -f -t when restarting the radios is:

1646423090.933209: wlan1 (phy #1): unknown event 60
1646423090.936422: phy #1: unknown event 94
1646423090.936546: phy #1: unknown event 94
1646423090.936594: phy #1: unknown event 94
1646423090.936639: phy #1: unknown event 94
1646423090.983843: wlan1 (phy #1): unknown event 8
1646423091.329078: wlan1 (phy #1): unknown event 7

2G is not giving me any problem. When connecting a device I get this output, but everything seems to be working fine:

1646423189.089119: wlan0 (phy #0): unknown event 60
1646423189.206039: wlan0: new station a6:7a:63:04:80:29
1646423189.254339: wlan0 (phy #0): unknown event 60
1646423189.286364: wlan0 (phy #0): unknown event 60
1646423189.289723: wlan0 (phy #0): unknown event 60
1646423189.486137: wlan0 (phy #0): unknown event 139
1646423189.490765: wlan0 (phy #0): unknown event 139
1646423189.742290: wlan0 (phy #0): unknown event 60
1646423189.748647: wlan0 (phy #0): unknown event 60

Any info on why 5G is not working in this snapshot but it is working fine in the UBI sysupgrade image used in the firmware installation from Nov 2021.

Ι have not tested extensively the 5G band, occasionally some of my phone connect to 5G but not for a long time.

For both bands I had all short of issues until I applied the disconnected due inactivity fix as i said before. I am testing it for a phew days now , my android's S8 and S9 phones was always been able to connect to wifi successfully mostly at the 2.4G band.

I have narrowed the problem down to the support HE160 mode in the CH36-64 band. When using HE80 everything works fine. I really don't know when that happened, but for sure HE160 mode (160MHz channel) was properly supported in the past. Tested and validated in SNAPSHOT r18646-3869ccbcc8 but fails in SNAPSHOT r19040-247eaa4416

Might be fixed in future by

2 Likes

Well I got hit by the "no connectivity" issue once again after couple days this time, similar to the @ilshatms.

From dmesg:

[543156.909270] br-lan: port 1(lan1) entered disabled state
[543156.922398] mt7530 mdio-bus:00 lan1: Link is Down
[543179.791306] mt7530 mdio-bus:00 lan1: Link is Up - 100Mbps/Full - flow control off
[543179.798928] br-lan: port 1(lan1) entered blocking state
[543179.804235] br-lan: port 1(lan1) entered forwarding state
[543189.158624] br-lan: port 1(lan1) entered disabled state
[543189.164827] mt7530 mdio-bus:00 lan1: Link is Down
[543191.231516] mt7530 mdio-bus:00 lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[543191.239306] br-lan: port 1(lan1) entered blocking state
[543191.244615] br-lan: port 1(lan1) entered forwarding state

From logread:

Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: binding station to interface 'wlan0'
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: authentication OK (FT)
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 MLME: MLME-AUTHENTICATE.indication(08:c5:e1:61:0d:b0, FT)
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: association OK (aid 4)
Mon Mar  7 05:34:16 2022 daemon.info hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: associated (aid 4)
Mon Mar  7 05:34:16 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 08:c5:e1:61:0d:b0
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 MLME: MLME-REASSOCIATE.indication(08:c5:e1:61:0d:b0)
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 IEEE 802.11: binding station to interface 'wlan0'
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 WPA: event 6 notification
Mon Mar  7 05:34:16 2022 daemon.notice hostapd: wlan1: Prune association for 08:c5:e1:61:0d:b0
Mon Mar  7 05:34:16 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 08:c5:e1:61:0d:b0
Mon Mar  7 05:34:16 2022 daemon.debug hostapd: wlan0: STA 08:c5:e1:61:0d:b0 WPA: FT authentication already completed - do not start 4-way handshake
Mon Mar  7 05:34:18 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DISASSOCIATE.indication(08:c5:e1:61:0d:b0, 1)
Mon Mar  7 05:34:18 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DELETEKEYS.request(08:c5:e1:61:0d:b0)
Mon Mar  7 05:34:46 2022 daemon.info hostapd: wlan1: STA 08:c5:e1:61:0d:b0 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Mar  7 05:34:46 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DEAUTHENTICATE.indication(08:c5:e1:61:0d:b0, 2)
Mon Mar  7 05:34:46 2022 daemon.debug hostapd: wlan1: STA 08:c5:e1:61:0d:b0 MLME: MLME-DELETEKEYS.request(08:c5:e1:61:0d:b0)

I checked if the phone was still connected with :

iw dev wlan0 station dump

It was still connected (unfortunately I forgot to copy the output).

I tried to perform the

iw dev wlan0 scan trigger freq 2447 flush

as user @sammo stated in https://forum.openwrt.org/t/archer-c7-2-4-ghz-wireless-dies-in-24-48-hours/44163/150?u=nkef

And I got connectivity back without needing to restart wifi or reboot the router , we may need to apply one of the workaround scripts suggested on that forum posts to apply the scan every time an event 60 occurs.

Maybe it is related to the https://forum.openwrt.org/t/archer-c7-2-4-ghz-wireless-dies-in-24-48-hours/44163/223?u=nkef

1 Like

I applied the workaround script provided by @Catfriend1 in https://forum.openwrt.org/t/archer-c7-2-4-ghz-wireless-dies-in-24-48-hours/44163/211?u=nkef

that triggers "iw dev wlan0 scan trigger freq 2447 flush" when event 60 occurs.

https://github.com/Catfriend1/openwrt-presence/blob/master/scripts/ath9k-watchdog/ath9k-watchdog.sh

1 Like

The workaround seems to work , I have not encountered the "no connectivity" issue on the 2.4 GHz band the last 8 days.

Of course it is not a proper solution ...

I tried the same solution & yes it works, but because the unknown event 60 occurs every 30 seconds to 3 minutes, the script runs iw dev wlan0 scan trigger freq 2447 flush every 30ish seconds.

I'm not sure what's the performance implications of the above, but just wanted to highlight that.

BTW this is just FYI, the ath9k-watchdog.sh script only triggers the scan when 2.4GHz encounters event 60, but I have more event 60s on 5GHz & it works w/o a problem.

I've had this for a long time with my RT3200s. Namely my wife's iPhone loses WiFi connectivity pending manual reconnection.

Does everyone still have this issue too?

Could it be an iPhone issue since it doesn't happen with my Google Pixel 3A?

@Lynx no it is not specific to iPhone , it occurs with any 2.4 GHz device , for example printers, android devices , any iOS devices e.t.c.

@Lynx - I disabled cell density coverage option cell_density '0' and she hasn't complained to me about her phone dropping since doing that... but if I look in my log, I see tons of entries indicating the drop occurred to this day.

It's not just the mac address corresponding to her iPhone X, my 13 is present there as well as an iPad too.

Below, xx:xx:xx:xx:xx:xx is the mac address of the iPhone X which happened dozens of times. I just show one representative example:

# logread | grep xx:xx:xx:xx:xx:xx
...
Fri Apr  8 13:34:18 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  8 13:37:51 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Apr  8 13:37:51 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 3)
Fri Apr  8 13:37:51 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:37:51 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Apr  8 13:37:51 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:38:08 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:38:08 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
Fri Apr  8 13:38:09 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Fri Apr  8 13:38:32 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Apr  8 13:38:32 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 3)
Fri Apr  8 13:38:32 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:38:32 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Apr  8 13:38:32 2022 daemon.notice hostapd: wlan1: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:38:52 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Apr  8 13:38:52 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
Fri Apr  8 13:38:53 2022 daemon.info hostapd: wlan1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
...

I think there may be separate issues here. I have 3x RT3200's connected via WDS (one guest WiFi WDS AP on 2.4 and another normal Wifi WDS on 5) and. I have FT. All works fine for all devices save for the iPhone. So I wonder if there may be something broken with your config?

@darksky are you seeing this only for Apple type devices?

For mobiles yes, for laptops no. Non-apple laptops do not show this. Seems to only be the Apple mobiles.

@darksky and @darksky
When the issue occurs no Wifi device can access the network in my case, I can only access the AP via the ethernet interface.

1 Like

When I see this issue, it includes my iPhone devices and MacBooks. It's quite frustrating. :frowning:

1 Like

Still an open issue... 6 days of uptime and 63 DEAUTH messages.

# logread| grep DEAUTH|wc -l
63

My wife's Apple iPhone and tablet is also disconnecting randomly it seems. Everything else works perfectly. What gives? What's the fix guys?

hi i have a same problem

try to change DTIM to defaut in 1

in advanced configuration

network wireless before