Unable to make 5GHz wifi work on NETGEAR RBR40

Installing and Using OpenWrt
1

Recently I am working on making OpenWrt to work with (NETGEAR RBR40)[https://openwrt.org/toh/hwdata/netgear/netgear_rbr40] and RBS40, a set of routers NETGEAR produced as 'MESH' networking, with IPQ4019 processor, 512M RAM and 4G eMMC flash.

I am building firmware from the latest development snapshots and enabled several modules like LuCI to make configuration easier. I flash the firmware with the nmrpflash program and the router works as expected, except the 802.11ac wifi (11n works, though). The git log of the commit 2cb24b3f3c showed everything works correctly with RBR50, so I think there could be

I am still a newbie with OpenWrt and I found the config file /etc/config/wireless of OpenWrt greatly differs from the stocking firmware, and the MAC address of radios are not correct. I don't know if this could be related with the issue.

Here are my system logs and config files:
ubus call system board:

root@OpenWrt:~# ubus call system board
{
	"kernel": "6.6.74",
	"hostname": "OpenWrt",
	"system": "ARMv7 Processor rev 5 (v7l)",
	"model": "NETGEAR RBR40",
	"board_name": "netgear,rbr40",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"firmware_url": "https://downloads.openwrt.org/",
		"revision": "r28739-69890e16b3",
		"target": "ipq40xx/generic",
		"description": "OpenWrt SNAPSHOT r28739-69890e16b3",
		"builddate": "1738386419"
	}
}

cat /etc/config/network:

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdf8:17a2:3ec6::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan6'
	option device 'wan'
	option proto 'pppoe'
	option username '<REDACTED>'
	option password '<REDACTED>'
	option ipv6 'auto'

cat /etc/config/wireless

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/a000000.wifi'
	option band '2g'
	option channel '1'
	option htmode 'HT20'
	option txpower '30'
	option country 'AU'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid '<REDACTED>'
	option encryption 'psk2'
	option key '<REDACTED>'
	option wps_pushbutton '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/a800000.wifi'
	option band '5g'
	option channel '36'
	option htmode 'VHT80'
	option txpower '23'
	option country 'AU'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid '<REDACTED>'
	option encryption 'psk2'
	option key '<REDACTED>'
	option wps_pushbutton '1'

