| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
A physical (phy) interface is mandatory for WiFi to work.
|
|
|
|
|
|
|
|
|
|
With commit d61cab4 ("vrf: T31: enable vrf support for wireless interface") an
unknown variable has been referenced.
|
|
|
|
|
|
|
|
|
|
os.environ['VYOS_TAGNODE_VALUE']
This has been only a theoretical problem but then the error condition was
triggered - only an error has been printed instead of raising an Exception.
|
|
|
|
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.
|
|
instead of providing three copies of the same method in bonding, ethernet and
wireless, make a common function in vyos.ifconfig_vlan.apply_vlan_config().
|
|
Tested using:
-------------
set interfaces wireless wlan0 address 'dhcp'
set interfaces wireless wlan0 channel '0'
set interfaces wireless wlan0 description '1'
set interfaces wireless wlan0 physical-device 'phy0'
set interfaces wireless wlan0 security wpa passphrase '12345678'
set interfaces wireless wlan0 ssid 'VyOS-TEST'
set interfaces wireless wlan0 type 'station'
|
|
|
|
Adopt RADIUS configuration and harmonize it with the rest of VyOS. Move the
following configuration block:
security {
wpa {
cipher CCMP
mode wpa2
radius-server 172.16.100.10 {
port 1812
secret secretkey
}
radius-server 172.16.100.11 {
port 1812
secret secretkey
}
}
}
to the harmonized version of:
security {
wpa {
cipher CCMP
mode wpa2
radius {
server 172.16.100.10 {
port 1812
secret secretkey
}
server 172.16.100.11 {
port 1812
secret secretkey
}
}
}
}
And add the new "set interfaces wireless wlan0 security wpa radius
source-address" CLI command to specify the origin of any RADIUS query on
systems having multiple IP addresses.
|
|
|
|
If no capabilities are configured on the CLI - there should also be no ht_capab
or vht_capab entry in the resulting hostapd.conf
|
|
Working:
- Wireless modes b, g, n, ac
- WPA/WPA2 psk and RADIUS (tested using Microsoft NPS)
|
