Cannot connect to 5.26 GHz WiFi

I have the following:

Model TP-Link Archer C2600
Architecture ARMv7 Processor rev 0 (v7l)
Firmware Version OpenWrt 18.06-SNAPSHOT r7715-9f2cbca / LuCI openwrt-18.06 branch (git-19.020.41695-6f6641d)
Kernel Version 4.14.48

This device is set up as an access point.
This device will often drop clients connected on the 5GHz WiFi connection and I have a devil of a time reconnecting them (soft and hard reboots usually don't work - not sure what really fixes the problem when it does finally reconnect.)

Here is a log of an android phone trying to connect to this access point:

Fri May 24 22:58:13 2019 odhcpd[627]: Using a RA lifetime of 0 seconds on br-lan
Fri May 24 22:58:20 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 7c:d9:5c:b3:82:69
Fri May 24 22:58:20 2019 hostapd: wlan0: STA 7c:d9:5c:b3:82:69 IEEE 802.11: authenticated
Fri May 24 22:58:20 2019 hostapd: wlan0: STA 7c:d9:5c:b3:82:69 IEEE 802.11: associated (aid 1)
Fri May 24 22:58:20 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 7c:d9:5c:b3:82:69
Fri May 24 22:58:20 2019 hostapd: wlan0: STA 7c:d9:5c:b3:82:69 WPA: pairwise key handshake completed (RSN)

Anyway suggestions?

1 Like

ath10k depends to a huge extent on the firmware blob, uploaded to the wlan cards - there have been quite significant updates in upstream ath10k firmwares (albeit mostly for the newer chipsets) and there is ath10k-ct in master, both are worth having a look at.

The thing that's killing me is that I have three routers with the same hardware, firmware and settings and this is the only one that acts like this.

Any suggestions on how to start looking at the different firmwares?

Depending on your region. frequencies in the 5 GHz band might be required to do DFS, which has implications on the reliability to use them (and the DFS detector might trigger for 'normal' interference as well).

three identical devices, or different devices with same hw specs?

uci show wireless ???

Here is the output from uci show wireless:

uci show wireless
wireless.default_radio1.ssid='Reboot Guest'
wireless.@wifi-iface[1].network='lan wan wan6'
1 Like

Identical hardware (identical: same versions of hardware, manufacturer, revs, etc.)

1 Like

We are located near an air force base... could be this is the problem?

1 Like

Very likely, (weather-) radar is the exact reason why devices must vacate a radar encumbered channel immediately; radar is the primary (licensed) user of those frequencies, wlan is only allowed to re-use them if there is no radar in sight.

According to this article:
I should be able to use 36, 40, 44, 48, 149, 153, 157 and 161. I tried moving to one of these channels but nothing has changed.

1 Like

try to switch places of misbehaving unit with the working one. if it still acts like that in a place where another one works fine it could indicate hw problem

I swapped locations as @psyborg suggested and it did not help. I reinstalled the firmware and it fixed it (temporarily). In my infinite wisdom, I tried to spread my channels around so that they would not overlap. That broke it. I then changed all (4) of my access points to b: 36, 40, 48, and 136. I rebooted the devices and they are all working fine.

I believe there is an issue with channel selection, but it is more restrictive than suggested before. I think what really fixed it was to set the channels lower and ensure to reboot if you get the "wireless not associated" error.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.