Page MenuHomePhabricator

WiFi: Enable support for 5GHz AccesPoints with DFS
Closed, ResolvedPublicFEATURE REQUEST

Description

In order to use recent WiFi networking, these prerequisites for 5GHz channel use need to be enabled:

Steps

  1. Include firmware packages for 802.11ac and 802.11n capable cards:
    • echo 'firmware-atheros' >> $vyos-build-dir/data/live-build-config/package-lists/vyos-utils.list.chroot
    • Firmware files may need to be cherry picked from linux kernel by users. For the Compex WLE600VX card, I needed to use firmware-5.bin_10.2.4.70.61-2 firmware-5.bin_10.2.4.70.66.
  2. Include a more recent hostapd (>2.4.x) [seems to work fine though with Jessie stock hostapd]
  3. Add configuration fields and options to the "vyatta-wireless" package. These might be free-text or options to input custom config file names to start with. hostapd will take multiple config files configuring multiple wifi cards in one go! (Proposed changes: see below)
  4. Build a custom Kernel with alterations to enable DFS. You may divert from common VyOS build scripts and use the approach from the next bullet instead.
  5. Using the script setup proposed by @carl.byington VyOS 1.2.x build scripts, build an image holding a custom Kernel with the needed alterations.
    • Find the Kernel path file attached to this task and use it with Carl's scripts!
  6. You may want to downgrade wireless-regdb package to the 2014 version (better patch it or use fixed channels) to keep compatible with older 802.11ac gear not knowing about clearance to use channels 144 to 157. Important update: frequencies 5755-5875MHz (channels 153-165) may NOT be cleared for private use within the EU. In Germany, they are for commercial provider use only. KEEP OUT!

Kernel Configuration

  1. Enable Kernel Device Drivers for 802.11ac and 802.11n capable cards (like Compex WLE600VX which uses ath10k)
  2. Enable Kernel support for DFS frequency scanning by enabling:
    • "Configure standard kernel features (expert users)" under "General Setup"
    • "cfg80211 certification onus" under "Networking support" -> "Wireless"
    • "Ministrel 802.11ac support" under "Networking support" -> "Wireless"
    • "Atheros DFS support for certified platforms" under "Device Drivers" -> "Network device support" -> "Wireless LAN" -> "Atheros Wireless Cards"
    • "Atheros dynamic user regulatory hints" under "Device Drivers" -> "Network device support" -> "Wireless LAN" -> "Atheros Wireless Cards" (*)
    • "Atheros dynamic user regulatory testing" under "Device Drivers" -> "Network device support" -> "Wireless LAN" ->"Atheros Wireless Cards" (*)

