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.
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.
@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...
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.
@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)
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.
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
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.
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.
what happened to this? just abandoned?
do I need to flash via tftp to get the ramdisk feature?