Build for Netgear R7800

Something is off with the 5 GHz radio. When I disabled it, the router crashed and rebooted. If the 5 GHz radio works well for others, perhaps my unit has a hardware issue with the radio. @hnyman: Do you use the 5 GHz radio on yours?

You are not alone here: when I make a couple of changes (power, channel, etc) to a 5GHz AP it stops working completely.
I never really cared to see why; just reboot and then it works again.
Using the latest 17.01 on R7800

I use both 5GHz and 2.4 GHz radios, but usually not really heavily.
But in general, when testing those earlier more heavily (e.g. streaming video via wifi), I have noticed no special problems

Note that the "normal" 17.01 branch uses the older hack for ath10k wifi firmware reading in R7800, while i have backported the firmware reading fixes from master to my own 17.01 build as explained in Netgear R7800 exploration (IPQ8065, QCA9984) - #367 by hnyman

I tried enabling the 5GHz radio again, this time setting it as N only (no AC). I also enabled just one of the two SSIDs I have defined (the other is a guest network). I connected to it from my phone (Galaxy S7), and ran Speedtest on the phone. The funny thing is that I got a download speed of 28 Mbps, while the upload was 233 Mbps (my internet line is 300/300). Repeated the test, pretty much the same result. Then I enabled the second SSID (from within LuCI), and the router crashed. :frowning:

After it had rebooted, I ran the test again (still on the primary ssid), same result again.

The download speed is obviously way too low, but worse is that changing wifi settings randomly crashes the router. I'll leave it on again for now, and see if it crashes even without changing settings. Here's the relevant portion of the boot log (I think):

[   18.283050] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
[   18.283075] Backport generated by backports.git backports-20160324-13-g24da7d3c
[   18.305451] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[   18.305536] ath10k_pci 0000:01:00.0: enabling bus mastering
[   18.305993] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   18.955381] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[   18.955413] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[   18.966663] 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
[   21.254447] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:1 crc32 751efba1
[   27.104379] 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
[   27.191861] ath: EEPROM regdomain: 0x0
[   27.191867] ath: EEPROM indicates default country code should be used
[   27.191872] ath: doing EEPROM country->regdmn map search
[   27.191880] ath: country maps to regdmn code: 0x3a
[   27.191886] ath: Country alpha2 being used: US
[   27.191892] ath: Regpair used: 0x3a
[   27.196140] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[   27.196260] ath10k_pci 0001:01:00.0: enabling bus mastering
[   27.196823] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   27.375357] ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[   27.375413] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[   27.395881] ath10k_pci 0001: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
[   29.662022] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 751efba1
[   35.516932] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
[   35.602490] ath: EEPROM regdomain: 0x0
[   35.602501] ath: EEPROM indicates default country code should be used
[   35.602506] ath: doing EEPROM country->regdmn map search
[   35.602517] ath: country maps to regdmn code: 0x3a
[   35.602527] ath: Country alpha2 being used: US
[   35.602534] ath: Regpair used: 0x3a

And here's my current 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 country 'NO'
        option channel '40'
        option txpower '23'
        option htmode 'HT40'

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'

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
        option channel '4'
        option htmode 'HT40'
        option country 'NO'
        option txpower '20'

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

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

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option ssid 'xxx'
        option encryption 'psk2'
        option key 'xxx'
        option wps_pushbutton '0'
        option network 'guest'

try the wireless speed with lede stable release build:

http://downloads.lede-project.org/releases/17.01.2/targets/ipq806x/generic/lede-17.01.2-ipq806x-R7800-squashfs-sysupgrade.tar

maybe you will be surprised

I guess I could try that, but then I'd lose the built-in packages that I have in my own build (which is otherwise identical to @hnyman's). And doesn't the stable release lack some of the important wifi fixes that allow reading from the factory calibration data?

I've been trying to get baby jumbo frames to work mtu 1508, when I putty in and ip link list, everything shows as mtu 1500, with the exception of pppoe-wan which shows as 1492, I've tried to change it in ssh, with ifconfig pppoe-wan mtu 1500 but then the internet is very slow, my modem mtu is 1520, anyone have any ideas? I cannot see on interface where I can alter pppoe mtu, without putty, please help!

