GL-AR750 with 22.03.2


I have a GL.iNet GL-AR750 "Creta" which I have been trying to use up to date OpenWrt on.

I have attempted installing both 22.03.2 and the latest snapshot .bin files, i.e.:

I started by upgrading to the latest GL.iNet firmware (3.216) and installing LuCI. I first tried installing 22.03.2 via LuCI and keeping the settings (just barebones fresh install). That worked and I went about testing it. 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, but that's still not a guarantee. I also found that the LAN ports don't seem to work.

So I went about trying various permutations of installs, e.g. using either 22.03.2 or the latest snapshot build and installing either via u-boot interface or LuCI interface, and starting with or without migrating the settings. I found that there's no notable differences, other than that if I don't migrate the settings it seems to install a VERY barebones OpenWrt, which doesn't include any device specific settings (e.g. knowing what the LEDs are for) and doesn't include any http server or LuCI.

Are there any other users with the GL-AR750 Creta successfully running the latest OpenWrt with full functionality reliably?

You're describing known behavior/issue on some devices while scanning.

Now that's really odd.

Only install the release versions, then. See:

There's a way to configure LEDs. See:

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.

1 Like

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.

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.

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

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:

Have you made major changes to the default config?

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

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-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.

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.

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.

Uses same process.

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.

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.

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.

1 Like

What are you playing with?

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.

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.

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.

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.

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.

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

Yea, it must be some algorithm. Interesting.

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
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 19.07.8"
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
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 -p [::]:80 -

root@GL-AR750:/# strings /www/cgi-bin/api | grep scan
iwinfo ra0 scan | grep -A 3 '%s' | grep Channel | awk -F ' ' '{print $4}'
iwinfo %s scan | grep '%s'

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/, no section header

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

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.

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.

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

Seems LuCI actually calls iwinfo...
OpenWrt callIwinfoScan - luci-static network.js - 2022-11-20

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.