| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It makes less to zero sense to blend in the default values of an interface when
it is about to be deleted from the system anyways - this makes the entire dict
just cleaner and easier to debug.
|
|
|
|
|
|
|
|
It seems not all systems have eth0 - get a list of all available Ethernet
interfaces on the system (without VLAN subinterfaces) and then take the
first one.
|
|
Different types of tunnels have different keys set in get_interface_config().
Thus it should be properly verified (by e.g. using dict_search()) that the key
in question esits to not raise KeyError.
|
|
|
|
|
|
|
|
Add support for OpenVPN client mode with only the CA certificate of the server
installed.
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 30cf3bc79e2253a004fcbbf76c9f99c52e7bc216)
|
|
|
|
container: T3881: Change description for container option "restart"
|
|
|
|
|
|
* rename: "show log dhcp" will become "show log dhcp server"
* add: "show log dhcp client" to display logs from ALL DHCP client processes
* add: "show log dhcp client interface <name>" to display logs from individual
DHCP client processes
* add: "show log dhcpv6 server" to display infos about running DHCPv6 server
* add: "show log dhcpv6 client" to display logs from ALL DHCPv6 client processes
* add: "show log dhcpv6 client interface <name>" to display logs from individual
DHCPv6 client processes
(cherry picked from commit ffd73958e42c20f69ded64393491966e0c9230c6)
|
|
(cherry picked from commit 3b2523b816556aa911459097c2476a2da4542151)
|
|
This reverts commit 6b48900358ce9b01eaa78e3a086e95a26064f0df.
|
|
Custom OpenVPN options moved back to the command line from a
configuration file. This should keep full compatibility with the
`crux` branch, and allows to avoid mistakes with parsing options
that contain `--` in the middle.
The only smart part of this - handling a `push` option. Because
of internal changes in OpenVPN, previously it did not require an
argument in the double-quotes, but after version update in
`equuleus` and `sagitta` old syntax became invalid. So, all the
`push` options are processed to add quotes. The solution is still
not complete, because if a single config line contains `push` with
other options, it will not work, but it is better than nothing.
|
|
We can not pass None as VRF name, this raises an exception.
OSError: [Errno 255] failed to run command: ip link set dev eth2 master None
(cherry picked from commit e687502b1cf4a3e15c562a3662afcbe0776b1fe7)
|
|
(cherry picked from commit 8e6c48563d1612916bd7fcc665d70bfa77ec5667)
|
|
(cherry picked from commit eab6e6830a566af647d7e1b24197bf945788c3d0)
|
|
|
|
Instead of throwing an exception when an adapters autoneg capabilities can not
be detected, just pretend it does not support autoneg.
|
|
T3869: Rewrite vyatta_net_name/vyatta_interface_rescan in Python
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is no need to delete the old ingres-qos and egres-qos values as it's not
a multi node and thus the values are simply overwritten. Also address validation
is not required as it's done in a dedicates test.
|
|
|
|
Some OpenVPN clients doesnt support option gateway and metric.
Set metric option only when 'metric' was added in config
explicity.
(cherry picked from commit 96681d8bf1ede069b573a4cbe3a2493c374d048e)
|
|
nat66: T3853: Change priority to 500
|
|
Service ndppd should start after tunnels.
|
|
The group CLI node takes a multicast IPv4 or IPv6 address - this must be input
validated to not case any OS exception
cpo@LR1.wue3# show interfaces vxlan
vxlan vxlan0 {
+ group 254.0.0.1
source-address 172.18.254.201
+ source-interface dum0
vni 10
}
Results in OSError beeing rasied with the following context:
Error: argument "254.0.0.1" is wrong: invalid group address
|
|
|
|
|
|
This extends commit 6f87d8c910 ("ospf: T3757: support to configure area at an
interface level") with a completion helper to show which Area ID is already in
use when configuring the area for an interface.
|
|
Commit 081e23996f (vyos.ifconfig: get_mac_synthetic() must generate a stable
"MAC") calculated a "stable" synthetic MAC address per the interface based on
UUID and the interface name. The problem is that this calculation is too stable
when run on multiple instances of VyOS on different hosts/hypervisors.
Having R1 and R2 setup a connection both via "tun10" interface will become the
same "synthetic" MAC address manifesting in the same link-local IPv6 address.
This e.g. breaks OSPFv3 badly as both neighbors communicate using the same
link-local address.
As workaround one can:
set interfaces tunnel tun1337 address 'fe80::1:1337/64'
set interfaces tunnel tun1337 ipv6 address no-default-link-local
This commit changes the way in how the synthetic MAC address is generated. It's
based on the first 48 bits of a sha256 sum build from a CPU ID retrieved via
DMI, the MAC address of eth0 and the interface name as used before. This should
add enough entropy to get a stable pseudo MAC address.
|
|
|
|
|
