160MHz on Netgear R7800

#1

Has anyone successfully gotten a 160MHz wifi configuration working on R7800? It seems to get rejected regardless of the frequency settings I've tried. I'm running git master with the nbd staging tree changes merged in as well.

Presumably this router also supports 80+80MHz operation as well as the single 160MHz channel, but it doesn't look like this is implemented in the config scripts yet. I haven't managed to figure out the magic in the hostapd config file to get that to run manually either though.

#2

It's doubtful that, or any, router is currently capable of a 160MHz bandwidth... I'm not even sure there's wifi cards that support 160MHz bandwidths.

  • It's in LuCI mainly as a placeholder for when it does become available.
1 Like
#3

It's definitely supported on this router and works under the stock firmware (though it does seem picky about channel selection and I'm not sure there's an option for the 80+80 mode which seems more practical). There's a number of cards that support 160MHz now such as the Intel 9260.

1 Like
#4

I wasn't aware of that =]

#5

I found one issue in that the CA regulatory settings currently don't include 160MHz channel support. Switching the country to US doesn't help though, so there's obviously another issue as well.

#6

CA rules look very similar to AU rules, and I can start a 160mhz channel starting at 36 on a WRT3200ACM.

Hostapd has changed a few times how it handles 160 (including 80plus80).
This patch describes the current state of affairs, and you should be able to forge this config based on that info
https://github.com/openwrt/openwrt/blob/master/package/network/services/hostapd/patches/700-160mhz_interop_workaround.patch

LEDE x86 + VHT160 capable WiFi adapter in AP mode
#7

I've just got a Compex WLE1216V5-20 mPCI wireless card, which uses the same chip as R7800, QCA9984, and I have the same issue.
I've put the card in an ESXi server with LEDE x86_64 running as a VM, with PCI passthrough enabled, and any 160 MHz configuration is refused. Anything below that works fine though.
What a bummer.

#8

What is your kernel version?

#9

OpenWrt SNAPSHOT, r6259-6b6dc2b3e3
root@OpenWrt:~# uname -r
4.14.20

#10

I have the same problem too.
After turning on the 160Mhz for 5Ghz Wifi, it keeps up and down.

image

Larger resolution picture: https://imgur.com/D6zfqqA

Here's the system log, could anyone please provide help?

#11

Same issue on QCA9994 (same as 9984, but high temperature chip) with VHT160 - interface is up and down (ct-htt firmware). Latest OpenWrt, kernel 4.14.75.

#12

It seems that i can make it works on AU country code and 36 channel.

#13

OpenWRT 18.06.02 hasn't improved the 160MHz situation.

The regulatory db has the correct info, but setting 160MHz in luci causes hostapd to not bring up the adapter. Setting to the AU country code doesn't work either.

<pre>phy#0
country US: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
	(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
	(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
	(5735 - 5835 @ 80), (N/A, 30), (N/A)
	(57240 - 63720 @ 2160), (N/A, 40), (N/A)</pre>

<pre>Sat Mar 23 16:10:35 2019 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Sat Mar 23 16:10:42 2019 kern.warn kernel: [977907.692948] ath10k_pci 0000:01:00.0: Unknown eventid: 36933
Sat Mar 23 16:10:42 2019 kern.info kernel: [977907.696105] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Mar 23 16:10:42 2019 kern.info kernel: [977907.702019] br-lan: port 3(wlan0) entered blocking state
Sat Mar 23 16:10:42 2019 kern.info kernel: [977907.703667] br-lan: port 3(wlan0) entered disabled state
Sat Mar 23 16:10:42 2019 kern.info kernel: [977907.709154] device wlan0 entered promiscuous mode
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: interface state UNINITIALIZED-&gt;COUNTRY_UPDATE
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE-&gt;HT_SCAN
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: interface state HT_SCAN-&gt;DFS
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
Sat Mar 23 16:10:42 2019 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Sat Mar 23 16:10:42 2019 daemon.err hostapd: Interface initialization failed
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: interface state DFS-&gt;DISABLED
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: AP-DISABLED
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: interface state DISABLED-&gt;DISABLED
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: AP-DISABLED
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sat Mar 23 16:10:42 2019 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn&apos;t started
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sat Mar 23 16:10:42 2019 kern.info kernel: [977908.071830] device wlan0 left promiscuous mode
Sat Mar 23 16:10:42 2019 kern.info kernel: [977908.071925] br-lan: port 3(wlan0) entered disabled state
Sat Mar 23 16:10:42 2019 kern.warn kernel: [977908.112339] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 1
Sat Mar 23 16:10:42 2019 daemon.notice hostapd: ELOOP: remaining socket: sock=22 eloop_data=0xb6f73aa0 user_data=0 handler=0x42314
Sat Mar 23 16:10:42 2019 daemon.notice netifd: radio0 (15765): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 1400 path ()</pre>
#14

18.06.2 with VHT160 on qca9984 works and speed is very good (about 100 MB/s, not stable - sometimes drivers crashes), but on current master branch with new ath10k-ct drivers (2018-10-10-d366b80d-1) VHT160 did not works at all.
On 18.06.2 iw list shows:
valid interface combinations:
* #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }

On current master branch:
valid interface combinations:
* #{ managed } <= 16, #{ AP, mesh point } <= 16, #{ IBSS } <= 1,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

And i don't know how to fix this.

#15

If you can actually use 160 MHz channels, you can uninstall the -CT drivers and firmware and install the “classic” (no -ct suffix) drivers and firmware as packages (or in your own build).

#16

Even on classic drivers there is no success:
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 }

i have tried ath10k-ct driver and classic firmware, VHT160 has start showing in valid combination, but not works.

In all cases iw list shows:
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)
but not works.

#17

Describe "not works."

  • Are you using a clear channel (including ALL adjacent 40 MHz channels included)?
  • Are you actually testing when you have that much traffic passing on your WiFi?
#18

"Not works" is simple, i have two flash disk:

  1. on stable branch 18.06.2 with kmod-ath10k-ct and ath10k-firmware-qca9984-ct-htt
  2. on current master branch OpenWrt SNAPSHOT r9855-8f17c019a1 / LuCI Master (f138fc93) with kmod-ath10k-ct (have tried kmod-ath10k) and ath10k-firmware-qca9984-ct-htt (have tried classic/ct/ct-htt).
    1 - works VHT160 (successfully set and show 1733 mbit speed in WLAN card) ;
    2 - not works (entering disable state and hangs, wireless did not up).
Why the switch to unstable ath10k-ct?
#19

How did you get VHT160 to work on 18.06.2? I've tried numerous combinations, but hostapd refuses to start up. Please describe your settings. Your channel, regulatory domain, etc.

#20

You need to setup
Country Code: HT
Channel: 36
and wait about 1 min, than AP appears.