PR https://github.com/vyos/vyos-1x/pull/2427

I understand (and accept) the risks of running rolling.

In T5681#163634, @JeffWDH wrote:

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

Snippet from vyos-migrate.log:

List of executed migration scripts:
List of executed migration scripts:
List of executed migration scripts:
/opt/vyatta/etc/config-migrate/migrate/cluster/1-to-2
/opt/vyatta/etc/config-migrate/migrate/interfaces/31-to-32
/opt/vyatta/etc/config-migrate/migrate/nat/5-to-6
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat/6-to-7
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat66/1-to-2

After readding them with the new syntax all is good, but it looks like for some reason the migration script didn't run on my system.

PR https://github.com/vyos/vyos-1x/pull/2425

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

Part of those is fixed with telegraf update in T5701

PR: https://github.com/vyos/vyos-1x/pull/2424

PR https://github.com/vyos/vyos-1x/pull/2423

There is a bug when we use lowercase "cisco"

set service pppoe-server authentication radius rate-limit vendor 'cisco'

It doesn't work as vendor is Cisco not cisco

vyos@vyos-lns# sudo cat  /usr/share/accel-ppp/radius/dictionary.cisco | grep -i vendor
VENDOR		Cisco

PR for 1.4 https://github.com/vyos/vyos-build/pull/451

Fix build PR https://github.com/vyos/vyos-build/pull/450

PR https://github.com/vyos/vyos-build/pull/448

PR https://github.com/vyos/vyos-build/pull/445

https://github.com/vyos/vyos-1x/pull/2417

PR for 1.5 which will be backported to 1.4 https://github.com/vyos/vyos-1x/pull/2416

I don't see this fix having been backported to Equuleus.

I'm building 1.4 rolling with the ixgbe out-of-tree driver if anyone cares.

Instead of "deny all" if no allow-clients are configured then localhost is always allowed. Can be handy when using containers and other if needed to sync to localhost for whatever reason (if the use of RTC isnt enough).

This has been implemented in 1.5 and 1.4.

@Apachez this request stems from this issue: https://forum.vyos.io/t/evpn-vxlan-esi-lag-duplicate-packets/12581

Both single-active and all-active should be supported when it comes to EVPN Multihoming.

I believe it's probably generating this error because modem sends an empty hostname.

Logs from just dhclient.

I didn't update it since the initial report and I don't really understand how/why it's working again.