(*) I inferred this from this post (Reference: https://forum.ipfire.org/viewtopic.php?t=15300) and by looking up the Kernel source at ./drivers/net/wireless/ath/regd.c (see below). Without these settings the ATH10K driver will not allow the user to set different regulatory domains than what is preset in the device's firmware.
BE SURE TO SET THE CORRECT REGULATORY DOMAIN IN /etc/default/crda BEFORE STARTING HOSTAPD
BE SURE TO CREATE A FILE /etc/modprobe.d/cfg80211.conf CONTAINING YOUR REG DOMAIN PARAMETER: options cfg80211 ieee80211_regdom=DE (See op command in T529)

117 static bool dynamic_country_user_possible(struct ath_regulatory *reg)
118 {
119         if (IS_ENABLED(CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
120                 return true;
121 
122         switch (reg->country_code) {
123         case CTRY_UNITED_STATES:
124         case CTRY_JAPAN1:
[...]
183                 return false;
184         }
185 
186         return true;
187 }
188 
189 static bool ath_reg_dyn_country_user_allow(struct ath_regulatory *reg)
190 {
191         if (!IS_ENABLED(CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS))
192                 return false;
193         if (!dynamic_country_user_possible(reg))
194                 return false;
195         return true;
196 }

A working config for hostapd and the Compex WLE600VX card looks like this (Reference: ath10k configuration):

interface=wlan1
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ctrl_interface=/var/run/hostapd_wlan1
ctrl_interface_group=0

ssid=testtest.ac
wpa=2
wpa_passphrase=my-secret-key
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_ptk_rekey=600

country_code=DE
ieee80211d=1
ieee80211h=1
hw_mode=a
#channel=0 if you want automatic frequency selection (!!!DISCOURAGED UNLESS YOU KNOW WHAT YOU DO!!!)
channel=36
vht_oper_centr_freq_seg0_idx=42
beacon_int=100
dtim_period=2
max_num_sta=32
rts_threshold=2347
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
disassoc_low_ack=1
ieee80211n=1
ht_capab=[HT20][HT40+][HT40-][MAX-AMSDU-7935][SMPS-STATIC][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
ieee80211ac=1
vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP3][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][BF-ANTENNA-2][SOUNDING-DIMENSION-2][VHT-LINK-ADAPT3]
vht_oper_chwidth=1
local_pwr_constraint=3

tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
wmm_enabled=1
uapsd_advertisement_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
disassoc_low_ack=1
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1

Proof of Concept for VyOS 1.2.x:

Kernel patch against debian/arch/amd64/config.amd64-vyos (with some long overdue hardware crypto acceleration added):

Kernel patch against arch/x86/configs/x86_64_vyos_defconfig:

Link to vyatta-wireless work in progress:
https://github.com/alainlamar/vyatta-wireless/commits/t452-802.11ac

Rebuild wireless-regdb

  1. On a Jessie build machine, do:
    1. sudo apt-get build-dep crda wireless-regdb
    2. git clone git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
    3. cd wireless-regdb
    4. vim db.txt
    5. Restrict regdom settings for your country according to local law! For Germany, this means disabling channels greater 140 by prepending a # to the line: #(5725 - 5875 @ 80), (25 mW)
    6. make
    7. fakeroot checkinstall -D --install=no make install
  2. copy deb package to vyos
  3. On a VyOS instance, do:
    1. install package on vyos: dpkg -i <your-wireless-regdb-package.deb>
    2. reboot
    3. Test if your regdom settings have been applied accordingly:
    4. sudo regdbdump /lib/crda/regulatory.bin
    5. sudo iw reg get
    6. sudo iw phy phy0 info
    7. sudo iw dev wlan0 info

Wireless-regdb Patch suitable for Debian/Ubuntu/VyOS:

Useful References

  1. Linux Kernel wireless wiki pages, DFS section with subpages to specific regulatory domains
  2. Linux Kernel git repo for wireless-regdb with cleartext entries and links to certification documents
  3. Bundesnetzagentur: 5755-5875MHz open for commercial providers only! (means: Germans have to patch wireless-regdb to exclude channels > 140 from being used by automatic frequency selection)
  4. Linux Kernel Wireless Wiki: Regulatory rules processing
  5. Linux Kernel Wireless Wiki: The Regulatory Database
  6. 802.11ac channels explained (partially outdated)
  7. CWAP – HT Capabilities IE (very good explanation on HT capabilities)

Helpers

  1. Online calculator to transform power units (for ex: mW <--> dBm)
  2. Linux Kernel Wireless Wiki: iw tricks
  3. Altering wireless-regdb (German)
  4. WLAN Frequenzen (German, information compiled by Freifunk Franken)

Details

Difficulty level
Hard (possibly days)
Version
-
Why the issue appeared?
Will be filled on close
This request is:
Service Request
There are a very large number of changes, so older changes are hidden. Show Older Changes
alainlamar added a comment.EditedDec 26 2017, 10:02 PM

@c-po here you go:

I didn't even notice the change you mentioned in Q121...

Edited:
I re-generated that patch again since I just took my config and replaced the arch/x86/configs/x86_64_vyos_defconfig with it in the first run. I realised there were very many differences which likely were not caused by my changes.

So, this time, I did:

  1. cp arch/x86/configs/x86_64_vyos_defconfig .config
  2. make menuconfig
  3. made my changes
  4. saved the .config
  5. cp .config arch/x86/configs/x86_64_vyos_defconfig
  6. git diff arch/x86/configs/x86_64_vyos_defconfig

Sorry for the hassle...

alainlamar updated the task description. (Show Details)Dec 26 2017, 10:43 PM
alainlamar updated the task description. (Show Details)Dec 28 2017, 4:33 PM
alainlamar added a comment.EditedDec 28 2017, 4:58 PM

Today, I had a look into the vyatta-wireless package to see if I could hack something up to work with the new Kernel changes via VyOS CLI.

I came up with a quick proposual of minimal changes which allow:

  • configuration of multiple wireless devices via CLI, including 5GHz frequency band
  • bridging of multiple wireless devices
  • use of custom hostapd.conf parameters

A working VyOS config for a dual-band bridged access point would look like this:

vyos@vyos# show interfaces wireless
 wireless wlan0 {
     bridge-group {
         bridge br0
     }
     channel 0
     country DE
     debug enable
     description "5GHz Access Point with DFS"
     hostapd-option disassoc_low_ack=1
     hostapd-option max_num_sta=32
     hostapd-option ht_capab=[HT20][HT40+][HT40-][SMPS-STATIC][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
     hostapd-option vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1][MAX-A-MPDU-LEN-EXP7][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][BF-ANTENNA-2][SOUNDING-DIMENSION-2][VHT-LINK-ADAPT3]
     hostapd-option vht_oper_chwidth=1
     hostapd-option local_pwr_constraint=3
     hostapd-option ieee80211w=2              #  <-- CULPRIT HERE!!!
     hostapd-option wpa_ptk_rekey=600         #  <-- CULPRIT HERE!!!
     hw-id 04:f0:21:34:19:6d
     mode ac
     physical-device phy0
     security {
         wpa {
             cipher CCMP
             mode wpa2
             passphrase my-super-secret-passphrase
         }
     }
     ssid accesspoint.ac
     type access-point
 }
 wireless wlan1 {
     bridge-group {
         bridge br0
     }
     channel 6
     country DE
     debug enable
     description "2.4GHz Access Point"
     hostapd-option max_num_sta=16
     hostapd-option ht_capab=[HT20][HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
     hw-id 80:1f:02:f7:27:5a
     mode n
     physical-device phy1
     security {
         wpa {
             cipher CCMP
             mode wpa2
             passphrase my-super-secret-passphrase
         }
     }
     ssid accesspoint.n
     type access-point
 }
[edit]
vyos@vyos#

Proposed patch for vyatta-wireless

Known Bugs

  • [solved] The 5GHz access point seems to forget its channel configuration every now and then (reason yet unknown, but symptoms are known to the Internet). This results in the wifi card going offline and being reconfigured and put online automatically again. Syslog has the following:
Dec 28 15:43:57 vyos kernel: [  484.286804] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:43:57 vyos kernel: [  484.320435] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:43:57 vyos kernel: [  484.336124] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:43:57 vyos kernel: [  484.351280] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:02 vyos kernel: [  489.443365] ath10k_warn: 58 callbacks suppressed
Dec 28 15:44:02 vyos kernel: [  489.443396] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  489.906011] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.599879] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.631953] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.632533] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.632922] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.673077] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.852364] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:03 vyos kernel: [  490.859497] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:04 vyos kernel: [  490.863981] ath10k_pci 0000:04:00.0: no channel configured; ignoring frame(s)!
Dec 28 15:44:04 vyos zebra[1553]: interface wlan1 index 5 changed <UP,BROADCAST,RUNNING,MULTICAST>.
Dec 28 15:44:04 vyos zebra[1553]: interface br0 index 7 changed <UP,BROADCAST,RUNNING,MULTICAST>.
Dec 28 15:44:04 vyos zebra[1553]: interface wlan0 index 6 changed <BROADCAST,MULTICAST>.
Dec 28 15:44:06 vyos zebra[1553]: interface wlan0 index 6 changed <UP,BROADCAST,MULTICAST>.
Dec 28 15:44:09 vyos zebra[1553]: interface wlan0 index 6 changed <UP,BROADCAST,RUNNING,MULTICAST>.
  • hostapd would not log to syslog engines even if instructed to do so by putting logger_syslog=-1 and logger_syslog_level=2 into the respective config files (done by using the "debug enable" config node via CLI). Reason is yet unknown. Hostapd however does log to stdout if started manually without forking to background.
  • [solved] While phones and Windows Laptops seem to connect just fine, several laptops see the network but fail to properly connect under Linux while doing just fine under Windows. Also, older gear just supporting 5GHz mode n but not ac fail to connect as well. While I believe there may be a driver issue on the Linux rtl8821ae implementation, I'm rather puzzled about the failure to use mode n on 5GHz. I'll play around a bit and try to find the culprit - maybe the bridged Wifi mac makes devices vomitting. This was tested against the above configuration using those devices:
    • Sony Xperia Z3c (latest stock ROM, Android 6.0.1) [works fine]
    • iPhone SE (iOS 11.2.1) [works fine]
    • Lenovo ideapad 110s with RTL8821AE (Windows 10 Professional works fine, Ubuntu LTS 16.04 successfully connects to 2.4GHz only) solved, set ieee80211w=0
    • Lenovo Thinkpad 420s with Intel 802.11bgn card capable of 5GHz for mode n (Ubuntu 16.04 LTS successfully connects to 2.4GHz only) solved, set ieee80211w=0
    • Google Nexus 10 (most recent LineageOS 13) [successfully connects to 2.4GHz only, capable of mode n on 5GHz but not mode ac] solved, set ieee80211w=0