I tried setting the 5 GHz radio back to AC mode, and download speed was a even slower (less than 20 Mbps), and when Speedtest tried to start upload, the driver got an issue:

Wed Aug 2 21:42:16 2017 kern.warn kernel: [ 1333.739946] ath10k_pci 0000:01:00.0: rx ring became corrupted: -5

@hnyman Is there any point in trying to build from your stable release instead? You apply patches to wifi there too, so perhaps there's no reason to expect different results?

[quote="mroek, post:332, topic:316"]
Is there any point in trying to build from your stable release instead? You apply patches to wifi there too, so perhaps there's no reason to expect different results?
[/quote]The ath10k wifi driver itself is different in 17.01, so the result may be different.

Somewhat similar was seen in May by one user: Build for Netgear R7800

It is possible that ath10k changes done to master in March (smaller buffers) may cause performance degradation, but there has not been really serious discussion about that. dissent1 made a patch to revert those buffer changes, so you might also test that: Build for Netgear R7800

Ok, thanks. I'll just have to read up on applying the patch, I'll admit to being a newbie there. And also, if the wifi driver in 17.01 is different, then it could be interesting to try a 17.01 build too.

I didn't try the patch (at least not yet), instead I built a new firmware based on 17.01 (again using your build environment and patches, just adding and removing some packages for my needs).

The good news is that the 5GHz radio works almost infinitely better. I've set it back to AC mode, and with Speedtest on my phone, I can fully saturate my connection, getting around 300 Mbps both up and down on wireless.

As I told you ... with the 17.01 you will be surprised!

@steom
some ideas for you, if you are still trying to use the master... I guess that you are reaching the performance limit somehow. Might be due to driver interrupt activity choking the CPU. (And the reason may well be wifi performance limitations made to master in March, but which limits are not in 17.01.) You might monitor CPU load with "top" while you have video problems. Likely SIRQ load is at 100%.

Some ideas that might mitigate the problem:

Great firmware, I still love using it.

Can someone tell me if MU-MIMO is supported?

Don't think MU-MIMO is supported, as it's not finished in the mainline linux wifi stack AFAIK.

You're not really losing anything though, unless you have 2 or more MU-MIMO capable devices connecting to your router.

Hnyman, I've tried latest stable firmware, and mtu jumbo frames works fine, by changing mtu on eth0 to 1508, but on your build ( I prefer your build) it still won't work
shows mtu as 1492 when tested. Also I've been getting latency spikes on PS4 with bf1, have it wired into router, using cake qos, any ideas? Router is not under load when ping spikes.

[quote="choppyc, post:340, topic:316"]
I've tried latest stable firmware, and mtu jumbo frames works fine, by changing mtu on eth0 to 1508, but on your build ( I prefer your build) it still won't work shows mtu as 1492 when tested.
[/quote]You mean that it works with release 17.01.2 but not with my master build, right?
17.01 branch is too far away to compare easily. There have been lots of changes since then. (Or did you mean my 17.01 build?)

My build has no build-specific items for switch driver code or config. So, I suspect that it is something more generic. You should check if the buildbot snapshot works for you with the same config (if you are talking about master).

But, I tried setting MTU to >1500 myself in master, and did not succeed. So, I guess that the symptom is real. (I have normally 1500 as the MTU, set automatically)

@hnyman: I'm pretty sure this has nothing to do with your build environment, but did you see my thread on IGMP snooping on this router? The switch seems to be dropping IGMP queries, but not other IGMP (or multicast) packets whenever IGMP snooping is enabled in the switch itself. Do you have any ideas on that one? Can you reproduce it on your router?

You may want to try this driver and check how igmp snooping works https://github.com/dissent1/r7800/commit/fd065e652c2d49db3fab42f800ff9002ce4993fa

You will have to unbridge eth0 and eth1 after this. You'll have lan1-4 and wan interfaces that correspond to relative physical port.

[quote="mroek, post:342, topic:316"]
did you see my thread on IGMP snooping on this router? The switch seems to be dropping IGMP queries, but not other IGMP (or multicast) packets whenever IGMP snooping is enabled in the switch itself. Do you have any ideas on that one?
[/quote]I saw that but did not comment, because I have nothing to say that would contribute. Not my specialty. You should get @blogic @dissent1 @mkresin (or somebody else who is really looking deeper into ipq806x) interested in the issue.