added linux kernel 6.6 support.
for now as testing kernel.
works okay so far.
after some testing will set it as the default one.
4 Likes
fyi.
dropped linux kernel 6.1 on branch netgear-r9000.
but it can still be found on branch netgear-r9000-linux-6.1.
linux kernel 6.1 will no longer be maintained.
linux kernel 6.6 is the default now.
5 Likes
Hi all!
I haven't been in the forum for a while - sorry, was busy with other projects.
Can someone quickly summarize the current status of OpenWRT on the R9000 - what works, what doesn't (hardware-wise). I'm considering converting my unit to OpenWRT again (but don't have the time to go through all the posts in the last 2 years that I missed).
In case all that summary info is already available someplace - just point me there.
Thanks!
Hmmmm... It's suspiciously quiet here. Why?
Did every R9000 owner switch to DD-WRT by now?
(I don't want to sound critical or anything, just trying to establish if OpenWRT is still a viable option for my favourite Netgear router. I trully appreciate the effort that was invested developing this branch)
I'm still using @egorenar build on my R9000. No issues and he keeps the repo synced with the main openwrt repo frequently. I update every week or so.
2 Likes
using @egorenar builds, update every 2 month or when i remember, tbh i dont know why this isnt yet official. i really like the device with openwrt, i would like it even more if i can use opkg to install or uninstall packages.
2 Likes
R9000 does reach 10G bps speed.
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-100.00 sec 109 GBytes 9.34 Gbits/sec 7747 sender
[ 5] 0.00-100.00 sec 109 GBytes 9.34 Gbits/sec receiver
backwards:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-100.00 sec 82.5 GBytes 7.09 Gbits/sec 28880 sender
[ 5] 0.00-100.00 sec 82.5 GBytes 7.09 Gbits/sec receiver
runing iperf3 server on openwrt x86.
edit: test on netgear-r9000-linux-6.1
1 Like
Im using your build, from the download, and I have no usefull wifi devices. All I have is this:
Am I missing something?
what does dmesg say ? wlan devices are pci devices and there should be pci messages in dmesg.
Hey egorenar... I have anizee's device at my place.
The dmsg log info for the wil6210 device shows the following. If you need to see more of the dmesg log, I posted it here: https://gist.github.com/pjobson/3830244cfeba927f1affb74fd3795f2e
This was after I did a firstboot -y in case he changed anything I didn't know about.
[13.547680] wil6210 0003:01:00.0: wil6210 device found [1ae9:0310] (rev 2) bar size 0x200000
[13.548065] wil6210 0003:01:00.0: enabling device (0140 -> 0142)
[13.565521] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_pcie_probe: CSR at [mem 0xf0200000-0xf03fffff 64bit] -> 0x0c283170
[13.578213] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_capabilities: Board hardware is Sparrow B0, flash exist
[13.590278] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_capabilities: platform_capa 0x0
[13.661801] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_refresh_fw_capabilities: keep_radio_on_during_sleep (0)
[13.673530] wil6210 0003:01:00.0: using dma mask 48
[13.678442] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_if_pcie_enable: 3 MSI mode failed, try 1 MSI
[13.735685] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_get_bl_info: Boot Loader struct v2: MAC = 04:ce:14:07:fe:c0 RF = 0x0000 (status 0x0000) bband = 0x00000000
[13.751831] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_get_bl_info: Boot Loader build 255.255.0.6836
[13.762684] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_oob_mode: oob_mode to 0
wireless config shows:
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/fd840000.pcie-external2/pci0003:00/0003:00:00.0/0003:01:00.0'
option channel '1'
option band '60g'
option htmode 'HT20'
option disabled '1'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'
option ifname '60GHz-radio0'
We appreciate your input, thanks!
hmm, i don’t see ath10k driver being probed.
just to make sure, the driver is enabled ?
lsmod shall display it.
The DDWRT forum has a couple of threads about burnt-out radios.
Rumour has it because of bad thermal design of the active antennas
1 Like
I re-flashed as I didn't know what state the unit was left in.
dmesg |grep wil
[ 13.369662] wil6210 0003:01:00.0: wil6210 device found [1ae9:0310] (rev 2) bar size 0x200000
[ 13.378327] wil6210 0003:01:00.0: enabling device (0140 -> 0142)
[ 13.384347] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_pcie_probe: CSR at [mem 0xf0200000-0xf03fffff 64bit] -> 0x78180b26
[ 13.397034] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_capabilities: Board hardware is Sparrow B0, flash exist
[ 13.412492] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_capabilities: platform_capa 0x0
[ 13.480454] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_refresh_fw_capabilities: keep_radio_on_during_sleep (0)
[ 13.492180] wil6210 0003:01:00.0: using dma mask 48
[ 13.497087] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_if_pcie_enable: 3 MSI mode failed, try 1 MSI
[ 13.585665] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_get_bl_info: Boot Loader struct v2: MAC = 04:ce:14:07:fe:c0 RF = 0x0000 (status 0x0000) bband = 0x00000000
[ 13.601811] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_get_bl_info: Boot Loader build 255.255.0.6836
[ 13.612666] wil6210 0003:01:00.0 (unnamed net_device) (uninitialized): wil_set_oob_mode: oob_mode to 0
[ 19.082532] wil6210 0003:01:00.0 wlan0: wil_cfg80211_del_iface: cannot remove the main interface
[ 19.159781] wil6210 0003:01:00.0 wlan0: wil_cfg80211_del_iface: cannot remove the main interface
lsmod |grep ath
ath 24576 1 ath10k_core
ath10k_core 450560 1 ath10k_pci
ath10k_pci 49152 0
cfg80211 319488 4 ath10k_core,ath,wil6210,mac80211
mac80211 602112 1 ath10k_core
iw phy
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 1
max scan IEs length: 1024 bytes
max # sched scan SSIDs: 16
max # match sets: 16
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Available Antennas: TX 0 RX 0
Supported interface modes:
* managed
* AP
* monitor
* P2P-client
* P2P-GO
* P2P-device
Band 3:
Capabilities: 0x00
HT20
Static SM Power Save
No RX STBC
Max AMSDU length: 3839 bytes
No 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: 1-12
Frequencies:
* 58320 MHz [1] (0.0 dBm)
* 60480 MHz [2] (0.0 dBm)
* 62640 MHz [3] (0.0 dBm)
interface combinations are not supported
max # scan plans: 2
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
opkg list-installed |grep ath
ath10k-board-qca9984 - 20240220-1
ath10k-firmware-qca9984-ct - 2020-11-08-1
kmod-ath - 6.1.80+6.6.15-1
kmod-ath10k-ct - 6.1.80+2023-06-05-fadd0768-1
ucode-mod-math - 2024-02-21-ba3855ae-1
i would make sure you have alpine-fan-control installed. The R9000 definitely has heat issues. I have mine set so the fan is always running at the max 4000rpms. CPU sits around 40-45c depending on load and the wifi chips run aroud 50-54C this way. My brothers R9000 has dead wifi chips now because he had fan control installed and thought the default fan curve would suffice. It does not. Could be the issue with your wifi, unfortunately. Maybe not, but keep it in mind if you cant get it working. If it was bought used, it certainly could be the problem.
1 Like
And another rumour has it that Netgear did accidentally kill the radios in many of those units with a buggy firmware update, which was quickly retracted, but not fast enough to prevent some units who had auto-updating enabled to have time to reboot and activate the unfortunate changes. Corrupt NVRAM is what we heard.
A lot of those on second-hand market are damaged in that way. Unfortunately noone discovered a way to recover the NVRAM (if that's the real culprit, of course)
I have 4 of those - 2 with good radios and 2 with dead. I've never seen the fans in these to turn on under normal load (routing and providing WiFi, not serving media file and transcoding under PLEX) when using the stock Netgear firmware. How come it becomes imperative to run the fan at full speed with OpenWRT?
What is the evidence of the WiFi chips being really damaged by overheating? After all these are modern chips of high sophistication. I cannot imagine Qualcomm not integrating basic thermal protection - something that's available even in simple analog ICs.
1 Like
my fan config:
echo 2000 > /sys/bus/i2c/devices/0-003e/hwmon/hwmon0/fan1_target
i never have had problems with overheating with my xr700 running all day.
1 Like
Thanks all. I'm leaning toward this being a damaged unit. It was used before I got it from my buddy who was posting about it above. Just for funsies I attempted to flash it to DDWRT, it would never even assign a DHCP address, much less load their web interface. I also flashed the stock firmware, but it was so convoluted that I didn't bother messing with it.
Any luck getting a 6.6 kernel to build?
where can I download this build?