I’m quite certain that no OEM Wi-Fi access point manufacturer uses the Candela Tech (CT) driver or firmware, except Candela Technologies themselves for their Wi-Fi testing equipment. OEMs typically use proprietary firmware and drivers provided directly by Qualcomm for their QCA-based Wi-Fi access points, which is why they can achieve the highest Wi-Fi throughput performance. However, this also means their firmware is usually tied to much older Linux kernel versions.
Two of at least two dozen coming to mind, without even thinking about the details.
Since I’m compiling from source, perhaps you could point me to the resource documenting the two dozen identified security flaws so I can address them the same way the developers did for the new iteration? Why would it be a secret?
Sure, https://git.openwrt.org/?p=openwrt/openwrt.git;a=log. If you want a more detailed list, that would be your homework. Backporting and assuming responsibility to keep old releases maintained is painstakingly hard- and boring work, it is what keeps RHEL, SLES and friends in business and where they spend most of their paid workforce on, because 'no one' would do that voluntarily (given the the easier route is to 'just update' to the current version). No one's keeping a list, the ~two dozen was just a rough number of serious security fixes (more serious than the ones you identified) I remembered off the top of my head (and that number is very much on the conservative side, if you dive in deep into the details, there will be more, of varying degrees of severity). The first job of backporting is always identifying the potential changes among all the 'noise', and this takes real effort - while being aware that quite often changes may not appear security relevant at first, but can be very serious nevertheless.
How did you find out about the dozens of undocumented security flaws in 23.05?
Because I am following (among other sources) the aforementioned git history and have a rough idea what's been fixed within the last 6 years?
Has anyone documented them all? It must be somewhere since the next iteration corrected them.
I’m doing a little self-reflection here now…
I think my issue has to do with “sunk costs.” I’ve spent so much time creating my version of firmware and it’s working so well, I’m very reluctant to move on. I seriously doubt my home router will be a target of state actors exploiting an obscure theoretically possible exploit no one has actually suffered but is technically possible.
However, I’m wondering the best way to move on. Sunk costs are something no one should consider in decisions you make today. They are gone and you never get them back no matter what you do.
The OnHubs are just not the best hardware to use as a main router even optimized to the maximum possible as I have done. The GL-iNet routers are the best IMHO. I’m thinking my plan to move on is to figure out the best possible package configuration for 24.10.4 to use the OnHubs as Bridged Access Points. Then when that is all working correctly, install the third-party Candela Technologies beta drivers for the QCA988x chipset the OnHub uses.
Since the NSS drivers are not involved when the OnHub is an access point, but the Candela Technology drivers can integrate into 24.10.4 builds to improve WiFi performance, client handling, and CPU efficiency – that seems to be the best way to go here.
I’m going to try some experiments.
1 Like
If you ask me, it works perfectly as it is. 24.10.2 stable version. Of course, they may have shortcomings. Just because Google has discontinued support for these devices doesn't mean they should be shelved. These devices can still easily handle gigabit speeds. But as you mentioned, Candela's beta drivers actually work much better than the versions in the official OpenWrt repo. I've personally tested them on the NBG6817 and EA7500v1, including the OnHub. There doesn't seem to be any alternative to candela at the moment.
I’m a compulsive tinkerer and getting worse as I learn how to do more things. I’m leaning into optimizing my two OnHubs (one TP-Link and one Asus) as Bridged Access Points. Access points don’t benefit from NSS drivers, but do benefit from the Candela Technologies driver that does speed up WiFi performance and fixes fast roaming issues with the official OpenWrt CT drivers installed by default.
I’m trying to figure out exactly the optimal firmware setup to use with 24.10.4 for this purpose. I want to include only key components and add additional packages needed in the overlay. The idea is that frequently updated packages are in the overlay. I’m going to manually install the Candela beta drivers to that.
Additionally, since both OnHubs are optimized OpenWrt APs, the main router is going to be a mini x86 PC running ipfire. I’ve been experimenting with that and it’s powerful and relatively easy with strong security. At the moment, I’m still using my own custom 23.05 NSS firmware on the OnHubs and configured them both as APs. It’s exciting to see how they actually work so well in this setup.
Anyway, I’m forcing myself not to tinker too much at this point. I’m sure it’s theoretically possible some state actor could exploit the OnHubs in some way I can’t imagine, but I’ve got to believe my little home system is far more fortified than anyone in my neighborhood and such actors would not be interested in what I’m streaming on my TVs or chatting about on these forums.
2 Likes
Are you using https://www.candelatech.com/downloads/ath10k-fw-beta/firmware-2-ct-non-commercial-full.bin ?
What’s the (approximately) max WIFI throughput you have ever got on this Asus Onhub?
I’m not using that one. That one is bit for bit identical to the one in the OpenWrt repository.
I’m using this one: https://www.candelatech.com/downloads/ath10k-fw-beta/firmware-2-ct-non-commercial-full-htt-mgt.bin
Free for non-commercial use. Not sure how long these will be up, so download a copy to archive.
Candela’s Beta (-22): 5.15.189 Kernel with NSS Hardware Offloading was over 700 Mbits/second peak but usually high 600s. There’s a long list of bugs corrected in the 13 months between the release driver (which is in the OpenWrt repository as the htt-full version) and the beta. Their log isn’t specific about the changes, but says fast roaming errors were addressed. But even the beta is pretty old - but the last best available.
This note is mostly for my future reference, but might be useful to others building an OnHub firmware optimized for use as a Bridged Access Point only.
Package selection for Firmware Selector:
base-files ca-bundle dnsmasq dropbear firewall4 fstools kmod-ata-ahci kmod-ata-ahci-platform kmod-ath10k-ct kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload kmod-phy-qcom-ipq806x-usb kmod-sound-soc-ipq8064-storm kmod-usb-dwc3-qcom kmod-usb-ledtrig-usbport kmod-usb-ohci kmod-usb2 kmod-usb3 libc libgcc libustream-mbedtls logd luci mtd netifd nftables odhcp6c odhcpd-ipv6only opkg ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd wpad-mbedtls e2fsprogs kmod-fs-ext4 losetup mkf2fs nano partx-utils -ath10k-firmware-qca988x-ct ath10k-firmware-qca988x-ct-full-htt
Thanks @KSofen for the information.
Unfortunately, in my environment, the firmware-2-ct-non-commercial-full-htt-mgt.bin firmware doesn’t seem to improve throughput compared to the other CT firmware versions. The mainline ath10k firmware still delivers noticeably better performance, so I’ll stick with that for now.
…you are using an OnHub correct? Lots of variables here and I have tinkered and toyed with every small detail which may explain the difference. Try the beta I linked instead of the release version. There’s a difference. @divinecougar has noticed this too. Another issue with the Asus OnHub is that you must do a clean install of the NSS firmware and not restore a backup because the old packages in the backup overwrite the newer ones in the overlay replacing those in the newer flashed firmware. I don’t know why this happens but it does.
Yes it’s Asus OnHub.
Can you check to see if the ath10k-ct firmware you’re using has this md5sum:
md5sum /lib/firmware/ath10k/QCA988X/hw2.0/firmware-2.bin
859869a0f3b062abce522e2e7293ad0b /lib/firmware/ath10k/QCA988X/hw2.0/firmware-2.bin
Get-FileHash -Algorithm MD5 firmware-2.bin
Algorithm Hash
MD5 859869A0F3B062ABCE522E2E7293AD0B
Make sure the only files in /lib/firmware/ath10k/QCA988X/hw2.0/ are board.bin and firmware-2.bin.
OpenWrt will use the ct-firmware-2.bin if it’s in that directory.
It took me a lot of trial and error to figure out that the only way to get it to work with the latest version of firmware is to do a clean install of my custom NSS firmware file and not restore the configuration from a backup. The older files in the backup overwrite the newer files you just flashed to the firmware. You have to reassemble your complete setup from scratch. Then you have to delete everything in /lib/firmware/ath10k/QCA988X/hw2.0 except board.bin and upload the beta CT firmware to that directory and rename it to firmware-2.bin, then reboot.
2 Likes
While we’re on the subject… Is there a way to flash new firmware and then restore your configuration from a backup and prevent older packages in the backup from overwriting the newer packages in the new firmware you just flashed?
Hi there! Is any easy way to reflash OpenWRT if I can't access to currently flashed via SSH or Luci (LAN port not working on flashed build)? Or only back on stock image and then follow instruction on main page?
Thank you! But how exactly to save configuration? After simple reboot it looks like factory reset. All the settings and installed packages gone. I tried to save currently configuration in Mount Points menu, but no good.
Since the kernels of the existing packages are incompatible with the new version, the packages are not installed when the firmware is changed.