WiFi: Enable support for 5GHz AccesPoints with DFS
Open, NormalPublicFEATURE 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

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:

Patch for vyatta-wireless against "upstream/current":

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
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
This request is:
Service Request
alainlamar updated the task description. (Show Details)
alainlamar updated the task description. (Show Details)Nov 13 2017, 9:29 AM
c-po added a subscriber: c-po.Nov 13 2017, 6:05 PM

@alainlamar thank you very much for providing such detailed information e.g. what is required inside the kernel configuration. This seems to be not a big deal to enable those.

Unfortunately debian lenny ships only hostapd version 2.3.1-1+deb8u5, sadly there is no hostapd package available from lenny-backports. Debian stretch ships hostapd 2.4-1+deb9u1, maybe we can somehow cherry pick this special version?

@c-po Hi, don't cheer up too early, I was not able to tst it all together since VyOS 1.2.x would not build due to server problems for the past week. Certain test steps on Ubuntu LTS 16.04 on a PC-Engines apu3b4 board using a Compex WLE600VX card indicated several possible pitfalls like reg domain switching. And then, as you already indicated, there are some old packages to be replaced in Debian Jessie. Major testing and some developing still needs to be done before we can celebrate a "recipe" for our cake. That is where I hope for your help and offer mine, too :-)

c-po added a comment.Nov 19 2017, 1:43 PM

I can confirm that by using this approach we can have hostapd 2.4 from debian stretch

c-po added a comment.Nov 19 2017, 1:56 PM

@alainlamar would you be willing to test a special image with all your required changes inside (Kernel, hostapd, firmware-atheros)? Only extension of vyatta-wireless is missing, but looks you could do this "on the fly"?

@c-po Yes, I happily would!
BTW: How did you manage to build 1.2.x with a custom Kernel? I continuously fail on the attempt when the build process tries to build the initrd for the custom Kernel. Would you mind to share your build steps?

Thank you!

c-po added a comment.Nov 20 2017, 9:45 AM

@alainlamar Unfortunately I have some problems with APT building my ISO but I added the steps for you here: https://wiki.vyos.net/wiki/Rebuild_VyOS_kernel_Step#VyOS_1.2.x

I'll pass you a DL link once I have a working ISO again.

@c-po Thanks for sharing your Kernel build steps. My question however was about building a custom Kernel _into_ a new ISO, so includung a successful run of "make iso".

Regarding "make iso", it seems we both ran into the same issue. While installing the Kernel, APT wants to build an initrd but for yet unknown reasons fails to do so.

Best regards!

  • Al

I have a script that builds all (well, almost all) the vyos packages from source, including the kernel, and then builds an iso with those rebuilt packages.

http://www.five-ten-sg.com/mapper/blog/vyos

c-po added a comment.Nov 28 2017, 7:11 PM

@carl.byington Thanks for this blogpost. Do you mind in supplying a build-all bash script we can have insied the vyos-build repository?

c-po added a comment.Dec 1 2017, 4:56 PM

@alainlamar I tried and tried but I never made it to properly build an image that has everything inside. This is a task for 1.3.x then, which is based on Debian 9! If this is setup it should be a piece of cake.

syncer moved this task from Need Triage to Backlog on the VyOS 1.3.x board.
syncer added a subscriber: syncer.

@alainlamar thanks for detailed description!
I wish that all tasks were created in that way.

Moving this to backlog of 1.3 directly.
Wireless part require lot of rework

syncer triaged this task as Normal priority.Dec 1 2017, 7:40 PM
alainlamar updated the task description. (Show Details)Dec 17 2017, 3:15 PM
alainlamar updated the task description. (Show Details)Dec 17 2017, 3:18 PM
alainlamar added a comment.EditedDec 17 2017, 3:33 PM

Meanwhile I learned how to successfully use DFS with the ATH10K driver. It is kind of a nasty driver to use as the makers put many obstacles into firmware and the driver module code to prevent "daisy chained" accidents related to setting wrong regulatory domains. RegDomain setting was not possible without Kernel config parameters "CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING" and "CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS". I guess that was the reason why hostapd always crashed when trying to use DFS.

