Build for Netgear R7800

You are right.
My bad. Looks like I have forgotten to toggle the .config.init back to -ct after the last mainline ath10k build.
I will compile a new -ct version.

In case you want to avoid hassle in your build environment, just edit .config.init.
If normal "ath10k-ct" case, these line are commented:

## # Mainline ath10k wifi firmware and driver instead of -ct
## CONFIG_PACKAGE_ath10k-firmware-qca9984=y
## # CONFIG_PACKAGE_ath10k-firmware-qca9984-ct is not set
## CONFIG_PACKAGE_kmod-ath10k=y
## # CONFIG_PACKAGE_kmod-ath10k-ct is not set

If you want mainline ath10k, just remove the comment prefix "## " from the lines, so that the defaults -ct gets disabled and mainline gets selected.

# Mainline ath10k wifi firmware and driver instead of -ct
# CONFIG_PACKAGE_ath10k-firmware-qca9984-ct is not set
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
1 Like

Now there are

  • master-r15668-d33cd383ed-20210201 (ath10k-ct)
  • master-r15657-ec0c6c1143-20210131-ath10k ("old" mainline ath10k)

As you are fresh on this process, could you please let me know what did you (exactly) do after steps 1-5 which are handled by the in order to finally end up to a sysupgrade.bin image?

I ran which is located under the hnscripts folder and i got this:

At the moment I am at this stage:

FYI: complete beginner in linux

thanks in advance

Anything "sudo" is pretty wrong in OpenWrt compilation.
All OpenWrt related compilation commands can be run with a normal user account (once after you have installed the prequisities.

After has completed:

  • cd to the new directory.
  • cp .confit.init .config
  • hnscripts/

Pretty much like said in the message 2:

(Do not cd into the hnscripts directory... Looks like you did that.)

1 Like

thanks for clarifying the directory bit. much appreciated.

For me whatever worked, it did with sudo. Probably because I have not installed the prequisities you mentioned. I am not even a regular user of linux hence I do not know this detail.

btw, my compilation just failed (not sure if it relates to the above):

very frustrating - honestly. just a tiny thing to change (to get the std ath10k in the 19.07 firmware) and 6 hours easily lost..

Last two snapshot builds my 5ghz has started selecting channel 157 instead of 161. My configuration files all seem correct specifying to use 161. My country code has access to use that channel.

Anything else I can check for to see why it's doing this.

You did not specify the exact builds...

Two ideas

  • Check if you are using the -ct build or old mainline ath10k build. ( I wrongly named a few mainline builds as normal).
    "opkg list-installed | grep ath10k"
  • channel width. One driver might show start channel, one shows midpoint. Check if there is a display difference between 20/40/80 wide channels

R7800-master-r15618-56c20f0a5a-20210126-1902 and R7800-master-r15668-d33cd383ed-20210201-2350 are the last two snapshot builds that I've noticed this.

Results of opkg list-installed | grep ath10k

ath10k-board-qca9984 - 20201118-3
ath10k-firmware-qca9984-ct - 2020-11-08-1
kmod-ath10k-ct - 5.4.94+2021-01-11-9fe1df7d-1

My wireless settings

config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option channel '161'
option country 'CA'
option legacy_rates '0'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'psk2'
option key 'xxx'
option wps_pushbutton '0'
option ssid 'xxx'

Results of iw reg get

country CA: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)

Results of iw phy phy0 channels for that channel, doesn't say disabled

* 5805 MHz [161]
Maximum TX power: 30.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80

Results of iw dev wlan0 info

Interface wlan0
ifindex 35
wdev 0x4
addr xxxx
ssid xxxx
type AP
wiphy 0
channel 157 (5785 MHz), width: 80 MHz, center1: 5775 MHz
txpower 30.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 3844 0 0 0 0 1073401 3844

You are probably just seeing a different interpretation by different tools (hostapd, iwinfo, iw), as the 80-wide channel is actually "149-164" and 157 is the center.

But in any case, there is nothing special regarding wifi regulations in my build, so your symptom is more generic.

1 Like

@hnyman, aside from the CT driver are there any other changes you're making between the CT and "old" mainline builds?

I've been using the CT builds for a while and whenever I had connection issues I mostly chalked it up to something random and just rebooted the router or moved to the next version of your build. It never occurred to me to try the non-ct "old" build because I figured new was always better, but after seeing the posts below I decided to give it a shot.

At least in my environment I feel like I'm seeing far fewer connection issues with non-CT mainline. This latest time all I did was switch from 20210205 (ath10k-ct) to 20210131-ath10k ("old" mainline ath10k), didn't change any settings, and the connection issues went away. I have around 20-30 connected devices and some devices have 0 connectivity issues on non-CT whereas with CT it seemed like every day or two there was some connection problem.

Is the CT driver that temperamental that it just doesn't work well under some conditions and devices? I had always thought that I was one setting away from getting to a stable environment and was pleasantly surprised that my problems seem to be solved by just moving to non-CT.

Thanks for your work!

No (or actually yes: driver AND WiFi firmware blob)

There are no other differences between them than the WiFi driver and the underlying firmware blob.

It's actually the firmware that is the problem. The CT driver seems OK. You can use the CT build which I think is updated more often and just replace the firmware with non-ct firmware (on the router I replace /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin with firmware-5.bin_10.4-3.10-00047 from here). FWIW, my problems with CT firmware are with 2 MBPs and a Nest E thermostat, they never worked right. Switch to "old" firmware and all problems are gone. You can report issues to the CT repo but so far I haven't gotten any fixes to the problems I reported.


The latest one should be 10.4-

There are several development branches of the mainline firmware blob.
3.10 and 3.9 have independent versioning.

But yeah, 3902 has been updated more recently than the 3.10 branch.

Indeed, any of those will probably work. I've had good success with 3.10 so I'm staying with that one. But try them and see which one works best in your env.

Good to know, thanks!

Thank you both for this, the swap was surprisingly easy **. I'm giving 10.4- a shot with master-r15687-3f4d1dad00-20210205 (ath10k-ct).

My problems were with a couple of Ring cameras. There was one in particular that would occasionally disconnect and a router reboot seemed to be the only way to get it to reconnect without having to setup the camera again. So far no issues after a couple of hours with the updated firmware.

** Full disclosure, I did run into a couple of surprises, both user error. :grinning: No issues in the end and at least I learned something.

Lesson #1 was that when the size of a file doesn't seem to be quite right, it's probably not a good idea to just use it anyway. :thinking: When downloading the bin file either the download got interrupted or I did a right-click Save As and downloaded the HTML page instead of the binary. Oops!

Lesson #2 was me remembering that the buttons on top of the router still work. While using one hand to remove the network cable I had to use to fix my first problem, my other hand was pressing the WiFi button that I forgot existed. Took me a bit to figure out why the WiFi wasn't working all of a sudden. :grin:

@hnyman do you have some devices to test router power consumption?
I would ask you if you can test 2 patch
One that actually enables the use of the regulator
One that should fix the broken mdio driver

Can you help me test this?

Probably not easily.
Sure, I have a multimeter, but I don't think that I have suitable adaptors to connect it between the router and the power supply. That would require some tinkering, I think.

But I am always willing to test patches, in general :wink:

I have a simple device that show the watt usage but i don't know if it's good to measure the router power.

Anyway let me clean some patch and I will post a link. If you want I can also post the dsa patch

Running 10.4- firmware too right now and it seems to work as well as 10.4-3.10-00047 I've been using for a long time. I hope CT builds continue to work with mainline firmware.