Pushed here for review: https://github.com/c-po/vyos-kernel/commit/0456e0acdcc5b9545723f57ebf489f2a1801a864

@syncer @dmbaturin @UnicronNL is this a GO to have the basis for 5 GHz APs?

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

@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 :-/

@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 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!

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#

In T529#11515, @alainlamar wrote:

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.

In T452#11673, @dmbaturin wrote:

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

... done

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...

@alainlamar clearfog is the ARM build for https://www.solid-run.com/marvell-armada-family/clearfog/