GL-AR750 with 22.03.2

[hnyman]

I have gl-ar750 as a travel router (but travelling has been minimal since I bought the device, sadly).

My experience matches you: better to use 2.4 and 5 mixed. One for upstream and one for own client devices.

I also achieved better stability (year ago) by switching 5 GHz WiFi driver from ath10k-ct to ath10k mainline. (Can be removed with opkg and the alternative driver installed.)

I have no recollection about Lan port troubles. But you might need to select the right mode with the physical switch.

[bndr]

Thanks, it's unfortunate then if the WiFi drivers are so unstable for this device. I have no such issues with the drivers from the vendor image.

Re: No http server or LuCI on default install... I'm having the same issue with both the release and the snapshot. I tried release first and only tried snapshot after release was having issues. I'm also aware of how to configure the LEDs but pointing out that the default install is hopelessly barebones.

[bndr]

Thanks, I might be willing to try playing with the WiFi drivers if I could get ethernet working. Otherwise, I need to pry the thing open and connect to the serial header.

Is anyone willing to share their config file backup from a working GL-AR750? Just want to double check I'm not missing anything with the configuration.

[lleachii]

@bndr

it's unfortunate then if the WiFi drivers are so unstable for this device. I have no such issues with the drivers from the vendor image.

Odd, I always notice this - most OEMs seem to just use some algorithm that merely slows connections (by appearance from my observation at least). It also depends on what channel the AP is using when the scan starts (not for the scan, but to return to that channel to TX to clients).

@bndr

Re: No http server or LuCI on default install...

It's unclear what you mean, as release versions have the web GUI installed by default. This leads me to believe there's other issues. Here's the link: https://downloads.openwrt.org/releases/22.03.2/targets/ath79/generic/openwrt-22.03.2-ath79-generic-glinet_gl-ar750-squashfs-sysupgrade.bin

@bndr

Is anyone willing to share their config file backup from a working GL-AR750?

Have you made major changes to the default config?

@bndr

I'm also aware of how to configure the LEDs but pointing out that the default install is hopelessly barebones.

• Which lights?
• Perhaps lights for features not existing by default in OpenWrt?
• These? https://openwrt.org/toh/gl.inet/gl-ar750s#leds

(BTW, you can use one post to respond to 2 people - as we can all see.)

[bndr]

Thanks, I just tried the release image from u-boot again and for some reason it's working today! It's the same one as I linked initially and I haven't even redownloaded it, so not clear what happened differently now. LuCI was just sitting there ready to go when it booted up, and the radio status LEDs are working with no added configuration.

Re: Lights... Well, the vendor image has this in /etc/config/system...

config led 'led_wlan2g'
	option name 'WLAN2G'
	option sysfs 'gl-ar750:white:wlan2g'
	option trigger 'phy1tpt'

config led 'led_wlan5g'
	option name 'WLAN5G'
	option sysfs 'gl-ar750:white:wlan5g'
	option trigger 'phy0tpt'

I just checked the OpenWrt release files after getting it booted up and initializing the radios and all I see for LEDs is this, but it is working as expected:

