| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Validate if the migrators performed correctly by comparing it to a known good
result file containing all the required `set` commands
|
|
Wireless devices are subject to regulations issued by authorities. For any
given AP or router, there will most likely be no case where one wireless NIC is
located in one country and another wireless NIC in the same device is located
in another country, resulting in different regulatory domains to apply to the
same box.
Currently, wireless regulatory domains in VyOS need to be configured per-NIC:
set interfaces wireless wlan0 country-code us
This leads to several side-effects:
* When operating multiple WiFi NICs, they all can have different regulatory
domains configured which might offend legislation.
* Some NICs need additional entries to /etc/modprobe.d/cfg80211.conf to apply
regulatory domain settings, such as: "options cfg80211 ieee80211_regdom=US"
This is true for the Compex WLE600VX. This setting cannot be done
per-interface.
Migrate the first found wireless module country-code from the wireless
interface CLI to: "system wireless country-code"
|
|
|
|
|
|
>=5.0
random - In kernel 5.0 and newer this is the same as fully-random. In earlier
kernels the port mapping will be randomized using a seeded MD5 hash mix using
source and destination address and destination port.
https://git.netfilter.org/nftables/commit/?id=fbe27464dee4588d906492749251454
|
|
|
|
Containers have the ability to add Linux system capabilities to them, this is
done using the "set container name <name> cap-add" command.
The CLI node sounds off and rather should be "set container name <name>
capability" instead as we use and pass a capability to a container and not
add/invent new ones.
|
|
mac node
The problem was introduced in [1] but the config migrator part unfortunately
was added to the wrong version [2]. As IPoE config version 0 was only active
during the 1.3 development cycle and VyOS 1.3.0 was already released with config
version 1 we can safely drop the migrator 0-to-1 and move the code to 1-to-2 to
properly support upgrades from VyOS 1.3 -> 1.4 or newer.
1: https://github.com/vyos/vyos-1x/commit/05df2a5f021f0c7aab7c06db645d210858b6e98d#diff-08291bf77870abe3af8bbe3e8ce4bbf344fd0498b2c5c75a75aa7235d381c88eL168
2: https://github.com/vyos/vyos-1x/commit/05df2a5f021f0c7aab7c06db645d210858b6e98d#diff-b8bb58b75607d3653e74d82eff02442f9f3ab82698f160ba37858f7cdf6c79ccR44-R46
|
|
The option "passive-interface default" was set even if it was not present in
the previous version we are migrating from. Fix migration script to handle this
with a conditional path.
|
|
|
|
|
|
|
|
T6001: add option to disable next-hop-tracking resolve-via-default
|
|
EDB should be EGP for exterior gateway protocol
|
|
dhcpv6-server: T5993: Extend interface migrator to check VLAN/QinQ
|
|
|
|
Updates smoketest config to test migrator change
|
|
|
|
|
|
bgp: T5937: fix migration script for IPv6 AFI peer-group
|
|
Migrate "bgp <ASN> neighbor <NEIGH> address-family ipv6-unicast peer-group"
to "bgp neighbor <NEIGH> peer-group"
|
|
|
|
this test
|
|
* Also migrate `address-range` to `range` tag node for consistency with dhcpv4 server syntax
|
|
We have not seen the adoption of the https virtual-host CLI option.
What it did?
* Create multiple webservers each listening on a different IP/port
(but in the same VRF)
* All webservers shared one common document root
* All webservers shared the same SSL certificates
* All webservers could have had individual allow-client configurations
* API could be enabled for a particular virtual-host but was always enabled on
the default host
This configuration tried to provide a full webserver via the CLI but VyOS is a
router and the Webserver is there for an API or to serve files for a local-ui.
Changes
Remove support for virtual-hosts as it's an incomplete and thus mostly useless
"thing". Migrate all allow-client statements to one top-level allow statement.
|
|
|
|
|
|
dhcp: T3316: Migrate dhcp/dhcpv6 server to Kea
|
|
(cherry picked from commit 1f304a5b3b3698e11f3a497ca9c61b69ef94b26b)
|
|
|
|
This complements commit f5e43b136 ("http: T5762: api: make API socket backend
communication the one and only default") so we have a consistent port CLI node
across VyOS components.
|
|
Why: Smoketests fail as they can not establish IPv6 connection to uvicorn
backend server.
https://github.com/vyos/vyos-1x/pull/2481 added a bunch of new smoketests.
While debugging those failing, it was uncovered, that uvicorn only listens on
IPv4 connections
vyos@vyos# netstat -tulnp | grep 8080
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN -
As the CLI already has an option to move the API communication from an IP to a
UNIX domain socket, the best idea is to make this the default way of
communication, as we never directly talk to the API server but rather use the
NGINX reverse proxy.
|
|
IGMP and PIM are two different but related things.
FRR has both combined in pimd. As we use get_config_dict() and FRR reload it
is better to have both centrally stored under the same CLI node (as FRR does,
too) to just "fire and forget" the commit to the daemon.
"set protocols igmp interface eth1" -> "set protocols pim interface eth1 igmp"
|
|
vxlan: T5671: change port to IANA assigned default port
|
|
|
|
Currently VyOS VXLAN implementation uses the Linux assigned port 8472 that
predates the IANA assignment. As Most other vendors use the IANA assigned port,
follow this guideline and use the new default port 4789.
Existing configuration not defining an explicit port number will be migrated
to the old default port number of 8472, keeping existing configurations work!
|
|
add IPv6 support and firewall groups
|
|
|
|
|
|
|
|
|
|
Commit 0a802d20c - ("smoketest: add config with VRF BGP instance") added a
config from a VMware VM. When moving to QEmu we must reduce the network card
ring-bufer size from 4096 -> 256, as the tests failed with:
> Driver only supports a maximum RX ring-buffer size of "256" bytes!
|
|
Replica of a real network. BGP is realised inside a VRF. The BGP peering to the
outside world is done via WireGuard that is backed by a PPPoE link - shiver!
|
|
|
|
tc acccepts the bandwidth value/unit pairs as lowercase - so does the VyOS CLI
validator work, too.
|
|
|
|
|
|
|
|
qos config migration is tested using qos-basic example config file.
|
