Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gluon-core: add outdoor channel support for 5 ghz radios #1329

Merged
merged 4 commits into from Apr 28, 2019
Merged

gluon-core: add outdoor channel support for 5 ghz radios #1329

merged 4 commits into from Apr 28, 2019

Conversation

@mweinelt
Copy link
Contributor

@mweinelt mweinelt commented Feb 12, 2018

    Add the `wifi5.outdoor_chanlist` site configuration that
    allows specifying an outdoor channel range that can be
    switched to for regulatory compliance.
    
    Upon enabling the outdoor option the device will
     - configure the `outdoor_chanlist` on all 5 GHz radios
     - which may enable DFS/TPC, based on the regulatory domain
     - disable ibss/mesh on the 5 GHz radio, as DFS *will*
       break mesh connections
     - allow for htmode reconfiguration on 5 GHz radios
    
    The outdoor option can be toggled from
     - Advanced Settings
       - W-LAN
         - Outdoor Installation
    
    The `preserve_channel` flag overrules the outdoor channel
    selection.

Configuring from Config Mode

config mode

Configuring from CLI

Outdoor disabled

root@64xxx-f81a67a5f222:~# uci set gluon.wireless.outdoor='0'
root@64xxx-f81a67a5f222:~# /lib/gluon/upgrade/200-wireless 
root@64xxx-f81a67a5f222:~# uci show wireless.radio0.channel; uci show wireless.radio1.channel; uci show wireless.mesh_radio0.disabled
wireless.radio0.channel='44'
wireless.radio1.channel='1'
wireless.mesh_radio0.disabled='0'
root@64xxx-f81a67a5f222:~# wifi
root@64xxx-f81a67a5f222:~# iw dev
phy#1
	Interface client1
		ifindex 18
		wdev 0x100000003
		addr f8:1a:67:a5:f2:21
		ssid darmstadt.freifunk.net
		type AP
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
	Interface mesh1
		ifindex 17
		wdev 0x100000002
		addr ae:02:43:9d:a4:05
		type mesh point
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
phy#0
	Interface client0
		ifindex 16
		wdev 0x3
		addr ae:02:43:9d:a4:00
		ssid darmstadt.freifunk.net
		type AP
		channel 44 (5220 MHz), width: 20 MHz, center1: 5220 MHz
		txpower 20.00 dBm
	Interface mesh0
		ifindex 15
		wdev 0x2
		addr ae:02:43:9d:a4:01
		type mesh point
		channel 44 (5220 MHz), width: 20 MHz, center1: 5220 MHz
		txpower 20.00 dBm

Outdoor enabled

root@64xxx-f81a67a5f222:~# uci set gluon.wireless.outdoor='1'
root@64xxx-f81a67a5f222:~# /lib/gluon/upgrade/200-wireless 
root@64xxx-f81a67a5f222:~# uci show wireless.radio0.channel; uci show wireless.radio1.channel; uci show wireless.mesh_radio0.disabled
wireless.radio0.channel='100'
wireless.radio1.channel='1'
wireless.mesh_radio0.disabled='1'
root@64xxx-f81a67a5f222:~# wifi
root@64xxx-f81a67a5f222:~# iw dev
phy#1
	Interface client1
		ifindex 21
		wdev 0x100000005
		addr f8:1a:67:a5:f2:21
		ssid darmstadt.freifunk.net
		type AP
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
	Interface mesh1
		ifindex 20
		wdev 0x100000004
		addr ae:02:43:9d:a4:05
		type mesh point
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
phy#0
	Interface client0
		ifindex 19
		wdev 0x4
		addr ae:02:43:9d:a4:00
		type AP
		channel 100 (5500 MHz), width: 20 MHz, center1: 5500 MHz
		txpower 22.00 dBm
root@64xxx-f81a67a5f222:~# logread | grep DFS
Mon Feb 12 01:22:49 2018 daemon.notice hostapd: client0: interface state COUNTRY_UPDATE->DFS
Mon Feb 12 01:22:49 2018 daemon.notice hostapd: client0: DFS-CAC-START freq=5500 chan=100 sec_chan=0, width=0, seg0=0, seg1=0, cac_time=60s
Mon Feb 12 01:23:49 2018 daemon.notice hostapd: client0: DFS-CAC-COMPLETED success=1 freq=5500 ht_enabled=1 chan_offset=0 chan_width=1 cf1=5500 cf2=0
Mon Feb 12 01:23:49 2018 daemon.notice hostapd: client0: interface state DFS->ENABLED

TODO

  • site validation
    • configurable list of acceptable outdoor channels (ranges and individual channels)
    • channel/chanlist validation
  • upgrade scripts
    • auto-enable for obvious 5ghz outdoor devices
  • config mode
    • show section in wizard, when enabled
    • enable outdoor mode and configure htmode in advanced settings
    • language strings
  • docs
