Netgear R7800 exploration (IPQ8065, QCA9984)

Wait, usb-modems? These usually are connected through some variant of usb-serial .

But USB_GADGET is something completely different, you don't need it.

@hnyman when kernel 4.19?

@chunkeey im' using usb net, but it's same, not connected ,

[   13.949491] usbcore: registered new interface driver cdc_wdm
[   14.505528] cdc_ether 3-1:1.0 eth2: register 'cdc_ether' at usb-xhci-hcd.1.auto-1, CDC Ethernet Device, 0c:5b:8f:27:9a:64
[   14.505686] usbcore: registered new interface driver cdc_ether
[   14.526507] usbcore: registered new interface driver cdc_ncm
[   14.574813] usbcore: registered new interface driver huawei_cdc_ncm
[   14.582978] cdc_ether 3-1:1.0 eth2: unregister 'cdc_ether' usb-xhci-hcd.1.auto-1, CDC Ethernet Device

always unregister...

I'm using Huawei E3372,

Before, When I using TP-Link Archer C7v5 it's successfull with rndis mode with usb gadget module,

[SOLVED]
Thanks every one

Why is master always behind on the official firmware updates from Kalle?

Have you looked at the source code for explanations...

https://github.com/openwrt/openwrt/commit/9860cdda76797b0d9dc24795c39b307589589f4c#diff-83f97eaa41a9f91a20b3483ef4fa1545

And linux-firmware gets updated infrequently:
https://github.com/openwrt/openwrt/commits/master/package/firmware/linux-firmware

And of course, the default for R7800 is now "-ct" so the explanation above is only meaningful if you try to use the normal old ath10k (like I do).

FYI:

Yesterday the netdev LED code got changed by

This commit apparently effectively removed the WAN LED functionality from some devices. At least from those ipq806x devices that specifically define WAN LED separately in the board identification.

My R7800 lost its WAN LED as the "mode" option can not be set:

Sun Dec 16 12:15:29 2018 daemon.notice procd: /etc/rc.d/S96led: setting up led WAN
Sun Dec 16 12:15:29 2018 daemon.notice procd: /etc/rc.d/S96led: /etc/rc.common: eval: line 74: can't create /sys/class/leds/r7800:white:wan/mode: Permission denied

The default config is generated from:

with the function in

I tried to remove the mode option from the uci config, but that does not help.

After looking at the new backported code, I noticed that manually echoing new value into sys/class/leds internals seems to help:

root@router1:~# echo 1 > /sys/class/leds/r7800\:white\:wan/rx
root@router1:~# echo 1 > /sys/class/leds/r7800\:white\:wan/tx
root@router1:~# echo 1 > /sys/class/leds/r7800\:white\:wan/link

But I haven't yet figured out what would be correct place to get that implemented in uci config & OpenWrt led init scripts.

Yes I know, I always edit that makefile and do some manual coping etc to get the latest non-ct firmware.
I made a patch file but since it's a makefile it changes quite often so using the patch file rarely helps much.

Fixed with
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=201058b35ce42086b83f7eabb6304cac00c4c585;hp=3262fce1cd12cd9dbd3b3e50d034233b2b884101

@hnyman
Hi, I am using your build for R7800, and try to enable ht160, only the build [OpenWrt SNAPSHOT r8466-251c350727 / LuCI Master (git-18.320.61035-ee6e072)] working great with [channel 36 & country AU], is that info help to fix problem with ht160?

Can anyone please provide the output of iw phyX info on one of these routers please? Where phyX is the phy number of the 5ghz radio.
I’m looking whether the device supports (and advertises) VHT80P80

ZyXEL NBG6817 (IPQ8065, QCA9984)

  • current master
  • ath10k
    • firmware ver 10.4-3.6.0.1-00004 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 05feb8e2:
Wiphy phy0
        max # scan SSIDs: 16
        max scan IEs length: 199 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports AP-side u-APSD.
        Available Antennas: TX 0xf RX 0xf
        Configured Antennas: TX 0xf RX 0xf
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x19ef
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 7935 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 8 usec (0x06)
                HT TX/RX MCS rate indexes supported: 0-31
                VHT Capabilities (0x339b79fa):
                        Max MPDU length: 11454
                        Supported Channel Width: 160 MHz, 80+80 MHz
                        RX LDPC
                        short GI (80 MHz)
                        short GI (160/80+80 MHz)
                        TX STBC
                        SU Beamformer
                        SU Beamformee
                        MU Beamformer
                        MU Beamformee
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: MCS 0-9
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 1560 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: MCS 0-9
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 1560 Mbps
                Frequencies:
                        * 5180 MHz [36] (23.0 dBm)
                        * 5200 MHz [40] (23.0 dBm)
                        * 5220 MHz [44] (23.0 dBm)
                        * 5240 MHz [48] (23.0 dBm)
                        * 5260 MHz [52] (23.0 dBm) (radar detection)
                        * 5280 MHz [56] (23.0 dBm) (radar detection)
                        * 5300 MHz [60] (23.0 dBm) (radar detection)
                        * 5320 MHz [64] (23.0 dBm) (radar detection)
                        * 5500 MHz [100] (23.0 dBm) (radar detection)
                        * 5520 MHz [104] (23.0 dBm) (radar detection)
                        * 5540 MHz [108] (23.0 dBm) (radar detection)
                        * 5560 MHz [112] (23.0 dBm) (radar detection)
                        * 5580 MHz [116] (23.0 dBm) (radar detection)
                        * 5600 MHz [120] (23.0 dBm) (radar detection)
                        * 5620 MHz [124] (23.0 dBm) (radar detection)
                        * 5640 MHz [128] (23.0 dBm) (radar detection)
                        * 5660 MHz [132] (23.0 dBm) (radar detection)
                        * 5680 MHz [136] (23.0 dBm) (radar detection)
                        * 5700 MHz [140] (23.0 dBm) (radar detection)
                        * 5720 MHz [144] (23.0 dBm) (radar detection)
                        * 5745 MHz [149] (30.0 dBm)
                        * 5765 MHz [153] (30.0 dBm)
                        * 5785 MHz [157] (30.0 dBm)
                        * 5805 MHz [161] (30.0 dBm)
                        * 5825 MHz [165] (30.0 dBm)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)
        valid interface combinations:
                 * #{ managed } <= 1, #{ AP, mesh point } <= 16,
                   total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Device supports VHT-IBSS.
1 Like

Fantastic, thanks!
Very jealous. I thought the WRT3200ACM/WRT32X could do 80+80 but they don’t. I wrote a patch to allow setting it and then it failed at the driver level :frowning:

I have been exploring R7800 with @hnyman's community build OpenWrt 18.06-SNAPSHOT r7409-d5afaa4114 for last few days. [edit: Note: This has nothing to do with this particular build, but 18.06-branch and most likely also newer ones. I just used this build as base for test.]

If you want lower ping & faster performance:

install ethtool package.

add to rc.local

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor

echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
sleep 1
echo 1750000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1750000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq

ethtool -C eth0 tx-usecs 0
ethtool -C eth1 tx-usecs 0
ethtool -C eth0 rx-usecs 31
ethtool -C eth1 rx-usecs 31

Remove / disable script (I inserted exit to 2nd line of file)
/etc/hotplug.d/net/20-smp-tune

There is some frequency setting bug in ipq8065's drivers. If you change frequency from 1GHz-1.4GHz to max, you get a lot worse latency than when changing from 600-800MHz. I suspect L2 is not done right? I haven't investigated sources (yet). Also ethernet driver has bug that you can't change tx-usecs after you have changes rx-usecs and default rx-usecs is really high. Normal would be about 3us, not 264us. 30us is minimum it allows to set (with parameter 31 - another bug that result is one lower than requested?).

eth0/1 coalesce settings will get reset when connection status changes or you apply/commit new settings, so be aware. I have not yet looked where to add lines so those would be applied when necessary. (Most likely somewhere in hotplug.d/ )

Pings get noticeably lower. I have not tested effect to bandwith (yet) as 10/10M is limiting in my current net topology.

If you want even faster latency / performance, iptables rules made by fw3 seem slow. But I haven't looked better performing ones yet.

If someone could figure how to get ethernet driver's rx-usecs to more standard 3us value, router's latency could be on same level as ar71xx with openwrt 12.09.

CPU governor changed to performance did not change router's idle power consumption measurable with 0.1W resolution RMS powermeter.

Is there some way to disable some of sleep/C-states of cpu/soc? it would improve things more.

VLAN-setting or switch0 settings didn't seem to make any effect to latency.

Best I could get was min 0.050ms / avg 0.126ms ping to router. Above "settings" should give avg about 0.140ms (or was it 0.150ms). Default state was 1ms level. Yes, it is pinging router, but same affects twice natted intenet traffic when not using hw (or sw?) acceleration.

ps. Messy post, I didn't refactor this, but just wrote what I remembered now after few hours sleep.

8 Likes

About R7800 and frequency stuff, there is a pull request by dissent1 that was never accepted, I think: https://github.com/openwrt/openwrt/pull/632
If you are into experimenting...

We get very 30 minutes the same error on eth0:

kern.err kernel: [ 584.144343] ipq806x-gmac-dwmac 37200000.ethernet eth0: len 1994 larger than size

After about ten or so of these messages the router crashes and sometimes it does becomes totally unresponsive.
Now a crontab runs every 10 minutes and when it greps the nefarious message, it reboots the router thereby assuring access stays possible.

Using this lowered ping about 0.200ms.
So pinging the router from a linux server gives me between 0.198ms-0.351ms.in ping. It was 0.350-0.600ms before.

Hi,
sorry if the question has already been asked, Is there an RTC chip on this router ? any kernel module to be used ?
Thanks

No, there is not.

1 Like

what happened to this? just abandoned?

do I need to flash via tftp to get the ramdisk feature?