VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=fix%2FT8955-http-api-verify-tls 2026-05-28T13:40:57+00:00 2026-05-28T13:40:57+00:00 John Estabrook jestabro@vyos.io 2026-05-28T13:40:57+00:00 urn:sha1:d4bb72161387132475e68c9186419f0384c28b32 T8502: Add exclusion mask to config-sync 2026-05-28T13:31:21+00:00 John Estabrook jestabro@vyos.io 2026-05-04T19:33:07+00:00 urn:sha1:8b2d2a80c0f9272d80ee4d90077978c9e43021b9 2026-05-27T19:42:01+00:00 Christian Breunig christian@breunig.cc 2026-05-27T19:42:01+00:00 urn:sha1:238d835823ee94b2060454e1a270176001d46345 snmp: T8538: Persist engineBoots counter across reboots 2026-05-27T14:04:17+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2026-05-27T13:31:15+00:00 urn:sha1:3b22850f4fe4163fea73f907ba8fe72777ba8d80 When setting 'vpn ipsec logging log-level 0', DPD informational messages (log level 1) were still appearing in the system journal. The root cause is that charon-systemd reads both `charon-systemd.conf` and `charon-logging.conf` and applies the higher of the two log levels to the journal. The VyOS only managed `charon-systemd.conf`, leaving `charon-logging.conf` at its default level of 1, which silently overrode the user-configured level. Fix this by rendering `charon-logging.conf` on every commit with syslog backend set to -1 (silent), making `charon-systemd.conf` the sole authoritative source for journal log verbosity. This also eliminates duplicate log entries in the journal that occurred when both backends were active and writing to the same destination. 2026-05-26T14:47:15+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2026-05-26T14:47:15+00:00 urn:sha1:f333e72b999c296565fc23e79b3bf651dc85afb0 ipsec: T7555: Implement `ikev2-reauth` for site-to-site peers 2026-05-25T06:25:45+00:00 Christian Breunig christian@breunig.cc 2026-05-25T06:25:45+00:00 urn:sha1:dc47f550e908eb4252ab2a30791b851403a3feae T8910: ipoe-server: expose accel-ppp idle-timeout option 2026-05-22T14:50:22+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2026-05-19T09:09:56+00:00 urn:sha1:81e8f14c5b9b322a998e6530184b07e9e9187ff5 Per RFC 3414 section 2.2 (Replay Protection), the `snmpEngineBoots` counter must be stored in non-volatile storage and incremented on every snmpd restart. VyOS was not persisting this value, causing it to reset to 1 after every reboot. SNMP managers cache the engineBoots value from previous sessions. When VyOS resets the counter to 1 after reboot, managers reject incoming SNMPv3 trap packets as "too old", producing errors such as: ``` usm: Message too old. reboot count invalid ``` This change introduces `/config/snmp/engineboots.count` as a disk-backed persist file and it uses to sync the counter into snmpd's conf before the daemon starts. 2026-05-22T10:54:18+00:00 Alex Kudentsov 43482574+alexk37@users.noreply.github.com 2026-05-22T06:50:27+00:00 urn:sha1:ce401c3f099a92c49ee8a0344ac80e113e19883e Add a CLI knob to terminate idle IPoE sessions after a configurable timeout: set service ipoe-server idle-timeout <0-86400> Today there is no way to age out stale IPoE sessions: clients that go silent (powered off, link down) leave a session record on the router indefinitely. accel-ppp natively supports idle-timeout in its [ipoe] section but VyOS did not expose it. The option is added as a shared accel-ppp include so it can be reused by other accel-ppp services in follow-up PRs. 2026-05-21T23:15:49+00:00 Giga Murphy giga1699@gmail.com 2026-05-21T23:15:49+00:00 urn:sha1:81ad0d10ad1df093cb19f715d39696e50f75411a 2026-05-21T15:32:53+00:00 anderbak bjanderson7583@gmail.com 2026-05-04T23:20:30+00:00 urn:sha1:fb26030466d017b1c136da6eb631f2c85fb229aa