$ grep -A2 -B2 -w led /etc/config/*
/etc/config/ucitrack-
/etc/config/ucitrack-config system
/etc/config/ucitrack:   option init led
/etc/config/ucitrack-   option exec '/etc/init.d/log reload'
/etc/config/ucitrack-   list affects luci_statistics

Re: config customizations. None really, just a barebones fresh install.

[bndr]

Okay, next problem I am noticing:

If I try to load the Channel Analysis page for the 5GHz radio, it doesn't work. It is fine for 2.4. Not only does it not work, but it seems to lock up LuCI such that I can't load any other pages (e.g. in a different browser or tab) until several seconds after I close the tab or try to return to the home page.

[lleachii]

@bndr

Okay, next problem I am noticing:

If I try to load the Channel Analysis page for the 5GHz radio, it doesn't work. It is fine for 2.4. Not only does it not work, but it seems to lock up LuCI such that I can't load any other pages

You were already noted this, and 2 responses were given (additionally, you responded to those replies). You seem to be describing the same issue:

@bndr

I found that trying to run channel scans causes WiFi clients to drop most of the time. It seems a bit more reliable if you are connected to 2.4G and try to scan on 5G or vice versa

[bndr]

@lleachii

You were already noted this, and 2 responses were given (additionally, you responded to those replies). You seem to be describing the same issue:

Similar, but separate issue. I was describing performing a scan on the Network > Wireless page initially. What I described most recently was trying to perform Status > Channel Analysis.

An update, anyway. I've just uninstalled the ath10k-ct drivers:
opkg remove kmod-ath10k-ct ath10k-firmware-qca9887-ct
And installed the mainline drivers:
opkg install kmod-ath10k ath10k-firmware-qca9887

After a reboot I have tried doing channel analysis (still wasn't working). I then tried scanning and found that it would only work if I disable my Client mode connection to a wireless AP. So, it won't work while the bottom line is enabled like this:

I then went back and found that channel analysis is also fine if the Client mode connection is disabled.

I tried running multiple scans. It still drops my WiFi connections, even if I'm doing a scan on the 5GHz radio while connected to the 2.4GHz radio, but it is less frequent than it was when I was testing yesterday.

Will need to go back to the ath10k-ct drivers and see if the behavior is the same.

[lleachii]

@bndr

Similar, but separate issue. I was describing performing a scan on the Network > Wireless page initially. What I described most recently was trying to perform Status > Channel Analysis.

Uses same process.

@bndr

that it would only work if I disable my Client mode connection to a wireless AP.

Ummm, yes that's correct (for what I thought was obvious reasons until now). You failed to mention you had a client connection.

If you want to look at another channel (e.g. received data from a scan), you must change channels) - so hence the client connection drops, hence other pages/traffic drops.

Since Client must be connect before Master (i.e. so it knows what channel to use) - it must drop both.

[bndr]

Well, again, the vendor firmware is able to successfully perform scans without me having to manually play around with any of the radio settings and without any clients dropping.

[bndr]

I've just gotten around to testing the ethernet. It is working on this install, though it wasn't initially picking up the DHCP address that LuCI said it had issued. Re-enabling the interface on my workstation caught it though.

[lleachii]

@bndr

without me having to manually play around with any of the radio settings

What are you playing with?

@bndr

I've just gotten around to testing the ethernet. It is working on this install,

Yes, this should work, as you're not using the same WiFi at the same time of the scan.

Disregard, you're referencing the other issue, my bad.

@bndr

Re-enabling the interface on my workstation caught it though.

I don't understand what you mean by "caught".

Nonetheless, I've tested multiple times here on devices, I do not receive connection drops (today); but do have connection loss on browsers, clients etc., then connection returns - and I have a new channel update. I've experienced this behavior on all fimrwares/software for WiFi, OpenWrt, Linux distros, Windows and OEM firmware.

I've experience this on all WiFi scans on all firmware I've ever used. I'd love to see GL net's code.

[bndr]

@lleachii

I've experience this on all WiFi scans on all firmware I've ever used. I'd love to see GL net's code.

I have other devices where they can do scans without dropping clients. I was unaware this is a common issue. I've just gone back to the vendor firmware and can confirm that it reliably maintains my WiFi connection, while being connected to a WiFi AP as a client as well. I can SSH into the AR750 and SSH remains responsive while the scan is going too. The scan is also much faster.

@lleachii

What are you playing with?

I just mean that I didn't have to disable the Client mode connection to the wireless AP in order for the scan to work.

@lleachii

I don't understand what you mean by "caught".

I mean that the NIC on my workstation was able to pick up the DHCP IP it was assigned by the GL-AR750 after I re-enabled it.

[lleachii]

@bndr

I've just gone back to the vendor firmware and can confirm that it reliably maintains my WiFi connection

Yea, I also maintain the connection (i.e. don't drop SSID) - but only....60-70% of the time.

Tomorrow, I'll try to do some more extensive testing with 2.4 GHz client/master scenario (if/when said AP is not in heavy use during business hours).

@bndr

The scan is also much faster.

Yea, it must be some algorithm. Interesting.

[bndr]

FWIW, here's some info from the vendor image:

root@GL-AR750:~# opkg list-installed | grep ath10
ath10k-firmware-qca9887 - 2019-10-03-d622d160-1
kmod-ath10k - 4.14.241+4.19.193-1-1

root@GL-AR750:~# uname -a
Linux GL-AR750 4.14.241 #0 Thu Jul 29 19:50:28 2021 mips GNU/Linux

root@GL-AR750:~# cat /etc/os-release
NAME="OpenWrt"
VERSION="19.07.8"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 19.07.8"
VERSION_ID="19.07.8"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r11364-ef56c85848"
OPENWRT_BOARD="ath79/nand"
OPENWRT_ARCH="mips_24kc"
OPENWRT_TAINTS="busybox"
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt 19.07.8 r11364-ef56c85848"

root@GL-AR750:~# ethtool -i wlan0
driver: ath10k_pci
version: 4.14.241
firmware-version: 10.2.4-1.0-00047
expansion-rom-version:
bus-info: 0000:00:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

root@GL-AR750:/# ps | grep uhttpd
21212 root      3916 S    /usr/sbin/uhttpd -f -h /www -r GL-AR750 -x /cgi-bin -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0.0.0.0:80 -p [::]:80 -

root@GL-AR750:/# strings /www/cgi-bin/api | grep scan
sscanf
fscanf
get_wifi_scan_result
wifi_set_scan
wifi_scan_list_sort_by_signal
wifi_deinit_scan_list
scandir
glbigdata.bigdata.upload_scan_aps
iwinfo ra0 scan | grep -A 3 '%s' | grep Channel | awk -F ' ' '{print $4}'
iwinfo %s scan | grep '%s'
wireless.mt7628.noscan
wireless.%s.noscan
/data/upload/scan
/repeater/scan

root@GL-AR750:/# file /www/cgi-bin/api
/www/cgi-bin/api: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-mips-sf.so.1, no section header

Funny enough, just running iwinfo wlan0 scan from SSH seems pretty fast and reliable...

[bndr]

I've also now tested the Scan functionality in LuCI on the vendor image.

It still drops clients like the 22.03.2 release. I am able to perform a scan successfully while the GL-AR750 is connected to a wireless AP as a client, though.

Given that iwinfo scans work consistently and flawlessly, it now seems more like there's an issue with the way OpenWrt implements scanning.

[anon4457646]

@bndr

Well, again, the vendor firmware is able to successfully perform scans without me having to manually play around with any of the radio settings and without any clients dropping.

that is impossible in radio tecnology. a radio can do two type of things:
1 scan on all channels and client will lost connectionù
2 radio will not scan and client will not loose connection.
mabie you have the same ssid on the two radios, and the clients are able to switch band.

[bndr]

So... I just dug through the LuCI code a bit...

Seems LuCI actually calls iwinfo...

That callIwinfoScan is what gets returned by getScanList:

getScanList is what the handleScanRefresh code for the Wireless scan uses to pull the data:

I've been playing around with htop open while running scans from LuCI and actually have not been able to get any client drops at all for a while, bizarrely.

[lleachii]

I had to research scanning for another thread, see:

WiFi transition rules

@eduperez is correct, unless chip manufacturers are now in the habit of just adding multiple receive ability (on a different channels) for a few milliseconds of scanning - which I doubt. See: https://www.wi-fi.org/knowledge-center/faq/what-is-off-channel-scanning-for-wi-fi-access-points-aps https://www.wi-fi.org/knowledge-center/faq/what-is-off-channel-scanning-for-wi-fi-client-devices Also note these parts - which are relevant to this discussion: The operation of performing of…

You're probably right that your OEM's scan works better, the Wi-Fi Alliance actually says this is possible.

[ThiloteE]

Do you still have clients disconnecting?