Onhub TP-LINK TGR1900 future support?

Is there a way to have only one network and not one for 2.4ghz and another for 5ghz like on original firmware?

If you configure both radios with the same access credentials, you get exactly what you want - but you do have to configure them both individually.

Won't that cause some conflict? Do they need to have same other settings like isolate client, WPA version etc?

Technically, no - you could configure each individually however you like.

Functionally it is sensible to use exactly the same settings for both radios, making them part of the same network.

Set the channel to 'auto' when setting up the 2.4 and 5Ghz APs.

I have 3 x TP-Link TGR1900 running OpenWRT 23.05.5. One is rock solid. The other two are getting SWBA overrun error which seem to cause devices to fail connecting to 2.4Ghz radio. I have tested all 3 using the same OpenWRT config backup, one at a time, over a few days each, so think I have ruled out an OpenWRT configuration setting.

Anyone else getting these errors?

Mon Apr  7 13:16:10 2025 kern.warn kernel: [39187.766525] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
Mon Apr  7 13:16:10 2025 kern.warn kernel: [39187.800670] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon
Mon Apr  7 13:16:10 2025 kern.warn kernel: [39187.834792] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 2, skipped old beacon

The interesting thing I noticed was that before I converted them to OpenWRT the rock solid one arrived with Google WiFi configured and successfully copied OpenWRT without having to wipe mmcblk0.

dd if=/dev/zero bs=1M of=/dev/mmcblk0

The second one also installed OpenWRT the same, and worked well without errors, until I tried changing config and the router would not boot. I could not recover so used the Google Recovery Factory Reset USB. Once I had access again I installed OpenWRT but had to wipe mmcblk0 for it to boot without USB. Since then it gets the SWBA overrun errors.

The third one arrived unconfigured/reset to default and when installing OpenWRT also required wipe of mmcblk0 for it to boot without USB. It also gets the SWBA overrun errors.

Does anyone think there is a correlation here?
Is it possible that something in the ChromeOS restore changes driver/setting that carry across to OpenWRT?
Does anyone know of a place I can download versions of ChromeOS for this device earlier than:

https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_9334.41.3_whirlwind_recovery_stable-channel_mp.bin.zip

Why? :slight_smile:
(This is not a requirement for having one SSID span both the 2.4 and 5G bands.)

chromeos_9334.41.3_whirlwind_recovery_stable-channel_mp.bin.zip

I use the same version for my factory restores (and have 3 of the TP-Links, like you.)