Update:
Culprit found! It was the management frame protection introduced on the 5GHz mac. You may configure it in hostapd.conf in three values:

  • ieee80211w=2 for enforced management frame protection
  • ieee80211w=1 for optional (whatever this means) MGMT frame protection
  • ieee80211w=0 for no MGMT frame protection.

Obviously, the latter is not what you want if you think of deassoc attacks and the like. But it turns out that:

  • Nexus 10 works just fine on 5GHz 802.11n with ieee80211w=0
  • Lenovo's ideapad works just fine on 5GHz 802.11ac with ieee80211w=0 --> I blame Realtek for very bad Linux driver implementation on this one!
  • Lenovo's T420s with the old iwlwifi card (802.11n on 5GHz only) works just fine with ieee80211w=0

The AP crashes were tracked down to the re-keying I had configured by setting wpa_ptk_rekey=600. Without re-keying, the AP is stable.

Please ping me once a VyOS dev image has been built which incorporates the Kernel changes.

Yours truly,
Al

c-po added a comment.Dec 29 2017, 11:49 AM

@alainlamar Kernel Updated and Rebuild triggered on CI server.

In T452#10768, @c-po wrote:

@alainlamar Kernel Updated and Rebuild triggered on CI server.

Cheers! I just built myself a new ISO and the new Kernel works fine! Now it is easier to get things in vyatta-wireless right. There are still some quirks left :-/

