Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
VyOS 1.2 confirmed it was a regular node - copy/paste error.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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...
|
|
Commits to
"interfaces wireless wlanX capabilities vht link-adaptation (unsolicited|both)"
always failed.
|
|
|
|
Autoconfigure addresses using Prefix Information in Router Advertisements.
|
|
... to new XML and Python based frontend/backend.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
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
|
|
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.
|