Netgear R7800 exploration (IPQ8065, QCA9984)

I am running latest LEDE 17.1.3 on my R7800. The 5GHz radio still crashes after running several hours.
I have been watching on this issue for a few months. Things didn't get better.
I am planing to flash back to the OEM firmware instead.

I have been having issues with my 5Ghz network for some time. After a few days (4 or 5) my network was dead. The hotspot was working but none of the devices could connect to it. It only happened to 5 Ghz network. My 2.4 Ghz WiFi is rock solid.

After an hour of research I came across a thread mentioning the fix for it. Apparently you need to include this link in your config. It needs to be placed in config wifi-iface section.
option wpa_group_rekey '0'

After this little change I resolved all of my issues with 5 Ghz network. I don't have a link to the thread explaining what's causing it but I do remember the solution.

Thanks for your information. I'll try it.

I would not do that. It reduces the security.

Not using it causes WiFi not to work.
I won't mind getting rid of this line form my config if this bug gets fixed.

Interesting discussion on the NBG6817 thread by @tolga9009 on how to possibly enable the original wifi LEDs on R7800 and C2600:



https://www.mail-archive.com/ath10k@lists.infradead.org/msg07443.html
https://github.com/billfarrow/pcimem

Looks like the method would require accessing PCI. @nwf has apparently figured out a way to toggle the LEDs by using "pcimem" tool:

Not yet tied to the ath10k driver internals, but sounds at least like step to the right direction.

Hi, I have an issue with 2.4GHz network, I can't get speed higher than 12 Mbit.
Although earlier it was 70 Mbit as I remember.
I tried different channels, widths, reboot router, installed latest f/w r5201 but nothing helps. 5GHz works fine and gives speed 200Mbit.
Any advices please?

Just don't use the master branch.

Interesting enough but after some changes to ath10k I've started experiencing issue with corrupted packets on both bands. Previously only 2.4ghz band was affected in my case...
It seems like volatile byte alignment or smth like this that happens in certain setups. Now I have both bands that generate corrupted tx packets.

@chunkeey fyi just to take into account

I finally got fed up with the wireless situation for the WRT3200ACM and got myself a R7800.

While setting it up I noticed IPv6 stops working on the LAN interface when I change the LAN interface from bridged to not bridged. This was the case with latest LEDE stable and latest master.

As soon as I set the interface to bridged again (with just the LAN interface as part of the bridge, nothing else) IPv6 starts working again for all devices connected to the LAN interface.

While testing IPv6 connectivity from the router to the internet was always working fine, it only stopped working for the clients connected to the LAN interface (they didn't receive public IPv6 addresses anymore and IPv6 traffic did not get routed to the internet).

Running the LAN interface as not bridged worked on the WRT3200ACM without breaking IPv6 (running different master builds for several months).

Did anyone else experience this or is the switch in the R7800 supposed to work this way?

@hnyman can you list me the actual problem of this router?
i read problem on wifi speed bad ethernet switch.... not so powerfull cpu... i mean i tought this was better than the wrt3200acm...

The CPU is significantly more powerful raw performance wise than the Linksys one. This uses a Cortex A15 “like” Qualcomm CPU while the Linksys uses an older Cortex A8 based CPU so performance per MHz is around 35% higher I believe. Wireless performance wise also the R7800 is probably the best one on the market for 5Ghz band, it actually is slightly better than the R9000 even though both of these use the same WiFi chipset.

So ath10 better than mwlwifi of wrt3200?

ath10k has seen better FOSS development efforts from QCA than mwlwifi from Marvell in my opinion. I think the decent amount of results people have been getting with FOSS for the R7800 is a testament to that.

1 Like

I have compiled the qca8k branch successfully but when configure the WAN to PPPOE and it crashs. Is someone managed to get traffic offload working because currently the throughtput substantially affected in heavy task.

blogic's qca8k has a bug that crashes when pppoe is used, he is working on a fix but no ETA. More than that offloading is unstable yet.

@dissent1 @chunkeey @blogic

I noticed that kernel log error messages seem to indicate that R7800 ath10k initialisation is now looking for firmware-6.bin instead of the firmware5.bin.

But ath10k Makefile is still installing firmware-5.bin
https://git.lede-project.org/?p=source.git;a=blob;f=package/firmware/ath10k-firmware/Makefile;hb=HEAD#l311

[   19.211571] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
[   19.211608] ath10k_pci 0000:01:00.0: Falling back to user helper
[   31.985753] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   31.985783] ath10k_pci 0000:01:00.0: Falling back to user helper
[   32.031964] firmware ath10k!QCA9984!hw1.0!firmware-6.bin: firmware_loading_store: map pages failed
[   32.315733] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[   32.315780] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[   32.329100] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.4-00082 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 f301de65
[   34.607539] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:1 crc32 751efba1
[   40.455033] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1

https://github.com/torvalds/linux/commit/aad1fd7f7677d05013b5fe247a5a6e1464c69a0f#diff-53fd3aaa018dbabcdbd37eb543e1abae

TL;DR: The ATH10K_FW_API_MAX was bumped from 5 to 6 because of the (new) QCA6174 hw3.0 firmware. Since all ath10k share the same firmware loading code:

All ath10k will try to load firmware-6.bin (and currently all other than the QCA6174 will fail)... But it shouldn't be that bad.

But yeah, something seems horribly wrong with the QCA9984 in the IPQ806x platform. I mean the IPQ40XX does manage to hit 550MBit/s throughput (See the Romans post on the ML). Not to mention that the QCA9980 and QCA9984 are much better than the QCA4019. After all they support 2x2 160MHz VHT or 4x4 at 80 MHz VHT channels (from what I know) they should be much faster!

1 Like

Actually I'm starting to think that it's kernel related and not the wireless driver is causing this. After some unrelated backports commits I've starting having the issue on both bands
(if you remember I've had it on 2.4 ghz previously).
Apart from that nbg6817 doesn't seem to have the issue while having similar hardware.
My assumption is that smth wrong with the byte alignment or maybe u-boot messes in ram in same addresses as wireless driver?
There's already 2 mibs in the end of ram region that uboot uses (discovered it when was investigating stability issues in the beginning of support by lede). Maybe it also does smth somewhere in the middle?

Update: weird enough but current HEAD seem to crash the device for some ppl in 10 seconds after 1st client attaches over wifi and that happens right after factory reset. With settings saved it doesn't crash but throughput is extremely low accompanied by broken frames (the issue that is being discussed).
@blogic @chunkeey @jcadduono

Well, the IPQ806x isn't alone. The Marvell mamba? have crashes/problems with 4.9 too:

It could that you (and others) are hitting a SoC or CPU errata. You could enable ARM_ERRATA_798181
and ARM_ERRATA_773022 in the kernel and test if it does helps or not, at least it's something easy to test.
But it might also do just be a waste of time.

You could also try 4.14. I know that hauke has been busy with porting the LEDE patches to 4.14
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.14

I too have the RT-AC58U running on 4.14. But I can't realistically port the IPQ806X parts without the hardware.

@blogic what's your comment? Will you look into this issue? Or, could you make the ipq40xx its own target?
Because this way, the ipq806x and ipq40xx can have separate kernels... And a lot of grief because of interest- and potential merge-conflicts could be avoided in the future.