You can try a block size of 1k for your dd cmd (bs=1k) and see if that helps. (Performance should be roughly the same, given it's an MMC chip.)

Also, re-reading your post, it sounds like your last 2 attempts/routers are giving you issues (but the first one is fine?)... so maybe the USB media itself has gone bad? Have you tried recreating that again?

Thanks for the confirmation that yours are working using same chromeos version.

I will try the smaller block size soon.

The USB media was brand new but I will try another one just in case.

Again thanks for the help.

1 Like

Obviously you don't HAVE to let the router scan traffic in your area and pick the best channel automatically and you can just set the channel to whichever one you want. It fact, the 'auto' setting doesn't work on every router -- but it does work on the OnHub. Use it if you want. Or not.

You probably just need an updated version of ath10k_pci driver. Best way to do it is with an attended system upgrade. Even if you are on the same version, you'll get the updated packages in the process.

How to upgrade OpenWrt?

You can also try adjusting the beacon interval:

config wifi-device 'radio0'
    option beacon_int '200'  # Increase from default 100ms
    option dtim_period '3'   # Reduce DTIM broadcasts

Change the load management:

option max_assoc '20'  # Default is often 128

Or some advanced kernel parameters:

net.wireless.ath10k.debug=0
net.core.netdev_max_backlog=1000

Could also just be interference. Check that:

iw survey dump

Just the first option updating the firmware is probably all you need to do or try first.

Thanks for taking the time to list all those things.

AUC only shows updates for LUCI packages and nothing for ath*. I can install 24.10.0 but tried that already and it was even less stable.

# auc
auc/0.3.2-1
Server:    https://sysupgrade.openwrt.org
Running:   23.05.5 r24106-10cc5fcd00 on ipq806x/chromium (tplink,onhub)
Available: 23.05.5 r24106-10cc5fcd00
Requesting package lists...
 luci-app-opkg: git-24.148.43905-2891ca4 -> git-25.097.68147-23477a1
 luci-mod-system: git-24.067.01860-7a82b2f -> git-25.097.68147-23477a1
 luci-theme-bootstrap: git-24.086.46634-1ffe078 -> git-25.097.68147-23477a1
 luci-mod-status: git-24.212.61237-b6da3f2 -> git-25.097.68147-23477a1
 luci-app-firewall: git-24.067.01746-69867db -> git-25.097.68147-23477a1
 luci-ssl: git-23.035.26083-7550ad6 -> git-25.097.68147-23477a1
 luci-proto-ppp: git-24.135.44542-f1ec9c2 -> git-25.097.68147-23477a1
 luci-mod-admin-full: git-19.253.48496-3f93650 -> git-25.097.68147-23477a1
 luci-base: git-24.264.56413-c7a3562 -> git-25.097.68147-23477a1
 luci-proto-ipv6: git-24.086.45108-51aee90 -> git-25.097.68147-23477a1
 luci: git-23.051.66410-a505bb1 -> git-25.097.68147-23477a1
 luci-light: git-23.024.33244-34dee82 -> git-25.097.68147-23477a1
 luci-mod-network: git-24.264.56960-63ba3cb -> git-25.097.68147-23477a1

Wouldn't these values be the same on all the routers if I do a sysupgrade to same version 23.05.5 clearing nvram and then restore the same backup?

Reason I say this is because the good router, from which I made the backup, works without issue where as the two other ones, with exact same config (replacing working router), do not work reliably in the same location.

Have about 50 WiFi devices that get split between 3 Dumb APs about 20, 20, 10. There are about 10 more Ethernet connected devices.

I am separated well from neighbors and most of the time do not pick up any other stations broadcasting that are not mine. Use channels 1,6,11.

# iw phy0-ap0 survey dump
Survey data from phy0-ap0
        frequency:                      2412 MHz
        noise:                          -101 dBm
        channel active time:            46 ms
        channel busy time:              7 ms
Survey data from phy0-ap0
        frequency:                      2417 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              3 ms
Survey data from phy0-ap0
        frequency:                      2422 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              2 ms
Survey data from phy0-ap0
        frequency:                      2427 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              2 ms
Survey data from phy0-ap0
        frequency:                      2432 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              1 ms
Survey data from phy0-ap0
        frequency:                      2437 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              8 ms
Survey data from phy0-ap0
        frequency:                      2442 MHz
        noise:                          -100 dBm
        channel active time:            46 ms
        channel busy time:              0 ms
Survey data from phy0-ap0
        frequency:                      2447 MHz
        noise:                          -101 dBm
        channel active time:            46 ms
        channel busy time:              0 ms
Survey data from phy0-ap0
        frequency:                      2452 MHz
        noise:                          -101 dBm
        channel active time:            46 ms
        channel busy time:              0 ms
Survey data from phy0-ap0
        frequency:                      2457 MHz
        noise:                          -101 dBm
        channel active time:            46 ms
        channel busy time:              1 ms
Survey data from phy0-ap0
        frequency:                      2462 MHz [in use]
        noise:                          -101 dBm
        channel active time:            6696498 ms
        channel busy time:              915327 ms
        channel receive time:           37226 ms
        channel transmit time:          49890 ms

I tried clearing mmcblk0 again using bs=1K and see the same errors spamming the log.

Since I have OpenWRT on it already I did the following directly on the router:

cd /tmp
wget https://downloads.openwrt.org/releases/23.05.5/targets/ipq806x/chromium/openwrt-23.05.5-ipq806x-chromium-tplink_onhub-squashfs-factory.bin
sha256sum openwrt-23.05.5-ipq806x-chromium-tplink_onhub-squashfs-factory.bin
// a9401af132c65a9a1eb7bd03d2e79f8410480566e644526ee262612bef3fce37 CORRECT
dd if=/dev/zero bs=1K of=/dev/mmcblk0
dd if=/dev/zero bs=512 seek=7552991 of=/dev/mmcblk0 count=33
dd if=/tmp/openwrt-23.05.5-ipq806x-chromium-tplink_onhub-squashfs-factory.bin of=/dev/mmcblk0 bs=1K
reboot now

This brought up the router using default setting 192.168.1.1
I then restored backup from my good router which is also on 23.05.5.
Unhooked good router and replaced with this one.
Router came up fine with everything reconnecting and within 5 minutes was showing the SWBA overrun on vdev 0-2 as before.

Did I do it correctly?

Sorry, I just caught this now.
Are you restoring a backup from router (x), onto a different router (y), while (x) is still online? If so, that could lead to potential MAC address collisions and/or SSH key collisions. Just FYI. :wink:

Additionally, have you tried swapping between the CT and Non-CT drivers?
I've got my 3 TP-Links all wired backhaul and with CT drivers == very stable. (I mention this because some people report having better success with Non-CT when using wireless mesh.)

Finally, speaking of firmware, I notice you are pulling stable 23.05.5 from openwrt site. If you plan to use that version, why not grab one of the firmwares built by the fine users here? They contain NSS drivers, which I believe are missing from 23.05.5 stable.

If the CT drivers are installed, then that's the problem for sure. I've never been able to get it to work reliably with the -ct drivers and the documentation for mesh states explicitly that they don't support mesh.

If it were me I'd go ahead and copy all the list of packages from the text file created by:

opkg list-installed | cut -f1 -d ' ' > /tmp/installed.txt

And go to the firmware builder and make a new image with the same packages in the text file making sure you don't reinstall ct drivers if they are installed. Then flash the new firmware keeping configuration settings.

1 Like

Thanks, I did have the ATH10 CT drivers and switching to a custom build with non CT drivers seems to have fixed the SWBA overrun errors. Just did a UI upgrade keeping settings and everything worked. 24 hours and no error!

2 Likes

Make a backup when you get it working and likewise, keep a list of the installed packages in a text file separately using the command I put in the last message. I've done that with every variation of configurations I've experimented with. With these, you can build a custom firmware package, and restore a backup and be exactly where you want to be. The backup alone isn't enough because it only backs up the configuration, not the various packages you may have accumulated in getting things to work. Never upgrade single packages either. Use the attended sysupgrade in Luci and check the advanced configuration box if you want to upgrade to the latest collection of packages and keep the configuration. In the advanced configuration of sysupgrade, you can add or remove and change packages too. AUC is not quite so versatile.

1 Like

Anyone upgraded to 24.0.1 already? All working well?

I have not risked it yet. I'm the usual guinea pig, but not this time. I have finally finished my custom build of 23.05.5 with NSS support. This build achieves enterprise-grade throughput (>900Mbps NAT) with sub-5% CPU utilization. Based on the patches created and optimized by @KONG @vochong @ACwifidude and six months of trial and error. Try at your own risk. I'm finally satisfied with it myself.

openwrt-ipq806x-chromium-tplink_onhub-squashfs-sysupgrade.bin

1 Like

All good:

...with the caveat (as mentioned previously) that you cannot perform an upgrade from 23.x to this version, because of the shift from switch to DSA:

1 Like