| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
