OpenWrt Forum Archive

Topic: Netgear R8000 support?

The content of this topic has been archived between 23 Mar 2018 and 5 May 2018. Unfortunately there are posts – most likely complete pages – missing.

DrPizza wrote:

Config:

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path '18000000.axi/bcma0:7/pci0000:00/0000:00:00.0/0000:01:00.0'
        option txpower '20'
        option channel '132'
        option country '00'
        option htmode 'VHT80'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2'
        option key 'password'
        option ssid 'grackle-nest-backhaul'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path '18000000.axi/bcma0:8/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:01.0/0001:03:00.0'
        option htmode 'HT20'
        option txpower '20'
        option country '00'

config wifi-iface
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'grackle-nest'
        option encryption 'psk2'
        option key 'password'

config wifi-device 'radio2'
        option type 'mac80211'
        option hwmode '11a'
        option path '18000000.axi/bcma0:8/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:02.0/0001:04:00.0'
        option txpower '20'
        option channel '44'
        option country '00'
        option htmode 'VHT80'

config wifi-iface
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'grackle-nest-5g'
        option encryption 'psk2'
        option key 'password'

System log:

Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio1 (1208): wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio1 (1208): wlan1: Could not connect to kernel driver
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio1 (1208): Using interface wlan1 with hwaddr e8:fc:af:fb:f7:0c and ssid "grackle-nest"
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): Failed to create interface mon.wlan0: -95 (Operation not supported)
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): wlan2: interface state UNINITIALIZED->COUNTRY_UPDATE
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): wlan2: interface state COUNTRY_UPDATE->HT_SCAN
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio1 (1208): wlan1: interface state COUNTRY_UPDATE->ENABLED
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio1 (1208): wlan1: AP-ENABLED 
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: interface state COUNTRY_UPDATE->HT_SCAN
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): wlan2: Could not connect to kernel driver
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): Using interface wlan2 with hwaddr e8:fc:af:fb:f7:0d and ssid "grackle-nest-5g"
Fri Apr 15 01:23:20 2016 daemon.notice netifd: Network device 'wlan1' link is up
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): wlan2: interface state HT_SCAN->ENABLED
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio2 (1209): wlan2: AP-ENABLED 
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: interface state HT_SCAN->DFS
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: DFS-CAC-START freq=5660 chan=132 sec_chan=1, width=1, seg0=138, seg1=0, cac_time=60s
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): DFS start_dfs_cac() failed, -1
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): Interface initialization failed
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: interface state DFS->DISABLED
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: AP-DISABLED 
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: interface state DISABLED->DISABLED
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): wlan0: AP-DISABLED 
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): hostapd_free_hapd_data: Interface wlan0 wasn't started
Fri Apr 15 01:23:20 2016 daemon.notice netifd: radio0 (1207): nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Fri Apr 15 01:23:21 2016 daemon.notice netifd: radio0 (1207): ELOOP: remaining socket: sock=16 eloop_data=0x1158240 user_data=(nil) handler=0x2fb68
Fri Apr 15 01:23:21 2016 daemon.notice netifd: radio0 (1207): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Fri Apr 15 01:23:21 2016 daemon.notice netifd: radio0 (1207): Command failed: Invalid argument

Try changing the channel to 149 and try again.

adityaxavier wrote:

Try changing the channel to 149 and try again.

That works, thank you!

Why 149?

DrPizza wrote:
adityaxavier wrote:

Try changing the channel to 149 and try again.

That works, thank you!

Why 149?

Actually if you check the UI ( Luci ) to set the Channel you would see that 132 is not supported. Because of the previous mistakes in the configuration Luci was displaying all the Channel options, even those which are not supported. At least thats what i believe the problem to be. smile

adityaxavier wrote:
DrPizza wrote:
adityaxavier wrote:

Try changing the channel to 149 and try again.

That works, thank you!

Why 149?

Actually if you check the UI ( Luci ) to set the Channel you would see that 132 is not supported. Because of the previous mistakes in the configuration Luci was displaying all the Channel options, even those which are not supported. At least thats what i believe the problem to be. smile

idk, I configured everything through luci so I'm not really sure why it's showing so many channels. The reason I set it to US was that I thought it'd only show the "right" ones (since it's a US device, after all) but it didn't seem to make a difference.

adityaxavier wrote:
config interface 'wan'
    option ifname 'eth0.2'
    option proto 'pppoe'
    option username    'xxxxx'
    option password    'xxxxx'
    option service    'xxxxxx' #Optional

Cause i don't have the bridge and orig_ifname options.. And PPPOE has always been working for me.. even in the latest Nightly. And this is what i have been using..