System Log: see [https://pastebin.com/3PbtECkJ]

Hope this will help finding the issue.

1 Like
2

I'm having the same issue with the release version of 24.10.0. I've tried enabling/disabling wds, changing channels (36, 40, 48, and 60), and a custom build with non-ct drivers, nothing seems to make a real difference. If I get my cell phone close, the 5ghz ssid will sometimes show up, but won't connect, usually it will say that I have the wrong password. The RBS40 doesn't show it in a scan, but it does show the 5ghz network from my asus router.

3

Same here with the 24.10.0 release: 2.4Ghz is working, but both 5Ghz Interfaces are super weak / not usable (client sees them only within ~10cm from the rbr40).
I tried more or less the same as @ozzie286 (additionally checked different country settings for WiFi) - no dice.

Did anybody even get the rbr40 5Ghz WiFi working properly in the past i.e. with an older Openwrt version?

Also, the commit which introduced support for the rbr40 says the device is identical to the rbr60 except for the antennas, and basically seems to enable the rbr60 modifications also for the rbr40. Maybe as a step forward: is there a way to check at runtime if the extracted calibration data for the ath10k is valid?

1 Like
4

It's not the rbr60, it's the srr60 and rbr50 that are identical in hardware to the rbr40. I've been debating trying to add rbr40 support to 23.05 to see if 5ghz works there, but haven't had time to look into it - specifically the toolchain required to build 23.05. I did just try the latest snapshot, r29144-a947be41b7, 5ghz is still low power and impossible to connect to from my laptop 4 feet away. 2.4ghz still works fine, I'm using it to post this comment.

I did have something odd happen when flashing. The first time I flashed the snapshot from luci, it rebooted to the stock netgear firmware. I then downloaded the openwrt "factory" image and flashed that using the stock gui and it rebooted into the openwrt snapshot. Does openwrt leave the stock firmware intact and just modify the bootloader or something?

5

You may want to refer to the comment of the git commit for answer. RBR40 was added to support since git commit 3121bf4f13 and according to the comments we go to the commit 2cb24b3f3c for the first commit of adding support for Netgear RBx series.

The stock firmware won’t flash to the correct partition by default, so if you reboot it would turn back to the stock firmware.

Consider using the CLI tool nmrpflash — brief help in the comment of git commit — since it would wipe everything on the eMMC and then write image (stock firmware, openwrt, etc.) to router, even the router failed to boot. Otherwise, you will have to first enable telnet and then do some magic with nvram settings uthrough Telnet. Moreover, Netgear remove the checkbox of enabling Telnet which used to be on the /debug.htm in recent versions of RBx stock firmware and automatically disable Telnet after every reboot. And of course, you have to use another CLI tool to enable Telnet manually.

6

I came back to investigate since yesterday and found we may have the same problem as some other users with ath10k (see here Github issue #14541). Though we have the config of 5ghz in the wireless file, but we got the same kernel errors and warnings, kernel tracebacks as they did.

See the line 196-202 of my system log, we got:

Sat Feb  1 05:07:11 2025 kern.info kernel: [   15.638695] ath10k 6.10 driver, optimized for CT firmware, probing pci device: 0x56.
Sat Feb  1 05:07:11 2025 kern.info kernel: [   15.639710] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
Sat Feb  1 05:07:11 2025 kern.info kernel: [   15.646348] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
Sat Feb  1 05:07:11 2025 user.info kernel: [   16.062113] urngd: v1.0.2 started.
Sat Feb  1 05:07:11 2025 kern.err kernel: [   17.101235] ath10k_pci 0000:01:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA9888/hw2.0: -12
Sat Feb  1 05:07:11 2025 kern.err kernel: [   17.101330] ath10k_pci 0000:01:00.0: could not fetch firmware files (-12)
Sat Feb  1 05:07:11 2025 kern.err kernel: [   17.110972] ath10k_pci 0000:01:00.0: could not probe fw (-12)

The kernel tried to load firmware for ath10k but could not find any. So it won’t work correctly at all.

And you can see multiple kernel tracebacks in the log, it complains about unable to configure the device in line 631-655, 716-740, etc. That was when I was applying changes to the 5ghz radio. We might see 5ghz working in LuCI but we are unable to use it at all.

There may be a solution for now, i.e., adding firmware of ath10k manually to the right place. But unfortunately I am not at home for now to test it. Maybe I will have some time in early May. But I do think you can refer to the GitHub issue and see how to fix it. I saw some comments that made 5ghz work after some hacking.

Good luck for you all and hopefully it would be fix in the near future. Reply if you all successfully get the 5ghz work.

7

Testing to fix this problem but ended nowhere.

No luck extracting board bin files from the stock firmware. Maybe because I am using Windows (no dice on Ubuntu, so unlikely it is related to OS). Seems lack of file headers. The BDF file should starts with header like “QCA-ATH10K-BOARD”.

I don’t have a chance, at least for now, to try directly copy BDFs, short for “board data file”, from the router. Maybe someone could try it on other platforms or use tftp/scp to transfer them from one running on stock firmware.

Would someone like to build a firmware with snapshot on 3121bf4f13 to try if 5ghz would work? That seems to be another possible option for now.

8

I tried using the firmware-mod-kit extract-firmware.sh on my Ubuntu 22.04 chromebook to get the BDF. First, python-magic was not in the ubuntu repos, so I grabbed it with pip. But when I went to run extract-firmware, this is what i get:

/usr/bin/ld: /tmp/ccgUhVdz.o: in function `do_chrdev':
/home/ozzie/firmware-mod-kit/src/uncramfs/uncramfs.c:324: undefined reference to `minor'
/usr/bin/ld: /home/ozzie/firmware-mod-kit/src/uncramfs/uncramfs.c:324: undefined reference to `major'
/usr/bin/ld: /tmp/ccgUhVdz.o: in function `do_blkdev':
/home/ozzie/firmware-mod-kit/src/uncramfs/uncramfs.c:364: undefined reference to `minor'
/usr/bin/ld: /home/ozzie/firmware-mod-kit/src/uncramfs/uncramfs.c:364: undefined reference to `major'
collect2: error: ld returned 1 exit status

I also tried upgrading my RBR40 from the snapshot I previously tried to OpenWRT 24.10.1 using the web interface, that failed, so I've now recovered to the stock firmware using tftp. IIRC the stock firmware is based on OpenWRT, and there is a way to get ipkg working on it, I'm just not sure if that would be useful for getting the BDF or any other information. For the moment I'll leave the stock firmware on it.

EDIT: learned how to fix the issues with firmware-mod-tools, working on fixing them in all the files that need fixing.

10

Ok, so after attempting to fix the firmware-mod-tools, getting it to compile, and then fail to extract the firmware, I found this repo: https://github.com/rampageX/firmware-mod-kit which compiles and runs without modification and seems to have actually worked.

I now have the extracted contents of the stock firmware, but nothing in the rootfs named QCA-ATH10K-BOARD. I'm not sure what format the file would be in, running 'strings' on the header.img that was extracted looks interesting, but I'm not sure if it's what we're looking for.

EDIT: /lib/firmware file list: https://pastebin.com/GDvdfe7Y

11

Ok, now I seemed to got somewhere about the BDF files. The header of BDF files QCA-ATH10K-BOARD is added by qca-swiss-army-knife. And looks like we have to create a json file -- board.json to repack the BDF files to the one usable for OpenWRT [1].

And according to a partial boot log of the stock firmware [2], to make the 5GHz WiFi work, the stock firmware loaded the file QCA9888/hw.2/boardData_2_0_QCA9888_5G_Y9690.bin as its BDF file. For the 2.4GHz part, we know that it is working so far through the log so we will choose to ignore it
for now. Maybe more investigations could be made in the future.

So maybe just repack the BDF file and place it somewhere correct [3], and it will work like a charm? But unfortunately, I don't have a RBR40 for a test now, and my mental status don't allowed me to work on more deeply in it nowadays.

More things to do in the near future:

  1. Get a full boot log from the stock firmware (use dmesg > dmesg.log through telnet and tftp to transfer it to local) to investigate what was loaded during the boot of the stock firmware.
  2. Build a working BDF file and give it a try.
  3. See if there is anything changed and if anything not working as expected.
  4. Maybe we will add the BDF data for the IPQ4019 module of RBR40. The 2.4GHz part is working now, but it is likely that IPQ4019 also plays a role in RBR40's radio, and a BDF file is also needed as the LBR20 [4].

Maybe those references mentioned about will help someone of us:

  1. How to create a working BDF file: HowTo create ipq40xx BDF files - For Developers - OpenWrt Forum
  2. Partial boot log of RBR40, BBS is in Chinese but auto translation works well: ath10k驱动的问题 求解惑-OPENWRT专版-恩山无线论坛
  3. Instructions about how to test a custom BDF file without recompiling the whole firmware: openwrt/package/firmware/ipq-wifi/Makefile at main · openwrt/openwrt · GitHub
  4. The commited BDF data of LBR20, also see the commit log for the example json file: firmware_qca-wireless/board-netgear_lbr20.qca4019 at main · openwrt/firmware_qca-wireless · GitHub
12

For anyone who happens to be looking for it, this script works to enable telnet on the latest/last RBR40 firmware.

Should the board file be identical between the RBR40 and RBS40? I have one of each, I'm wondering if I should leave the RBR40 on the stock firmware and try to test with the RBS40.

13

So thanks to the provided references, I got at least the q4019-based 5ghz working. What I did (on Ubuntu):

  • download the rbr40 stock firmware from Netgear (RBR40-V2.7.5.6.zip)
  • extract the .img from the zip archive
  • use binwalk to extract the squash filesystem (binwalk -Me RBR40-V2.7.5.6.img)
  • get the boarddata from /lib/firmware/ipq4019/hw.1; there are A LOT of .bins in there - I semi-randomly chose the ones from within the FCC-ETSI folder (there are actually 4 files, but two are just renamed copies of the other ones (?)).
  • create a json file based on the given references:
[
    {
        "data": "boardData_1_0_IPQ4019_DK04_2G.bin",
        "names": [
"bus=ahb,bmi-chip-id=0,bmi-board-id=20,variant=Netgear-Orbi-Pro-SRK60"
        ]
    },
    {
        "data": "boardData_1_0_IPQ4019_DK04_5G.bin",
        "names": [
"bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=Netgear-Orbi-Pro-SRK60"
        ]
    }
]

Note the variant referring to the SRK60 instead of the rbr40 - it seems the commit which derived rbr40 support from the SRK60 was incomplete / broken in this regard.

  • use Swiss army knife to generate the board-2.bin file (references)
  • using ssh, rename the board-2.bin on the router (in /lib/firmware/ath10k/qca4019/hw.1) to e.g. board-2.bak
  • using SCP, copy the new board-2.bin onto the router (to /lib/firmware/ath10k/qca4019/hw.1)
  • reboot the router
  • enable 5ghz in luci.

With this setup, signal strength is "normal" and hosts can connect as expected. Switching channels and country code also seem to work.

I tried the same also for the other 5ghz (988x-based), but even though the boot log looks ok (it takes the modified board-2.bin), many of the wifi properties in luci are zero and the channel drop-down is missing completely. I have to say I could not investigate further, maybe I just messed something up when generating the files.

I won't have spare time the next days to look into it further but wanted to share anyway - maybe it's helpful for somebody else to go on.

1 Like
14

AFAIK, although BDF file is crucial for radio to work correctly, even default BDF file would at least work. And it would not cause a harm to the hardware itself using a wrong BDF file, except violating regulation requirements and potential performance impacts, which is not that important for experiments in home lab. You can still do tests on RBS40, according to steps provided by @kkugelblitz , just extract files from the RBS40 stock firmware and rewrite a json to create a BDF for current version OpenWRT.

And I don’t think models like RBR50/60 and so on, instead of LBR20, whose BDF was merged to the qca-wireless repository some time ago, would have a correctly working radio. The description of “everything works correctly” cannot be true in fact. It may work, but 100% not correctly.

And please note, RBS40 will not work with a RBR40 with non stock firmware, especially the MESHing and Roaming, Netgear Armor, etc., since Netgear did lot of magic to the original OpenWRT project. Although there is GPL licensed source code available on its website, compiling it on any recent Linux distribution is impossible (the initial release requires Ubuntu10 and the last one requires Ubuntu16 LTS). I will not suggest to compile it on any machine rather than a VM.

There are some open source implementations about Roaming and MESHing (search batman, mesh11sd, DAWN, usteer plus OpenWRT for more information) though, but I never tried any of them, and they seem to be lack-of-maintenance, buggy and unstable.

But I do think by switching it to the open-source OpenWRT is a good idea, because the router itself has plenty of memory (512MB) and storage (4G, though eMMC is not durable as modern flash, but it should be good enough to do its job), and the stock firmware is lacking of many powerful features, including add-ons and much more, which I think it’s a waste of potential performance of these router.