Build for Netgear R7800

[hnyman]

@brunoh

Isn't that a non-ct version

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.

EDIT:
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=y
# CONFIG_PACKAGE_ath10k-firmware-qca9984-ct is not set
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set

[hnyman]

Now there are

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

[pstlr78]

@brunoh

Just had my first exeriences with building my own OpenWrt Software and used your scripts. It worked very well. Thank you very much.

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 newBuildroot.sh in order to finally end up to a sysupgrade.bin image?

I ran updateNmake.sh 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

[hnyman]

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.

@pstlr78

hat did you (exactly) do after steps 1-5 which are handled by the newBuildroot.sh

After newBuildroot.sh has completed:

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

Pretty much like said in the message 2:

@hnyman

Steps in the actual firmware build process in /Openwrt/master:

1. Copy .config.init as the new .config to initialize the build profile:
   cp .config.init .config
   ("make defconfig" will expand the recipe to a full .config . You can run that command also manually.)
2. Do the actual make: hnscripts/updateNmake.sh

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

[pstlr78]

thanks for clarifying the directory bit. much appreciated.

@hnyman

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.

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

[rawd]

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.

[hnyman]

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

[rawd]

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

global
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

[hnyman]

@rawd

option htmode 'VHT80'
option channel '161'

@rawd

||* 5805 MHz [161]|

@rawd

channel 157 (5785 MHz), width: 80 MHz, center1: 5775 MHz

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.

https://www.semfionetworks.com/blog/5ghz-regulations-in-canada-2018-update

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

[patrick]

@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!

@wired

So sad. CT firmware never worked well for my clients and .022 is no exception

@krabbs

i have had the latest CT firmware for a month now. most clients run great in 5ghz and 2.4ghz wifi. with two iphones i can reproducibly prove very slow connections (<5Mbit/s) in 2.4ghz. I test with iperf3. Since other apple phones are running fine i always thought it was a problem with these 2 phones. But now I test the "old" mainline ath10k firmware and everything is fine.
(i just tried because wired posted that CT firmware never worked well for his clients, and yes that seems to be true for me as well )

@Iv4nI

I actually switched to your build (from KONG) because of the ath10 non-ct version.
I'm pretty sure my WiFi for iOS devices is wrecked because of the ct driver issues.
Anyway, working great so far. Thanks for all your work!

[hnyman]

@patrick

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

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.

[wired]

@patrick

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.

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.

[castiel652]

The latest one should be 10.4-3.9.0.2-00135.

[hnyman]

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

kvalo/ath10k-firmware

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

[wired]

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.

[patrick]

@hnyman

@patrick

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

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.

Good to know, thanks!

@wired

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

@hnyman

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

Thank you both for this, the swap was surprisingly easy **. I'm giving 10.4-3.9.0.2-00135 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. 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. 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.

[Ansuel]

@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?

[hnyman]

@Ansuel

do you have some devices to test router power consumption?

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.

@Ansuel

I would ask you if you can test 2 patch
One that actually enables the use of the regulator

But I am always willing to test patches, in general

[Ansuel]

@hnyman

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.

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

[wired]

@patrick

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

Running 10.4-3.9.0.2-00135 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.