summaryrefslogtreecommitdiff
path: root/interface-definitions/interfaces-wireless.xml.in
AgeCommit message (Collapse)Author
2020-09-16wireless: T1627: "capabilities ht smps" is not a multi nodeChristian Poessinger
2020-09-16wireless: T1627: "capabilities ht max_amsdu" is not a multi nodeChristian Poessinger
VyOS 1.2 confirmed it was a regular node - copy/paste error.
2020-07-25wireless: ifconfig: T2653: move to get_config_dict()Christian Poessinger
The current VyOS CLI parser code written in Python contains a ton of duplicates which I can also hold myself accountable for - or maybe mainly me - depends on the angle of judge.
2020-06-14wireless: T2354: add new validator for phy interfacesChristian Poessinger
2020-05-17xml: split dhcp, dhcpv6 to individual filesChristian Poessinger
2020-05-07wireless: T2427: add common interface includes to templateJernej Jakob
2020-04-17wireless: T2306: bugfix: insert missing </leafNode>Alain Lamar
2020-04-17wireless: T2306: Add new cipher suites to the WiFi configurationAlain Lamar
Yet, VyOS knows these two encryption schemes for WiFi: 1. CCMP = AES in Counter mode with CBC-MAC (CCMP-128) 2. TKIP = Temporal Key Integrity Protocol These encryption schemes are new and especially the Galois counter mode cipher suites are very desirable! 1. CCMP-256 = AES in Counter mode with CBC-MAC with 256-bit key 2. GCMP = Galois/counter mode protocol (GCMP-128) 3. GCMP-256 = Galois/counter mode protocol with 256-bit key CCMP is supported by all WPA2 compatible NICs, so this remains the default cipher for bidirectional and group packets while using WPA2. Use 'iw list' to figure out which cipher suites your cards support prior to configuring other cipher suites than CCMP. AP NICs and STA NICs must both support at least one common cipher in a given list in order to associate successfully.
2020-04-13XML: T2282: clarify on ethernet and wireless hw-id nodesChristian Poessinger
2020-04-05wireless: T2212: bugfix for BF-ANTENNA and SOUNDING-DIMENSION flagsalainlamar
VHT flags deal with many variables which depend on antenna count and supported features. BF-ANTENNA-(2|3|4) and SOUNDING-DIMENSION-(2|3|4) were not dealt with correctly. IEEE 802.11ac (VHT) supports at least 1 antenna and up to 8 antennas at most. The hsotapd VHT flags may support as many but most do not. Therefore, we need to be picky here...
2020-04-04wireless: T2208: bugfix: errors in the XML and Python fileAlain Lamar
Commits to "interfaces wireless wlanX capabilities vht link-adaptation (unsolicited|both)" always failed.
2020-04-03interfaces: XML: constraint: add start of line ^ to regexChristian Poessinger
2020-03-28ipv6: T1831: migrate autoconf nodeChristian Poessinger
Autoconfigure addresses using Prefix Information in Router Advertisements.
2020-03-28ipv6: T1831: migrate forwarding and dup-addr-detect-transmits nodesChristian Poessinger
... to new XML and Python based frontend/backend.
2020-03-08wireless: radius: T2110: migrate to XML includeChristian Poessinger
2020-03-08vrf: T31: enable vrf support for wireless interfaceChristian Poessinger
2020-01-26Interfaces: unify interface help textChristian Poessinger
2020-01-03ifconfig: T1939: provide abstraction for interface "ip" optionChristian Poessinger
Provide an XML/Python abstraction to * ip disable-arp-filter * ip enable-arp-accept * ip enable-arp-announce * ip enable-arp-ignore The old implementation can co-exist until the last interfaces have been migrated.
2019-12-06T1843: use include files for interface link-detect featureChristian Poessinger
2019-12-06T1843: use include files for interface MAC addressChristian Poessinger
2019-12-06T1843: use include files to disable interface (admin down)Christian Poessinger
2019-12-06T1843: use include files for interface descriptionChristian Poessinger
2019-12-06T1843: use include files for DHCP/DHCPv6 optionsChristian Poessinger
As 219779b ("T1843: run interface-definitions though GCC preprocessor") implemented the foundation of using the GCC preprocessor to make our XML definitions more lightweight this commit transforms the configuration of DHCP/ DHCPv6 configuration options to this new style. It implementes it for the following interface types: * bonding * bridge * ethernet * wireless * vif/vif-s interfaces
2019-12-06T1843: recursively include IP address definitions in VIF/VIF-S definitionsChristian Poessinger
2019-12-06T1843: use include files for VIF/VIF-S interfacesChristian Poessinger
As 219779bc6151 ("T1843: run interface-definitions though GCC preprocessor") implemented the foundation of using the GCC preprocessor to make our XML definitions more lightweight this commit transforms the configuration of VIF and VIF-S interfaces to this new style. It implementes it for the following types: * bond * ethernet * wireless
2019-12-06T1843: use include files for IPv4/IPv6 interface address configurationChristian Poessinger
As 219779bc6151 ("T1843: run interface-definitions though GCC preprocessor") implemented the foundation of using the GCC preprocessor to make our XML definitions more lightweight this commit transforms the configuration of an IPv4/IPv6 address to this new style. It implementes it for the following interface types: * bond * bridge * dummy * ethernet * geneve * loopback * vxlan * wireguard * wireless
2019-12-06T1843: run interface-definitions though GCC preprocessorChristian Poessinger
A lot of XML code is duplicated (VLAN, interface address) for instance. Such XML definitions should be moved to feature.xml.i files and then just pulled in via GCC preprocessor #include definition in e.g. bond or ethernet definitions. This will give us the ability to single-source repeating node definitions as: * Interface Address * Interface Description * Interface Disable * VLAN (both vif-s and vif-c) The .in suffix of the interface-definitions is a marker that those files are input files to the GCC preprocessor. They will be rendered into proper XML files in the build directory. Some node definitions have been reworder to remove escaped double quote occurances which would have been warned about by the GCC preprocessor.