Questions on 5.0MHz channel selection

Model: Ubiquiti UniFi-AC-PRO
Architecture: Qualcomm Atheros QCA956X ver 1 rev 0
Firmware: OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)
Kernel: 4.9.120

I'm trying to understand a couple key bits on how OpenWRT channel selection works for the 5.0MHz band with this AP. Output of 'iw list' (below) only shows 20MHz channels, but also that the unit supports 80MHz widths. LuCi presents these same channels, and offers widths of 20, 40 and 80MHz. I have two questions.

First, how do I configure hostapd for a 80MHz signal? With the stock UBNT firmware, it is possible to select the first 20MHz channel of an 80MHz band and then indicate bonding of higher, adjacent 20MHz channels to achieve 40MHz or 80MHz. Or, the top of an 80MHz band and indicate bonding of lower, adjacent 20MHz channels. In a nutshell, that's what the Ubiquiti engineers are describing in:


Do hostapd configuration options support a grammar for expressing this? Setting channel 36 or 149 at 80MHz width shows only 40MHz in Wavemon. Channel set to 'auto' and width at 80MHz goes for channel 36 at 40MHz.

Second, with hostapd does the 20MHz channel selection + 80MHz width just center on the selected channel and impinge on -40MHz and +40MHz of adjacent space? The cited article mentions a way for directing bonding upward or downward. So I'm wondering if hostapd is silently doing something similar. Or to ask this a slightly different way, should I pick 20MHz channels closer to the center of the 80MHz widths, say, 40, 44, 153, or 157?

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: 1 (up to 450m)
	Device supports AP-side u-APSD.
	Available Antennas: TX 0x7 RX 0x7
	Configured Antennas: TX 0x7 RX 0x7
	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-23
		VHT Capabilities (0x338001b2):
			Max MPDU length: 11454
			Supported Channel Width: neither 160 nor 80+80
			RX LDPC
			short GI (80 MHz)
			TX STBC
			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: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: MCS 0-9
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 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)
	valid interface combinations:
		 * #{ AP, mesh point } <= 8, #{ managed } <= 1,
		   total <= 8, #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.

The notation for specifying which "base" channel to use for a "wide" channel has never been clear to me.

Here's one link I just found, unconfirmed in its accuracy, http://blog.fraggod.net/2017/04/27/wifi-hostapd-configuration-for-80211ac-networks.html

Where "channel" can only be picked from the following list (see hw_features_common.c in hostapd sources):

36 44 52 60 100 108 116 124 132 140 149 157 184 192

[...]

Furthermore, picking anything but 36/42 and 149/155 is probably restricted by DFS and/or driver, and if you have any other 5G APs around, can also be restricted by conflicts with these, as detected/reported by hostapd on start.

I cannot suggest modification of regdb as it is generally unlawful to do so and then operate your device.

From https://w1.fi/cgit/hostap/tree/src/common/hw_features_common.c

int allowed_ht40_channel_pair(struct hostapd_hw_modes *mode, int pri_chan,
			      int sec_chan)
{
	int ok, j, first;
	int allowed[] = { 36, 44, 52, 60, 100, 108, 116, 124, 132, 140,
			  149, 157, 165, 184, 192 };

Another page that I find useful is

I think that 36 and 149 are the only "generally available" 80-MHz channels, at least in the US. There are no "generally available" 160-MHz channels in the US. Note that "in the UK/EU (channels 149 and higher require light licensing for outdoor use only)".

The short answer is, setting the following in /etc/config/wireless produces a 80MHz channel on either 36 or 149:

 option htmode 'VHT80'
 option channel 'auto'
 option channels '36 149'
 option log_level '1'

The long answer starts with confessing my faulty expectations. Simply moving the laptop within ~20' of the AP yielded 80 MHz in Wavemon. Also, 'iw dev' shows the AP is offering 80 MHz, while I was expecting the client to flawlessly negotiate to 80 MHz.

So, now to answer my first question, the solution is simply to select the bottom 20MHz channel of 80 MHz bands. This AP supports HT+ [and HT-]. The start-up script /lib/netifd/hostapd.sh uses HT+ to bond 20 MHz + 40 MHz + 20 MHz upward to set up an 80MHz channel. So with the base channel set at 149, 'iw dev' shows:

phy#0
	Interface wlan0
		ifindex 10
		wdev 0x3
		addr f0:9f:c2:f5:7d:53
		ssid WhiteRabbit50
		type AP
		channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
		txpower 30.00 dBm

Note that that center, 5775 MHz, is channel 155, which is NOT directly selectable. Similarly, if the base channel is 36 (5180 MHz), the center of the the relevant 80 MHz is displayed by 'iw dev' is 5210 MHz, or channel 42.

I don't have a solid answer to the second question, whether hostapd might impinge on 20 MHz channels outside of the allocated 80 MHz band. However, the "problem" is that whomever developed /lib/netifd/hostapd.sh did an awesome job. It simply doesn't allow for such nonsense. My first thought on seeing the script was, "Geez, why not just use a hostapd.conf?" But, this script tests the device's capabilities, parses the config files and produces a correct result.

Slightly off-topic --
Usually it does so even with some fairly messed options set in /etc/config/wireless. I did find a dysfunctional result by testing whether HT- also worked, though. Basically, with the base channel set to 48 or 161, the tops of 80 MHz bands, it still tries HT+ vice HT-. For this, the following goes to syslog (option log_level '1'):

Dec 20 05:46:30 WhiteRabbit hostapd: Interface initialization failed
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: interface state ACS->DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: AP-DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: ACS: Possibly channel configuration is invalid, please report this along with your config file.
Dec 20 05:46:30 WhiteRabbit hostapd: ACS: Failed to start
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: AP-DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Dec 20 05:46:30 WhiteRabbit hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: interface state DISABLED->DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: interface state DISABLED->DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: AP-DISABLED
Dec 20 05:46:30 WhiteRabbit hostapd: wlan0: CTRL-EVENT-TERMINATING
Dec 20 05:46:30 WhiteRabbit hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Dec 20 05:46:30 WhiteRabbit netifd: radio0 (1209): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Dec 20 05:46:30 WhiteRabbit netifd: radio0 (1209): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process  path ()
Dec 20 05:46:30 WhiteRabbit netifd: radio0 (1209): Command failed: Invalid argument
Dec 20 05:46:32 WhiteRabbit kernel: [   33.253224] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

This is either a nit-level bug or maybe a safety feature. Nit: it did not use HT- and bond 20+40+20 downward to set up an 80 MHz channel. But, at least it refused to impinge on frequencies outside of the allocated block.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.