@mweinelt mweinelt changed the title RFC: gluon-core, gluon-web-wifi-config: add outdoor option RFC, WIP: gluon-core, gluon-web-wifi-config: add outdoor option Feb 12, 2018
@blocktrron
Copy link
Member

@blocktrron blocktrron commented Feb 12, 2018

In addition to this, it would be great to have some devices pre-configured to use outdoor channels. Devices such as Nanostation M5, CPE510, UniFi AP AC Mesh (probably impossible atm. due to wrong board detection).

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Feb 13, 2018

If we're doing client only on 5 GHz we could aim for other htmodes as well, no?

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Feb 15, 2018

Simon Wunderlich's slides on "Dynamic Frequency Selection in 5 GHz mesh networks"
https://www.battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=get&target=2014-05-17_wbmv7_DFS.pdf

Intelligent handling of mesh connections is out of scope for this issue.

@MPW1412
Copy link
Contributor

@MPW1412 MPW1412 commented Feb 15, 2018

As comments were requested in the gluon developer mumble meeting tonight: I would like to see this merged, as we have a lot of Ubiquity AC Mesh Pro devices here in Münsterland, which are running with original firmware so far and could be flashed with Gluon then. For now we install the rocket m2 for mesh and use a dual band access point at the same place. This could be reduced to one dual band device and by this simplifies setups.

Vote fore merge. :)

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Feb 16, 2018

  • config mode lets you configure htmode per radio now.
  • config only shows up when you actually have a 11a/11na/11ac radio

config mode

looking for more people willing to test now! set wifi5.outdoor_chanlist to 100-140 for example.

also the section description and field labels could need some polishing, please start here: https://md.darmstadt.ccc.de/gluon-outdoor-config-mode

@mweinelt mweinelt changed the title RFC, WIP: gluon-core, gluon-web-wifi-config: add outdoor option RFC, WIP: gluon-core: add outdoor regulatory compliance support for 5 ghz radios Feb 16, 2018
@mweinelt mweinelt changed the title RFC, WIP: gluon-core: add outdoor regulatory compliance support for 5 ghz radios RFC, WIP: gluon-core: add outdoor channel support for 5 ghz radios Feb 16, 2018
@mweinelt mweinelt changed the title RFC, WIP: gluon-core: add outdoor channel support for 5 ghz radios RFC: gluon-core: add outdoor channel support for 5 ghz radios Feb 16, 2018
@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Feb 27, 2018

I tested this for the DFS-ETSI regdom, the 5 GHz radio automatically uses a txpower setting according to {regdom, device capability}.

The global regulatory domain seems to be what's used, the per phy value apparently is not.

# iw reg get
global
country DE: DFS-ETSI
	(2400 - 2483 @ 40), (N/A, 20), (N/A)
	(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
	(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
	(5725 - 5875 @ 80), (N/A, 14), (N/A)
	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#1
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)

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)

UAP-AC-Mesh

# iw dev
[...]
phy#0
	Interface client0
		ifindex 20
		wdev 0x6
		addr ba:f5:60:dd:39:70
		ssid darmstadt.freifunk.net
		type AP
		channel 140 (5700 MHz), width: 20 MHz, center1: 5700 MHz
		txpower 27.00 dBm