I tested this with a Kali Linux installation on my apu3b4 with a WLE600VX card (using firmware-5.bin_10.2.4.70.61-2) and a hostapd configuration very similar to that posted above. To prevent "daisy chaining", I also set "REGDOMAIN=DE" in /etc/default/crda and "options cfg80211 ieee80211_regdom=DE" in /etc/modprobe.d/cfg80211.conf. These would always (I hope!) set the RegDomain as soon as modules are loaded.

Did anyone succeed yet in building VyOS 1.3 using a custom Kernel? If so, please advise!

Yours truly,
Al

alainlamar updated the task description. (Show Details)Tue, Dec 19, 9:22 PM
alainlamar updated the task description. (Show Details)Tue, Dec 19, 9:25 PM
alainlamar updated the task description. (Show Details)Tue, Dec 26, 7:26 PM
alainlamar added a project: VyOS 1.2.x.
alainlamar updated the task description. (Show Details)Tue, Dec 26, 7:43 PM
alainlamar removed a project: VyOS 1.2.x.
alainlamar added a comment.EditedTue, Dec 26, 8:04 PM

Hi folks,

I wish everyone a Merry Christmas!

And I've come prepared. Thanks to @carl.byington and his blog here, I was able to throw in my custom Kernel config and finally make a VyOS 1.2.x image holding a modified VyOS Kernel.

With addition of recent firmware files and correct hostapd configuration, I was able to run a 5GHz 802.11ac access point on VyOS 1.2.0!

This did not require including a version of hostapd newer than Jessie stock but it may require users to cherry-pick working firmware files (TODO: make config sections for that in vyatta-wireless) and put them into /lib/firmware/. In order to remain compatible to older 802.11 5GHz gear, one may also downgrade the wireless-regdb package to the version 2014.11.18-1 in order to keep out of recently approved channels above 140.

So the PoC is done for VyOS 1.2.x

Kernel patch (may be placed into the "updates" directory referenced in carl's blog):

Would anyone of you like to help adjusting the vyatta-wireless package?

Thank you!
Al

alainlamar updated the task description. (Show Details)Tue, Dec 26, 8:33 PM
alainlamar added a project: VyOS 1.2.x.
alainlamar updated the task description. (Show Details)Tue, Dec 26, 8:43 PM
c-po added a comment.Tue, Dec 26, 9:02 PM

@alainlamar thanks for your effort! Could you please regenerate your patch against arch/x86/configs/x86_64_vyos_defconfig which is used for the CI builds?

alainlamar added a comment.EditedTue, Dec 26, 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)Tue, Dec 26, 10:43 PM
alainlamar updated the task description. (Show Details)Thu, Dec 28, 4:33 PM
alainlamar added a comment.EditedThu, Dec 28, 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.Fri, Dec 29, 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)Mon, Jan 1, 4:52 PM
alainlamar updated the task description. (Show Details)Mon, Jan 1, 4:56 PM
alainlamar added a comment.EditedTue, Jan 2, 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)Sun, Jan 7, 5:37 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 5:48 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 6:09 PM
alainlamar updated the task description. (Show Details)
alainlamar updated the task description. (Show Details)Sun, Jan 7, 6:14 PM
alainlamar updated the task description. (Show Details)
alainlamar updated the task description. (Show Details)Sun, Jan 7, 6:21 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 6:25 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 8:50 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 9:05 PM
alainlamar updated the task description. (Show Details)Sun, Jan 7, 10:12 PM
alainlamar updated the task description. (Show Details)Sat, Jan 13, 12:47 PM
alainlamar updated the task description. (Show Details)Sat, Jan 13, 12:54 PM
alainlamar updated the task description. (Show Details)Sat, Jan 13, 12:57 PM
alainlamar updated the task description. (Show Details)Sat, Jan 13, 1:10 PM
alainlamar updated the task description. (Show Details)Sun, Jan 14, 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!