alainlamar updated the task description. (Show Details)Jan 1 2018, 4:52 PM
alainlamar updated the task description. (Show Details)Jan 1 2018, 4:56 PM
alainlamar added a comment.EditedJan 2 2018, 1:04 PM

@c-po I did some major work on vyatta-wireless, including the introduction of nested nodes to configure card capabilities. Would you mind to take a look at it and suggest improvements for:

  • using a better way than Perl smartmatch to compare strings against arbitrary lists of strings (like in Python if "bar" in ["foo", "bar", "baz"]: print("True"))
  • a nicer way to getting rid of mutual exclusions without adding too much responsibility on parsing by wireless-hostapd.pl. Transforming ht and vht from multi nodes into nested directories and then implement a bool node for each capability flag would IMHO require much more parsing in wireless-hostapd.pl but would solve the issue with mutual exclusions which could be implemented as simple multi-choice nodes...

Example wireless interface configuration:

vyos@vyos# show interfaces wireless wlan0
 address 172.31.255.254/24
 capabilities {
     ht HT20
     ht HT40+
     ht HT40-
     ht SMPS-STATIC
     ht LDPC
     ht SHORT-GI-20
     ht SHORT-GI-40
     ht TX-STBC
     ht RX-STBC1
     ht MAX-AMSDU-7935
     ht DSSS_CCK-40
     require-ht true
     vht MAX-MPDU-11454
     vht RXLDPC
     vht SHORT-GI-80
     vht TX-STBC-2BY1
     vht RX-STBC-1
     vht MAX-A-MPDU-LEN-EXP7
     vht RX-ANTENNA-PATTERN
     vht TX-ANTENNA-PATTERN
     vht BF-ANTENNA-2
     vht SOUNDING-DIMENSION-2
     vht VHT-LINK-ADAPT3
     vht-channel-width 1
 }
 channel 0
 country DE
 debug enable
 description "5GHz Access Point with DFS"
 hostapd-option disassoc_low_ack=1
 hostapd-option local_pwr_constraint=3
 hw-id 04:f0:21:xx:xx:xx
 max-stations 16
 mgmt-frame-protection disabled
 mode ac
 physical-device phy0
 security {
     wpa {
         cipher CCMP
         mode wpa2
         passphrase secret-passphrase
     }
 }
 ssid my-test-network
 type access-point
[edit]
vyos@vyos#

Commits:
https://github.com/alainlamar/vyatta-wireless/commits/t452-802.11ac

side note:
There is a big fat commit in the pile with inter-dependencies -- very hard (time consuming) to try and split that up. Since I'm a full time worker and just have a few hours while on holidays, I'd like to provide suggestions and get things done rather quickly while being aware of that I'm neither a top quality Bash/Perl programmer nor blessed with deep understanding of former Vyatta parsing mechanics :-/

Thanks!

Hey everyone,

Would you consider participating in rewrting the wireless code in python too, or at least converting your old style templates to new style XML definitions?

@dmbaturin Yes, as time permits. That's my worst constraint.

alainlamar updated the task description. (Show Details)Jan 7 2018, 5:37 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 5:48 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 6:09 PM
alainlamar updated the task description. (Show Details)
alainlamar updated the task description. (Show Details)Jan 7 2018, 6:14 PM
alainlamar updated the task description. (Show Details)
alainlamar updated the task description. (Show Details)Jan 7 2018, 6:21 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 6:25 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 8:50 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 9:05 PM
alainlamar updated the task description. (Show Details)Jan 7 2018, 10:12 PM
alainlamar updated the task description. (Show Details)Jan 13 2018, 12:47 PM
alainlamar updated the task description. (Show Details)Jan 13 2018, 12:54 PM
alainlamar updated the task description. (Show Details)Jan 13 2018, 12:57 PM
alainlamar updated the task description. (Show Details)Jan 13 2018, 1:10 PM
alainlamar updated the task description. (Show Details)Jan 14 2018, 1:52 PM

@alainlamar by any chance you want to be maintainer of wireless subsystem ? :)
It looks like you both have knowledge and real life use case and that make it whole easier

@syncer thanks for the offer :)

I'd be happy to continue work on that package as it is not done yet by far. However, I cannot guarantee a given response time on requests or regular time slots to do work on it.

If that is still fine with you guys, I am, too.

Best regards!
Al

That is fine, maybe with exception for some nasty vulnerabilities, however we also not disappear
just handy to have someone dedicated to wireless (almost separate world)
Thank you!

alainlamar updated the task description. (Show Details)Jan 18 2018, 7:34 PM
alainlamar added a comment.EditedJan 21 2018, 6:11 PM