WDR4900v1 (didn't find a radar-free channel … weird)

# iw dev
[...]
phy#0
	Interface client0
		ifindex 28
		wdev 0x5
		addr ae:02:43:9d:a4:00
		type AP
		channel 120 (5600 MHz), width: 20 MHz, center1: 5600 MHz
		txpower 22.00 dBm

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Feb 28, 2018

The last commit adds an improved channel and chanlist validation:

wifi24.channel and wifi5.channel now check against an array of valid channels:

*** site.conf error: expected wifi24/channel to be one of the given array [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14], but it is 0
*** site.conf error: expected wifi5/channel to be one of the given array [34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 132, 134, 136, 138, 140, 142, 144, 149, 151, 153, 155, 157, 159, 161, 165, 169, 173], but it is 45

Also chanlist validation implements what hostapd describes to be a valid chanlist:

# Channel list restriction. This option allows hostapd to select one of the
# provided channels when a channel should be automatically selected.
# Channel list can be provided as range using hyphen ('-') or individual
# channels can be specified by space (' ') separated values
# Default: all channels allowed in selected hw_mode
#chanlist=100 104 108 112 116
#chanlist=1 6 11-13

@mweinelt mweinelt changed the title RFC: gluon-core: add outdoor channel support for 5 ghz radios gluon-core: add outdoor channel support for 5 ghz radios Feb 28, 2018
@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Mar 26, 2018

And the language strings for de and en are in. Next up is testing, testing and testing. Anybody willing to chime in?

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Mar 27, 2018

I currently see a 500 Bad Gateway after clicking Save & Restart. I don't get an error message and haven't found the error yet.

This issue was unrelated to this PR.

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Apr 4, 2018

Model detection for UAP-AC-M is stuck in the openwrt pull request queue (openwrt/openwrt#767) and OpenWrt 18.5 is supposed to be branched in 3 days.

IMO this is the most interesting device for this PR, but the review/merge isn't happening.

@MPW1412
Copy link
Contributor

@MPW1412 MPW1412 commented Apr 6, 2018

It's merged now.

openwrt/openwrt#767

@NeoRaider NeoRaider added this to the next milestone May 5, 2018
@rotanid rotanid removed this from the next milestone Jul 9, 2018
@rotanid rotanid added this to the 2018.2 milestone Jul 9, 2018
@CodeFetch
Copy link
Contributor

@CodeFetch CodeFetch commented Jul 22, 2018

There was a talk on the last battlemesh where they said that DFS in ath9k is broken as it has far too many false-positives (maybe it was a lightning talk as it is not on the schedule).
They said they have implemented DFS in hostapd which works reliable and it was tested in a certified environment. Maybe it was „Opennet Initiative“. I don't know... https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS/Experiment

I oppose merging this unless we are either sure that DFS works correctly (which I doubt) or whoever did that talk releases their work and we confirmed it's working.
It is not okay to merge something into Gluon that makes communities think they can switch to outdoor channels now while there is evidence that it is broken.

@Adorfer
Copy link
Contributor

@Adorfer Adorfer commented Jul 22, 2018

"false positives" are better than "no 5G outdoor at all".
If somebody can improve the DFS later: why not.
But at least it's start.
Or do you assume that "not merging" will improve the reliability of dectection significantly/instantly?

@CodeFetch
Copy link
Contributor

@CodeFetch CodeFetch commented Jul 24, 2018

@Adorfer You are right. I misunderstood what the PR does. As it falls back to indoor channels when no radar-free channel was detected, it is safe to merge this and I didn't see that one can define devices for which outdoor channels can be used before.
Only the DFS detection in ath9k is broken. Ath10k should be fine.
As far as I remember it can happen that a node continuously detects radar without any radar at all.
MarkusMartin said „WDR4900v1 (didn't find a radar-free channel … weird)“. It seems to be the case for this device as mine does not find a radar free channel, too.
Nonetheless I've written an e-mail to the Opennet people hoping that we can fix DFS completely soon.

@mweinelt We have a very strong CW radar in our city. It uses channels 116-132. Can you please change the outdoor channel siteconf definition to be a list instead so that one can define e.g. outdoor_chanlist = {'100-112', '136', '140'}, add a siteconf check to make sure that the default channel is always an indoor channel and mention this in the docs?

The only problem I still see is when radar was detected once and the node switches to the indoor channel it is unlikely that it ever switches to an outdoor channel again or am I missing something?

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Jul 24, 2018

@CodeFetch:

outdoor_chanlist = '100-112 136 140',

see #1329 (comment)

It shouldn't switch to an indoor channel if that's not in the chanlist.

(also I'm Martin, not Markus)

@CodeFetch
Copy link
Contributor

@CodeFetch CodeFetch commented Jul 24, 2018

@mweinelt Oh sorry Martin... Did I get it right the first time that when I activate outdoor channels it does not use the default (indoor) channel anymore?
Are you sure that it can't happen that a node detects radar on all outdoor channels hence not being reachable for some time at all?
In the talk they said some ath9k devices detect radar very often and some even always. I don't know if it only differs per location, device or chipset, but I'd like to be sure beforehand...

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Jul 25, 2018

When you activate outdoor mode it sets:

channel=auto

That removes the indoor channel from the hostapd configuration

As I described in #1329 (comment) I indeed had the situation that a WDR4900v1 didn't find a radar-free channel and therefore didn't set up the radio. I didn't research this any further.

I've tried this on ath9k/ath10k/mt76, all seem to be working (to some degree?).

@CodeFetch
Copy link
Contributor

@CodeFetch CodeFetch commented Mar 18, 2019

@blocktrron Merging with LibreMesh is on the plan for more than 3 years now. We've talked about that with the LibreMesh developers on the last BattleMesh and last consent was that after we've successfully modularized the packages to be independent from Batman and Babel integration is fine, we should have a look at how to support BMX7. That AREDN-Mesh wants to have a look at switching to Gluon is new. I have the names of devices in #94 corresponding to vendor device IDs from their firmware and extracted the other power offsets from the UBNT firmware. They want to get rid of their Perl-Scripts and switch to a cleaner solution.

Edit: BTW description of Gluon is "a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes" and not "Freifunk firmware build environment"

@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented Mar 23, 2019

"Merging with LibreMesh" is unrealistic, and I don't even consider it desirable, as it will further reduce the diversity in mesh firmware frameworks. We can work together and try to create modules that are usable by both projects, but I don't think either project will disappear.

@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented Mar 23, 2019

@CodeFetch Modularization can be achieved in a later refactoring.

@CodeFetch
Copy link
Contributor

@CodeFetch CodeFetch commented Mar 23, 2019

@NeoRaider Yes, it can be done later. I wasn't clear about that. "Merging" was the wrong word. They'd use Gluon as their base system when it's modular enough and as you say merging efforts of common packet development and system stability, device support patching etc.

package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua Outdated Show resolved Hide resolved
package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua Outdated Show resolved Hide resolved
scripts/check_site.lua Outdated Show resolved Hide resolved

uci:section('gluon', 'wireless', 'wireless', {
outdoor = platform_info.is_outdoor_device()
})
Copy link
Member

@NeoRaider NeoRaider Apr 23, 2019

I think it is unexpected that the outdoor mode may be enabled on a sysupgrade. When this is not a fresh configuration (sysconfig.gluon_version is set), outdoor should always be set to false.

Copy link
Contributor Author

@mweinelt mweinelt Apr 24, 2019

Fixed in 492c22e

Copy link
Member

@NeoRaider NeoRaider Apr 25, 2019

  1. Rather than doing nothing when sysconfig.gluon_version is set, outdoor should be set to false in this case
  2. I think it would make sense to have a site.conf option that can force the default to on or off

Copy link
Contributor Author

@mweinelt mweinelt Apr 25, 2019

  1. Wow, I didn't properly read what you wrote earlier, sorry. Fixed in f6b9feb.
  2. TODO.

Copy link
Contributor Author

@mweinelt mweinelt Apr 26, 2019

package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless Outdated Show resolved Hide resolved
@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented Apr 28, 2019

#1716 caused a few merge conflicts...

docs/site-example/site.conf Outdated Show resolved Hide resolved
mweinelt added 4 commits Apr 28, 2019
Add the `wifi5.outdoor_chanlist` site configuration that
allows specifying an outdoor channel range that can be
switched to for regulatory compliance.

Upon enabling the outdoor option the device will
 - configure the `outdoor_chanlist` on all 5 GHz radios
 - which may enable DFS/TPC, based on the regulatory domain
 - disable ibss/mesh on the 5 GHz radio, as DFS *will*
   break mesh connections
 - allow for htmode reconfiguration on 5 GHz radios

The outdoor option can be toggled from
 - Advanced Settings
   - W-LAN
     - Outdoor Installation

The `preserve_channel` flag overrules the outdoor channel
selection.
adds a section to the wizard for outdoor capable devices
that informs the user of of the regulatory situation and
allows a quick toggle of the outdoor mode.
@NeoRaider NeoRaider merged commit ddb11dd into freifunk-gluon:master Apr 28, 2019
@belzebub40k
Copy link
Contributor

@belzebub40k belzebub40k commented Apr 29, 2019

I just looked into the feature after it got merged but it looks like there is a mismatch between what is checked in check_site.lua ...

need_one_of({config, 'outdoors'}, {true, false, 'preset'}, false)

... and what is read in 180-outdoors.

local config = site.wifi5.outdoor_preset('preset')

Also the documentation says:

The outdoors option in turn allows to configure when outdoor mode will be enabled.

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Apr 29, 2019

Thanks, fixed in ad1a190.

@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented Apr 29, 2019

Hmm, should the site.conf setting really be placed under wifi5? While it doesn't matter for 2.4GHz, other frequency bands that may be added in the future will likely have similar restrictions, so I'd see the outdoor mode more as a global (toplevel) flag.

@NeoRaider
Copy link
Member

@NeoRaider NeoRaider commented Apr 29, 2019

Hmm, should the site.conf setting really be placed under wifi5? While it doesn't matter for 2.4GHz, other frequency bands that may be added in the future will likely have similar restrictions, so I'd see the outdoor mode more as a global (toplevel) flag.

@mweinelt Opinions on this?

@mweinelt
Copy link
Contributor Author

@mweinelt mweinelt commented Apr 29, 2019

Yes, long-term you are correct.

Short-term (still several years) we're not going to see another frequency band for outdoor usage, are we?

We can certainly change this now, I'm not sure we need to.

@mweinelt

This comment has been hidden.

@mweinelt mweinelt deleted the outdoor_mode branch Jun 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet