| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Other interfaces were previously migrated, but this one was forgotten,
causing a commit error:
File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 621,
in verify
verify_vlan_config(wifi)
File "/usr/lib/python3/dist-packages/vyos/ifconfig_vlan.py", line 155,
in verify_vlan_config
for vif in config['vif'].values():
AttributeError: 'list' object has no attribute 'values'
|
|
- make error output more user friendly
- replace .format with f-strings
- split into lines less than ~80 characters long
|
|
Previously, set_vrf was always called, which uses the same master and nomaster
commands as bridge, so it removed the interface from the bridge.
- add checks to make VRF and bridge membership mutually exclusive
|
|
Bridge members should not have any addresses assigned.
|
|
|
|
- rewrite the function to support both bridge and bonding interface types,
if the type is passed it searches only that type, otherwise it searches
both
- move is_member check out of the deleted condition
- move is_member check to intf_from_dict for interfaces that use it
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Commit c0629296bb ("wireless: T2185: migrate from SysVinit to systemd") remove
a required argument to get_conf_file()
|
|
convert all call to jinja to use template.render
|
|
|
|
|
|
The typos cause the configurator to throw an exception when a wireless VLAN is specified:
Traceback (most recent call last):
File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 1463, in <module>
apply(c)
File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 1433, in apply
vlan = e.add_vlan(vif['id'])
NameError: name 'e' is not defined
|
|
Use WiFi modes ieee80211ac and ieee80211n if VHT capabilities are optional.
ieee80211n = 1
ieee80211ac = 1
Use only ieee80211ac if VHT capabilities are required (ieee80211n=0).
ieee80211ac = 1
ieee80211n = 0
require_vht = 1
In order to make this decision, the desired WiFi operation mode needs to be
known. Therefore, we must require users to set the WiFi mode.
mode = (a|b|g|n|ac)
|
|
Break the code between v4 and v6, remove need for getter/setter
as they are just exposing the underlying dict.
Move FixedDict from tunnel code and expose it to other part so
it can be used to prevent accidental change to the dhcp option if
no default exists already.
|
|
... to make it clear also directories can be chown(-ed)
|
|
Commit fcce471 ("bridge: T2232: prevent deletion of enslaved interfaces")
added a regression by referencing a wrong variable name.
|
|
Interfaces enslaved to a bridge are not allowed to be deleted. If an interface
is deleted from the config but it is still enslaved to a bridge will cause a
configuration error on the subsequent boot.
|
|
cmd is not used as with not wireless adaptor wireless testing
fails
|
|
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...
|
|
Commit 3d978249b313 ("wireless: T1627: move Jinja2 templates to data/templates
folder") remove a wildcard import statement which is required for MAC address
modification for the AP.
|
|
Commit 3d978249b313c ("wireless: T1627: move Jinja2 templates to data/templates
folder") made use of a new library function (chown_file) from vyos.util,
unfortunately the required import was somehow not added into the patch.
|
|
|
|
wireless: T2211: bugfix: vht_oper_chwidth was not set in hostapd config
|
|
When any defaults are set, VHT capabilities are automatically assumed
for all WiFi modes which does not match the reality. Therefore we must
leave this undefined by default.
|
|
When operating in certain modes, channel width must be configured for
WiFi interfaces. The hostapd config does this in two separate lines
which must both be configured:
vht_oper_chwidth=(0|1|2|3)
vht_capab+=[VHT160] for 160MHz in one block or
vht_capab+=[VHT160-80PLUS80] for 160MHz as 2x 80MHz in two separate
blocks.
|
|
Commits to
"interfaces wireless wlanX capabilities vht link-adaptation (unsolicited|both)"
always failed.
|
|
A user reported a PHY that provides two consecutive MAC addresses, this case has
been added as I was not aware of such cards. As we manipulate the MAC address
anyways its safe to take only the first one.
|
|
OpenVPN, WIFI, SSTP all had the same boiler plate copied about checking if a
process associated with a pidfile is running or not. This has been migrated to
the common library function vyos.util.process_running().
|
|
set_mac is validating the mac address passed, therefore passing
empty string will cause it to fail. if the hardware id could
not be found then it should not be attempted to be set
|
|
|
|
Autoconfigure addresses using Prefix Information in Router Advertisements.
|
|
|
|
... to new XML and Python based frontend/backend.
|
|
ifconfig: T2057: explicity name state functions
|
|
The Interface get_state/set_state were not clear about
if they edited the admin or operational state.
functions are now using admin_state and oper_state
for clarity.
|
|
It is not sufficient to only place a wifi interface in adminsitrative down
state as hostapd could change the interface state again. If the wifi interface
is administratively disabled, hostapd or wpa_supplicant should not be started
at all to prevent anyone from messing arround with the admin state.
|
|
|
|
|
|
tunnel: T31: fix vrf deletion, add support for vrf on tunnels
|
|
|
|
Calculation of the locally administered MAC address should only be performed
when the interface is not deleted.
|
|
|
|
According to http://wiki.stocksy.co.uk/wiki/Multiple_SSIDs_with_hostapd every
SSID served by access-point should run on its own, locally administered MAC
address. Take the phy's interface MAC address as base and calculate a per
interface locally administered MAC address.
|