Pull request sent. Please consider a merge.

This improvement is old-style Vyatta compatible Perl and Bash. Rewrite will follow at a later stage, once these changes are functionally committed to CI-built images. The configuration improvements are fully backwards compatible, so existing setups don't need to have their configurations altered.

Please consider to fix T521 soon.

I know y'all (@c-po well, at least some :-) ) may want to kill me for this, but these changes will only work if the whole lot gets merged. I had to test and debug in-situ (real hardware needed), copying tarballs of node.defs and altered Perl scripts back and forth...

5GHz WiFi is now functional with those notes:

  • Users must install compatible firmware for their cards if VyOS (Debian Jessie) does not have it in stock
  • Users must know the capabilities and limitations of their cards (iw phy phy0 list may help)
  • Users must check their regulatory domain settings when setting up their cards for the first times (iw reg get; iw phy phy0 info, etc) and make sure the channel mappings and emitted signal strength matches their country's laws
  • Users may have to patch their regdb (MUST patch if based in Germany and using DFS)
  • Users may have to edit /etc/default/crda to set their regulatory domain (example: REGDOMAIN=DE)
  • Users may have to add /etc/modprobe.d/cfg80211.cfg and add an option for their regulatory domains (example: options cfg80211 ieee80211_regdom=DE) However, I'm planning an operations command that helps users set these values...
  • Network services may fail to start up if they use a WiFi interface that is configured for DFS. However, this is not a WiFi bug, see T521.

Please find a configuration syntax example for a dual band AP below:

wireless wlan0 {
    address 172.31.254.254/24
    capabilities {
        ht {
            40MHz-incapable true
            auto-powersave true
            channel-set-width ht20
            delayed-block-ack false
            dsss-cck-40 true
            greenfield false
            ldpc true
            lsig-protection false
            max-amsdu 7935
            short-gi 20
            short-gi 40
            smps static
            stbc {
                rx 1
                tx true
            }
        }
        require-ht false
        require-vht false
    }
    channel 1
    country DE
    debug enable
    description "2.4GHz Access Point"
    expunge-failing-stations false
    hw-id aa:bb:cc:dd:ee:ff
    isolate-stations true
    max-stations 16
    mgmt-frame-protection disabled
    mode n
    physical-device phy0
    reduce-transmit-power 2
    security {
        wpa {
            cipher CCMP
            mode wpa2
            passphrase your-secret-phrase
        }
    }
    ssid 2.4GHz-AP
    type access-point
}
wireless wlan1 {
    address 172.31.255.254/24
    capabilities {
        ht {
            40MHz-incapable false
            auto-powersave true
            channel-set-width ht20
            channel-set-width ht40+
            channel-set-width ht40-
            delayed-block-ack false
            dsss-cck-40 true
            greenfield false
            ldpc true
            lsig-protection false
            max-amsdu 7935
            short-gi 20
            short-gi 40
            smps static
            stbc {
                rx 1
                tx true
            }
        }
        require-ht true
        require-vht false
        vht {
            antenna-count 2
            antenna-pattern-fixed true
            center-channel-freq {
                freq-1 42
            }
            channel-set-width 1
            ldpc true
            link-adaptation both
            max-mpdu 11454
            max-mpdu-exp 3
            short-gi 80
            stbc {
                rx 1
                tx true
            }
        }
    }
    channel 36
    country DE
    debug enable
    description "5GHz Access Point with DFS"
    expunge-failing-stations true
    hw-id aa:bb:cc:dd:ee:fe
    isolate-stations true
    max-stations 16
    mgmt-frame-protection disabled
    mode ac
    physical-device phy1
    security {
        wpa {
            cipher CCMP
            mode wpa2
            passphrase your-secret-phrase
        }
    }
    ssid 5GHz-AP
    type access-point
}

Auto-complete help screens for set interfaces wireless wlan0 capabilities:

vyos@ap-test# set interfaces wireless wlan0 capabilities 
Possible completions:
 > ht           HT settings
   require-ht   Require stations to support HT PHY (reject association if they do not)
   require-vht  Require stations to support VHT PHY (reject association if they do not)
 > vht          VHT settings
      
[edit]
vyos@ap-test# set interfaces wireless wlan0 capabilities vht 
Possible completions:
   antenna-count
                Number of antennas on this card
   antenna-pattern-fixed
                set if antenna pattern does not change during the lifetime of an association
+  beamform     Beamforming capabilities
 > center-channel-freq
                VHT operating channel center frequency
   channel-set-width
                VHT operating Channel width
   ldpc         LDPC coding capability
   link-adaptation
                VHT link adaptation capabilities
   max-mpdu     Increase Maximum MPDU length to 7991 or 11454 octets (otherwise: 3895 octets)
   max-mpdu-exp Set the maximum length of A-MPDU pre-EOF padding that the station can receive
+  short-gi     Short GI capabilities
 > stbc         Support for sending and receiving PPDU using STBC (Space Time Block Coding)
   tx-powersave Support for VHT TXOP Power Save Mode
   vht-cf       STA supports receiving a VHT variant HT Control field

[edit]
vyos@ap-test#
alainlamar changed the task status from Open to In progress.Jan 23 2018, 10:16 PM
alainlamar changed the status of subtask T529: Create op command to set regulatory domain from Open to In progress.
alainlamar updated the task description. (Show Details)Jan 26 2018, 10:21 PM
alainlamar changed Difficulty level from Unknown (require assessment) to Hard (possibly days).Jan 27 2018, 9:37 PM
alainlamar moved this task from Backlog to In Progress on the VyOS 1.3.x board.Jan 27 2018, 9:42 PM

I had a chat with @syncer yesterday, where we also discussed the approach of setting WiFi regulatory domains. We agreed upon two issues prompting for an Architect's decision (@dmbaturin):

  • Code that does persistent changes should go to the configure section. This would mean three things:
    • The part writing to files would be moved from T529 to T452.
    • Backward compatibility in T452 would be broken as the set interfaces wireless wlanX country DE node would be moved in front of the interface name tag config node: set interfaces wireless regulatory-domain DE which would allow for a complete and easy to understand way of making all persistent changes in one go. [...]

I'd like to prompt for a decision:

  • break backward compatibility to implement the above scheme (I'd suggest that) or
  • stick with this pull request (T452) and work around the regdom-setting by using the existing pull request in T529.

Thank you!
Al

I'd like to prompt for a decision:

  • break backward compatibility to implement the above scheme (I'd suggest that) or
  • stick with this pull request (T452) and work around the regdom-setting by using the existing pull request in T529.

My idea of implementing set interfaces wireless regulatory-domain DE was utterly stupid as the node after wireless is the wlanXX tag node. Forcing regdom settings into there would be like doing Frankenstein surgery on the config concept of tag nodes. So I decided to make set system wifi-regulatory-domain DE available to the wireless configuration templates and removing the wireless wlanXX country node. This obviously breaks backwards compatibility but at the same time it allows to persistently set regulatory domain setting at one fixed point and apply changes in one commit step. However, since settings from /etc/modprobe.d/cfg80211.conf will only become active after reloading the cfg80211 module (which you only can do after removing all depending wireless modules), a VyOS restart is necessary to complete the change. No change will be done however on the running regulatory domain setting during the commit (aka no iw reg set DE call is made).

Please test, discuss and consider for merge (you may cherry pick this, but it depends on all previous commits in this pull request).

Merged.

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

alainlamar added a comment.EditedFeb 11 2018, 12:58 PM

Merged.

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

Thank you! I'll start th refactor to Python now.

Would somebody please trigger a rebuild of the the vyatta-wireless package on the CI environment?

Thanks a lot!
Al

Cheers @c-po! Unfortunately, the build failed with reference to "clearfog". Do you know what this is or if I could fix this somehow in vyatta-wireless?
Right now, I have no idea...