I fix the problem by add a line in in wan section.  where mac address can get from the package box.

        option macaddr 'xx:xx:xx:xx:xx:xx' 

R8000 can't get a valid mac address under CC 15.05.1
Can you confirm this bug fixed in current trunk release?

(Last edited by aru on 16 Apr 2016, 11:45)

The problem is caused by specific Ethernet interfaces in R8000.
eth0: doesn't have MAC, should be used as fwd0, should be used for forwarding packets to radio
eth1: doesn't have MAC, should be used as fwd1, should be used for forwarding packets to radio
eth2: does have MAC, should be used as eth0, should be used as main switch interface

We should use eth2 but this requires setting FA (flow accelerator) which is not supported. So our only option was to use eth0 or eth1 as workaround. This works (it's possible to use network) but none of them has MAC assigned, so Linux gets a random one for them.

Zajec wrote:

We should use eth2 but this requires setting FA (flow accelerator) which is not supported. So our only option was to use eth0 or eth1 as workaround. This works (it's possible to use network) but none of them has MAC assigned, so Linux gets a random one for them.

Can we do a hack to force eth0 use eth2 mac?
random mac may cause weird problem in some network environment, At least  two cases in this thread.

Zajec wrote:

The problem is caused by specific Ethernet interfaces in R8000.
eth0: doesn't have MAC, should be used as fwd0, should be used for forwarding packets to radio
eth1: doesn't have MAC, should be used as fwd1, should be used for forwarding packets to radio
eth2: does have MAC, should be used as eth0, should be used as main switch interface

We should use eth2 but this requires setting FA (flow accelerator) which is not supported. So our only option was to use eth0 or eth1 as workaround. This works (it's possible to use network) but none of them has MAC assigned, so Linux gets a random one for them.

FWIW, the MACs I set are sequential, because that's what was showing under other firmware. radio0/radio1/radio2 have MACs ending :0b, :0c, :0d, WAN is :0a, and the bridge is :09.

I feel OpenWrt should probably try to replicate this setup, as having them random each boot seems to cause a range of problems.

I am using the 15.05.1 version, all of the features are working very well. But when the wireless network is used to download and more than 3000 connections with a half hours or later, speed in about 110Mbps, the wireless network that is used will collapse and can not be restarted.
The kernel error are follows:
Brcmfmac: brcmf_msgbuf_query_dcmd: Timeout on [34378.555713] response for query command
Brcmfmac: brcmf_cfg80211_get_tx_power: error [34378.563581] (-5)

I analyzed this problem should not case of large data stream, because I use a copy to LAN computer speeds in excess of 600Mbps continued for half an hour is not a problem.

(Last edited by crwnet on 26 Apr 2016, 18:48)

Anyone able to compile toolchain from trunk for R8000? On the same box, I'm able to compile for WRT1900AC but same box failed to compile for R8000. Here is the error while compiling GCC.

build/genautomata /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/common.md /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/config/arm/arm.md \
      insn-conditions.md > tmp-automata.c
/bin/bash: line 1: 15849 Killed                  build/genautomata /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/common.md /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/config/arm/arm.md insn-conditions.md > tmp-automata.c
make[5]: *** [s-automata] Error 137
make[5]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal/gcc'
make[4]: *** [all-gcc] Error 2
make[4]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal'
make[3]: *** [/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal/.built] Error 2
make[3]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/toolchain/gcc/minimal'
make[2]: *** [toolchain/gcc/minimal/compile] Error 2
make[2]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt'
LogicoZone wrote:

Anyone able to compile toolchain from trunk for R8000? On the same box, I'm able to compile for WRT1900AC but same box failed to compile for R8000. Here is the error while compiling GCC.

build/genautomata /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/common.md /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/config/arm/arm.md \
      insn-conditions.md > tmp-automata.c
/bin/bash: line 1: 15849 Killed                  build/genautomata /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/common.md /home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0/gcc/config/arm/arm.md insn-conditions.md > tmp-automata.c
make[5]: *** [s-automata] Error 137
make[5]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal/gcc'
make[4]: *** [all-gcc] Error 2
make[4]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal'
make[3]: *** [/home/parallels/openwrt/r8000-trunk/openwrt/build_dir/toolchain-arm_cortex-a9_gcc-5.3.0_musl-1.1.14_eabi/gcc-5.3.0-minimal/.built] Error 2
make[3]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt/toolchain/gcc/minimal'
make[2]: *** [toolchain/gcc/minimal/compile] Error 2
make[2]: Leaving directory `/home/parallels/openwrt/r8000-trunk/openwrt'

It's OK to compile latest trunk. Maybe you don't have sufficient memory? Make sure you have large than 3GB ram.

wget / curl failed in latest trunk
I compile latest trunk and find wget/curl within router will failed.
wget http://www.google.com will return error: Failed to allocate uclient context.
I download latest trunk build from downloads.openwrt.org and do a fresh upgrade, same thing happen.
Can someone confirm this bug?

Hi, thanks for all the hard work that went into getting this release working. Just making a note here about getting USB working on r8000 device which has 1xUSB2.0  and 1xUSB3.0 ports.

Looks like USB3 is not supported on this router. I installed the USB3 driver but got a error messing in kernel log "no usb3 ports found"

I then installed kmod-usb2:

[  659.710750] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[  659.721503] ehci-platform: EHCI generic platform driver
[  659.726928] ehci-platform ehci-platform.0: EHCI Host Controller
[  659.732959] ehci-platform ehci-platform.0: new USB bus registered, assigned bus number 1
[  659.741339] ehci-platform ehci-platform.0: irq 111, io mem 0x18021000
[  659.758343] ehci-platform ehci-platform.0: USB 2.0 started, EHCI 1.00
[  659.765376] hub 1-0:1.0: USB hub found
[  659.769444] hub 1-0:1.0: 2 ports detected

I was also wondering what ETH1 and ETH2 ports are used for? Could the WAN port be setup on one those instead of sharing ETH0 with the embedded switch?

r8000_user wrote:

Looks like USB3 is not supported on this router. I installed the USB3 driver but got a error messing in kernel log "no usb3 ports found"

I think this message appears for one hub only. Provide a full log.

r8000_user wrote:

I was also wondering what ETH1 and ETH2 ports are used for? Could the WAN port be setup on one those instead of sharing ETH0 with the embedded switch?

Really, it was explained in my last post here.

Please, can you tell me the best practice between these 2:
- use the same SSID/WPA key for the two 5GHz radios
- use different SSIDs ?

Both work, both have different tradeoffs.
- By using the same SSID, roaming works smoother, but both SSIDs are considered equal (the stronger signal usually wins) - which means you can't prefer the faster 5 GHz band if you're in range of both (some commercial wireless setups work hard on accomplishing this through evil tricks)
- By using different SSIDs, you can prefer one band over the other (by giving the 5 GHz SSID a higher priority), but they're no longer considered to be the same network (which means the handoff doesn't work that smoothly, although it still works)

In the commercial arena there are several approaches (quite ugly hacks) to mitigate this to some extent, but those have their own problems and exploit specific (undefined or non-standard) behaviour of the connecting clients.

(Last edited by slh on 21 May 2016, 20:35)

My question was on the two 5Ghz radios of the R8000. They supposely have the same speed right ?

Right, so to summarize for those who are late to this thread like I was an hour ago:
1) 5GHz radios will not work at all if any of the 3 radios' region is set to anything other than 00 (World)
2) 5GHz radios will not work if:
2.1) Channel width is set to more than 80MHz
2.2) Channel above 48 is selected
2.3) Cipher is set to anything other than "auto"

This makes the 2nd radio pretty much pointless because a single 80MHz channel will straddle all channels from 36 to 48, so you might as well switch it off for now.

There is also an issue with firmwares:

[   15.351600] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   15.374720] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed
[   15.869864] brcmfmac 0001:03:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   15.893020] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed
[   16.399870] brcmfmac 0001:04:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   16.423010] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed

It is looking for a non-existant firmware blob (the file name it reports is .txt, the actual file is .bin, creating a symlink or copying the bin to a txt so the fw loader can find it doesn't seem to fix it. In fact it makes it worse, the radios don't work at all, and the error message changes to:
[   23.068201] brcmfmac: brcmf_pcie_download_fw_nvram: FW failed to initialize

gordan wrote:

There is also an issue with firmwares:

[   15.351600] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   15.374720] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed
[   15.869864] brcmfmac 0001:03:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   15.893020] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed
[   16.399870] brcmfmac 0001:04:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
[   16.423010] firmware brcm!brcmfmac43602-pcie.txt: firmware_loading_store: map pages failed

It is looking for a non-existant firmware blob (the file name it reports is .txt, the actual file is .bin, creating a symlink or copying the bin to a txt so the fw loader can find it doesn't seem to fix it. In fact it makes it worse, the radios don't work at all, and the error message changes to:
[   23.068201] brcmfmac: brcmf_pcie_download_fw_nvram: FW failed to initialize

There is no such issue at all. brcmfmac failed to load NVRAM from separated file and it used platform one.
Trying to provide firmware image instead of NVRAM file (it is what you did) is just a totally bad idea.

So that error is from trying to load some kind of a configuration file rather than the firmware? Interesting because that doesn't appear to be what the error message says. So what is the non-existant brcmfmac43602-pcie.txt file, then?

On a more important note, is there a workaround to get the 5GHz radios to not choke on regions other than 00 and channels above 48?

gordan wrote:

So that error is from trying to load some kind of a configuration file rather than the firmware? Interesting because that doesn't appear to be what the error message says. So what is the non-existant brcmfmac43602-pcie.txt file, then?

I don't know how to explain it better. It's a file that may contain NVRAM content. It's for devices that don't have NVRAM on board and don't use platform NVRAM.

gordan wrote:

On a more important note, is there a workaround to get the 5GHz radios to not choke on regions other than 00 and channels above 48?

It's a generic problem with cfg80211, nothing brcmfmac specific. I don't know the solution.

I just tried working around the WiFi configuration issue by setting the regulatory domain directly:

/etc/modules.d/00-cfg80211:
  cfg80211 ieee80211_regdom=GB

That doesn't seem to fix the problem. Could this possibly be a wifi firmware blob issue? Is the firmware blob used in OpenWRT the same as the firmware blob used by the stock Netgear OS? If not, could it be that the WiFi firmware blob that ships with OpenWRT is deliberately locked down to 00 regulatory domain?

If it is a case of firmware being deliberately crippled, has anyone tried extracting the firmware from the stock OS and putting that in /lib/firmware/ ? Or is that the same firmware blob that is already there?

With regdom stuck at 00, the only channels available are:
2.4GHz: 1-11
5GHz: 36-48, 149-165

Since I'm in UK, I would very much like access to channels 12 and 13 in the 2.4GHz band since they are much less congested, and channels 50-112, since channels 36-48 tend to be quite congested and many of my devices don't support channels 149+.

(Last edited by gordan on 21 Jul 2016, 19:38)

Could someone please provide me R8000 NVRAM dump while either running Stock or on OpenWRT ?

gordan wrote:

I just tried working around the WiFi configuration issue by setting the regulatory domain directly:

/etc/modules.d/00-cfg80211:
  cfg80211 ieee80211_regdom=GB

That doesn't seem to fix the problem. Could this possibly be a wifi firmware blob issue? Is the firmware blob used in OpenWRT the same as the firmware blob used by the stock Netgear OS? If not, could it be that the WiFi firmware blob that ships with OpenWRT is deliberately locked down to 00 regulatory domain?

If it is a case of firmware being deliberately crippled, has anyone tried extracting the firmware from the stock OS and putting that in /lib/firmware/ ? Or is that the same firmware blob that is already there?

With regdom stuck at 00, the only channels available are:
2.4GHz: 1-11
5GHz: 36-48, 149-165

Since I'm in UK, I would very much like access to channels 12 and 13 in the 2.4GHz band since they are much less congested, and channels 50-112, since channels 36-48 tend to be quite congested and many of my devices don't support channels 149+.

The Country code issue is a rather complex one. We (brcmfmac engineers) haven't solved it yet correctly and it wont be solved any time soon probably and certainly not for the R8000.
What is problem: firmware needs more information then just country code. This means country code needs a translation to something called ccode/creg. Latest brcmfmac provides methods to do this translation when a table is provided. The table is product specific so it should be board specific data. This data does not exist at the moment, nor is the table available.
New regulations: FCC forbids setting country code at all (recently), and products have to be updated for this. As a result the current method in brcmfmac will probably be dropped, that is besides the fact that tables are unavailable and therefor it wont work anyway.
How to make it work: It can be made to work. What you need to do is make sure you have a brcmfmac which uses a table to translate country code, if that table doesn't exist the country code will not be configured, and that is what we ultimately want. Then you load the original Netgear firmware for the R8000, use the GUI to change the country code to the desired code. Then reload the openwrt image and voila you're done. The country code will be the correct one. As you don't need to (and are officially not allowed to) change the country code, this procedure needs to be done only once. 
If you don't have a brcmfmac which uses a translation table for determining ccode/creg. but do compile from sources then modify cfg80211.c from brcmfmac and return immediately on entry of the function brcmf_cfg80211_reg_notifier.

Also: read back in the thread. One of the 5G radios is only for lower frequencies and the other radio is for higher 5G frequencies, don't use them wrongly or they will not be very efficient.