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 2025-10-29T11:22:42+00:00 2025-10-29T11:22:42+00:00 Christian Breunig christian@breunig.cc 2025-10-29T11:12:52+00:00 urn:sha1:c5ef4f4ebf38a249998498ebe443f3cc733b64fd Commit f08a5700e7 ("dhcpv6: T7646: restore missing default route after upgrade") introduced a regression affecting both non-VIF and VIF interfaces. The addressing mode check in the migration logic was incorrect for both cases. For non-VIF interfaces, the migration was skipped entirely due to a missing configuration test. For VIF (VLAN) interfaces, the existing test always evaluated to true, since it incorrectly assumed that DHCPv6 was configured even when a static address was present. Smoketests have been extended to cover for these cases. 2025-09-13T11:16:40+00:00 Christian Breunig christian@breunig.cc 2025-09-13T11:16:40+00:00 urn:sha1:f08a5700e725a2ed4c53320b310167826953215d Commit de44c6aef249 ("interface: T7379: do not request SLAAC default route when only DHCPv6 is set") introduced a behavioral change while addressing an earlier issue fixed in e9fb2078d5ea ("interface: T7375: SLAAC assigned address is not cleared when removing SLAAC"). This change caused unintended connectivity loss after upgrading to VyOS 1.4.3. The underlying reason is that VyOS now requires explicit configuration to determine how IPv6 addressing and routing should be handled, rather than making assumptions: Requesting a DHCPv6 address alone will correctly assign an address. However, since the IPv6 default route is typically advertised via SLAAC (and not DHCPv6), SLAAC must also be explicitly enabled to receive the default route. Historically, this distinction was implicit and did not require additional configuration. To preserve backward compatibility, a configuration migrator has been added. It inspects existing configurations that only request a DHCPv6 address and automatically appends the required CLI node to also enable SLAAC, ensuring that the default route is restored after upgrade. 2025-06-28T21:16:52+00:00 Christian Breunig christian@breunig.cc 2025-06-28T18:51:21+00:00 urn:sha1:1478516ae437f19ebeb7d6ff9b83dd74f8e76758 The legal team says years are not necessary so we can go ahead with it, since it will simplify backporting. Automatically removed using: git ls-files | grep -v libvyosconfig | xargs sed -i -E \ 's/^# Copyright (19|20)[0-9]{2}(-[0-9]{4})? VyOS maintainers.*/# Copyright VyOS maintainers and contributors <maintainers@vyos.io>/g' In addition we will error-out during "make" if someone re-adds a legacy copyright notice 2024-06-26T20:38:41+00:00 John Estabrook jestabro@vyos.io 2024-06-20T01:16:05+00:00 urn:sha1:26740a8d583f64dc0a27b59dd4ae303056972c0b 2024-06-16T07:22:28+00:00 Christian Breunig christian@breunig.cc 2024-06-15T19:40:04+00:00 urn:sha1:9e22ab6b2aee48029d3455f65880e45c558cf1da 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"