| Age | Commit message (Collapse) | Author |
|---|
|
debian: T9455: drop exfat-fuse in favour of in-kernel exFAT driver
|
|
pseudo-ethernet: T9253: fix anycast-gateway with shared MAC on bridge VLANs
|
|
container: T9401: add chown option to tmpfs mounts
|
|
firewall: T9332: fix GeoIP source/destination nftables set name colli…
|
|
ospf: T9448: do not render metric-type when it is the default
|
|
The VyOS kernel ships the native exFAT driver (CONFIG_EXFAT_FS=m), so the
userspace FUSE implementation is no longer needed. The exfatprogs tools for
creating and checking filesystems are kept.
The kernel options smoketest now verifies CONFIG_EXFAT_FS is enabled.
|
|
T9386: openvpn: reject AEAD fallback cipher with shared-secret-key
|
|
With metric-type 2 (the CLI default), every FRR reload deletes and
re-adds "default-information originate" and every "redistribute" line
under "router ospf". ospfd flushes the Type-5 LSAs on the delete and
re-originates them right after, so neighbours can briefly lose the
external routes on commits that do not touch OSPF.
ospfd and ospf6d (for redistribute) write "metric-type 1" back to the
running config and print nothing for type 2, their default. The
templates render "metric-type 2", so frr-reload sees a different line
on every reload.
frrender now adds the XML default of metric-type to the OSPF and OSPFv3
dicts as xml_default_metric_type, for the default and every VRF
instance. The templates render metric-type only when it differs from
that default, so the generated config matches what FRR prints back.
OSPFv3 default-information keeps rendering metric-type, as ospf6d
prints it for both types.
Add smoketests that read the generated config and vtysh for types 2,
1 and back to 2. Rename the "ptotocol" loop variable in
test_protocols_ospf.py to "protocol", which the typos check flags on
any change to this file.
|
|
Static key mode only supports CBC, so OpenVPN refuses to start with an
AEAD "data-ciphers-fallback" just like with an AEAD "encryption cipher".
Reject it at commit time.
|
|
config-management: T6304: Rewrite commit-archive location into a structured CLI
|
|
interfaces: T9152: Refactor source-validation to use vmaps
|
|
vpp: T9161: Enforce NIC MTU limit and apply MTU to VLAN sub-interfaces
|
|
Several anycast-gateway pseudo-ethernets with the same MAC on different
VLANs of one bridge (the usual EVPN layout) failed to commit with
"bridge fdb add ... File exists". The local FDB entry was always installed
without a VLAN, so every interface competed for the same entry. A failing
commit at boot left only one interface configured and dropped the rest of
the config.
The local FDB entry is now bound to the VLAN of the bridge sub-interface
when the bridge is VLAN aware, and it is installed with replace so a
re-commit over an existing entry no longer fails. Two anycast-gateways
with the same MAC on the same source-interface are rejected.
|
|
On a VPP-bound interface the MTU limit is the NIC's, which only VPP knows
(the kernel side is an LCP tap reporting a meaningless larger max). Reject at
commit an MTU larger than that limit, read from VPP's 'show hardware-interfaces'
(max mtu + driver frame overhead), so the kernel and dataplane cannot silently
end up with different MTUs.
Also apply a VLAN sub-interface's MTU to its VPP dataplane sub-interface and its
linux-cp tap (created with MTU 0), not just the parent; a sub-interface without
its own MTU inherits the parent's. Covers ethernet (vif/vif-s) and VPP
bond/loopback (vif).
|
|
configd: T9368: reconcile FRR after a DHCP lease without the commit socket
|
|
bgp: T9410: add route-map vrf import under ipv6-unicast
|
|
router-advert: T9413: add no-remove-on-exit and no-flush-* options
|
|
On shutdown radvd sends a final RA with router lifetime 0 and announces
its RDNSS and DNSSL entries with lifetime 0. On a VRRP pair that sends
RAs from a shared source address (source-address fe80::1), hosts read
the zero router lifetime as the shared router going away and remove
their default route until the backup's next RA. On my routers that was
1.6 s of IPv6 loss when the master rebooted.
radvd controls this with RemoveAdvOnExit, FlushRDNSS and FlushDNSSL,
all defaulting to on. Expose them per interface:
set service router-advert interface <if> no-remove-on-exit
set service router-advert interface <if> no-flush-name-server
set service router-advert interface <if> no-flush-dnssl
The directives are only rendered when the options are set, so the
generated radvd.conf is unchanged for existing configurations.
|
|
The ipv4-unicast address family has 'route-map vrf import' to filter the
VRF route leak; ipv6-unicast did not, so an IPv6 leak could not be
filtered. The template is already AFI-generic: only the CLI node was
missing.
|
|
openvpn: T9370: add chacha20poly1305 data cipher
|
|
Two IPv6 tests waited for a global address as their synchronisation point,
although neither of them is about one. A global address only shows up once the
peer answers a router solicitation, which is best effort, so both tests failed
intermittently whenever a run was slow.
The link-local test now waits for the address it actually asserts on, and
forces the established session to be reconfigured within a commit before it
looks. Waiting for the link-local alone would race the code it guards, as the
peer assigns that address before VyOS configures the link. The autoconf test
proves the session negotiated IPv6 before asserting that no global address
exists.
Autoconfiguration itself is covered by a test of its own, with a timeout of its
own, so a slow peer no longer fails tests which do not depend on it.
|
|
A PPPoE session is restarted from within the commit that changes it and comes
back up milliseconds later, while that commit is still running. The hook which
then configures the interface reads the running configuration, which until the
commit finishes is still the one from before it. Everything the commit adds is
missing at that point: for an interface newly set to IPv6 autoconf the hook
disabled router advertisements and autoconfiguration on the link, and nothing
turned them back on. The link kept its link-local address and never received a
global one, until the next commit or reconnect.
Which interface is hit varies with the order the commit happens to process
them, so this surfaced as an intermittent failure.
The hook now waits for the commit to finish before reading the configuration.
|
|
Reconciling the FRR configuration after a DHCP lease event was requested from
the configuration daemon over the socket the commit pipeline uses. The daemon
serves one client at a time and assumes it is the running commit, so
the request either landed in the middle of the handshake which hands over the
configuration, or kept the daemon busy past the 10ms a commit waits for it.
Either way the commit fell back to running the conf-mode scripts directly.
Those never render FRR, only the daemon does, so the commit succeeded while FRR
kept the configuration rendered before it, until the next lease event.
A lease event now renders FRR in its own process, and a commit which could not
use the daemon renders FRR itself instead of skipping the reload. Both take the
same lock. A commit post-hook would remove the second case, for a full render
on every commit.
|
|
bgp: T9407: do not render "bgp reject-as-sets" when it is the FRR default
|
|
Since FRR 10.5 "bgp reject-as-sets" is the default. FRR does not print
the default in show running-config, so frr-reload never finds the line in
the running config and sends it again on every reload. The command
handler resets every BGP session of the instance (NOTIFICATION Cease,
other configuration change) whether or not the value changed,
so with "protocols bgp parameters reject-as-sets" set, every commit that
reloads FRR reset every established session, not only commits that touch
BGP.
Render only the non-default form: "no bgp reject-as-sets" when the
option is not set, as T7664 added it, and nothing when it is set. The
option is a valueless leaf, so it has no XML default to read; the
rendered "no" form already was the only place that knows what FRR's
default is. Changing the option still reaches FRR: frr-reload sends
"bgp reject-as-sets" when the option is set (the "no" line leaves the
rendered config) and "no bgp reject-as-sets" when it is deleted, and
each change resets the sessions once, as before.
Add a smoketest that reads the rendered /run/frr/config/vyos.frr.conf,
because FRR never prints the default form and vtysh cannot show it.
|
|
bgp: T9404: do not render "bgp default local-preference" when the value is 100
|
|
T9351: Accel-PPP-NG: Add CLI support for Message Authenticator attribute in Access packets (Blast-RADIUS mitigation)
|
|
Replace the free-form 'commit-archive location <url>' leafNode with a
structured, per-destination tagNode:
`set system config-management commit-archive location <name> <protocol> \
authentication { username | password } | server | port | path`
Each location selects exactly one transport protocol (scp, sftp, ssh, ftp,
ftps, http, https, git, tftp). 'git' additionally accepts a 'transport'
(https/http/ssh, default https). 'source-address' and 'vrf' stay under
'commit-archive' and apply to every location, as before.
|
|
FRR does not print "bgp default local-preference 100" in show
running-config because 100 is its default, so frr-reload never finds the
line in the running config and sends it again on every reload. The
command handler calls bgp_clear_star_soft_in() whether or not the value
changed, so every reload ran "clear bgp * soft in" (once in pass 0 and
twice in pass 1), a full inbound re-evaluation of every peer.
Add the default (100) to the XML definition of parameters default
local-pref. Templates cannot query the XML definition while rendering,
so frrender takes the value from the config defaults of "parameters
default" (conf.get_config_defaults) and adds it to the BGP dict as the
key xml_default_local_pref, for the global instance and for every VRF
instance. bgpd.frr.j2 renders the line only when the configured value
differs from xml_default_local_pref, so the value 100 is not hardcoded
in the template. A real value change (100 to 200, or 200 to 100) is
still sent: frr-reload sees the difference between the rendered file and
the running config.
|
|
agents: T9348: update content in AGENTS.md to improve AI generated changes
|
|
op-mode: T861: add "show secure-boot detail" command
|
|
Since T9024 (Podman 5.8.4, crun replaced by runc 1.1.5), a tmpfs mounted
over a directory that already exists in the image is owned by root:root
0755, whatever the image prepared. A container running as a non-root
user (image USER or uid/gid) can no longer write its pid file or control
socket there and fails to start. With crun 1.8.1 every tmpfs was 1777,
so the same configuration used to work.
runc 1.1.5 ignores tmpfs-mode; the Podman mount option `U` (chown the
mount to the container user) is the only one that works on the runtime
VyOS ships. Expose it as a valueless `chown` node:
set container name <name> tmpfs <tag> chown
Without the option the generated Quadlet line is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
|
"show secure-boot" only reported whether Secure Boot is enabled, not who
signed the running Linux Kernel. An image signed by the VyOS CA could not be
told apart from one signed with a custom Machine Owner Key.
"show secure-boot detail" now lists issuer and subject of the Kernel image
signature certificates. The same information is added to the raw
"show version" data as "secure_boot_detail", issuer and subject delimited by
",". The key is only present when Secure Boot is enabled and a signature
could be read.
|
|
config-mgmt: T9399: read the committed config once in the post-commit hooks
|
|
frrender: T9377: do not save the FRR configuration a second time
|
|
pppoe: T9395: render default routes via FRR only
|
|
webproxy: T9371: fix typo in the squidGuard local-block-url rule ACL
|
|
01vyos-commit-revision built a full Config() in ConfigMgmt() (active and
working config, the working one read through the session's unionfs-fuse)
and then ran vyos-save-config.py, which built a second full Config() to
write the same active config out. On a config with a 2,000-entry
prefix-list the hook took 17 s of every commit.
The hooks run after the active config has been written, so read it once
from the active store, and write the archive copy and config.json from the
tree already held. The read is made as ConfigSourceSession makes it
(stdout only, unmodified), and as there, no running config is passed
until the boot configuration is complete, so the boot commit's hooks see
no effective values and 02vyos-commit-archive uploads nothing at boot.
After a commit that does not end in COMMIT_STATUS=SUCCESS (PARTIAL in
the tests; a conf_mode script failure gives PARTIAL, and FAILURE takes
the same branch) the hooks read the config the stock way (a full Config()
of the working config); only the archive copy is still written from that
tree in-process instead of by vyos-save-config.py.
vyatta-cfg's discard removes the session's changes underneath the
unionfs-fuse mount, and a set within about a second of it fails while the
kernel still caches the removed directories; the stock hook takes longer
than that and so hides it. A faster hook after a failed commit made
smoketest test_bgp_27_route_reflector_client fail; on stock it fails the
same way with 01vyos-commit-revision removed.
confirm and initialize_revision use the same archive helper, so they also
write the archive copy from the tree already held instead of starting
vyos-save-config.py.
|
|
The IPv6 autoconf test failed intermittently. It rejected the link-local
address IPV6CP still negotiates without a BRAS IPv6 pool, and on failure left
the pool deleted, breaking the next test. It now only checks for global
addresses and always restores the pool.
|
|
Deleting a PPPoE interface shortly after its session came up could fail the
commit with "% could not lock candidate DS". The default routes were installed
via vtysh both from the commit and from the asynchronous ppp ip-up hook, so the
two FRR sessions raced for the mgmtd lock. The IPv6 default route was also
missing from the rendered FRR configuration, so an FRR reload could remove it.
Both default routes are now part of the rendered FRR configuration, which
vyos-configd applies at the end of every commit. PPPoE no longer calls vtysh.
|
|
policy: T9379: prefix-list duplicate check in linear time
|
|
T9365: add bindings for reference tree path from config path util
|
|
|
|
|
|
|
|
|
|
T9341: Fix consistency of legacy templates, xml_ref cache, and reference tree
|
|
verify() looked up each prefix-list rule in a list of the rules seen
so far, which is quadratic in the size of the list and runs on every
policy commit. verify() alone, run from the source on a workstation,
took 41.8 s for a 40,000-rule list; on a 1.5.1 VM the check cost 0.08 s
at 2,000 rules.
Keep a set of the rules' sorted items instead. Every value under a
prefix-list rule is a single leaf, so the key is hashable, and two keys
are equal exactly when the rule dicts are: the same rules are flagged,
with the same message. The workstation benchmark took 0.11 s.
|
|
apply() runs frr-reload.py --reload without --daemon, and in that mode
frr-reload.py saves the configuration itself (vtysh "write" to
/etc/frr/frr.conf, bind-mounted from /run/frr/config/frr.conf). The
following vtysh -n --writeconfig, added by T3217 when VyOS still reloaded
one daemon at a time with --daemon, writes the same file again and asks
every daemon for its configuration once more.
That second round trip comes several seconds after the change was
applied. On a large FRR configuration it reaches bgpd after the route-map
update timer (5 s) has started a policy walk, and the commit then waits
until the walk ends: on a 20,000-line FRR configuration with 100 update
groups and 500,000 routes a policy commit took 497.9/501.0 s against
381.1/381.6 s without this second save.
|
|
Offer chacha20poly1305 in "encryption data-ciphers" and
"encryption data-ciphers-fallback", rendered as CHACHA20-POLY1305 and
allowed with DCO.
|
