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

Going to close this task as the PR has been merged into vyos-1x, and documentation has been merged also - https://docs.vyos.io/en/latest/configuration/vpn/openconnect.html#configuring-radius-accounting

Will be fixed in the next rolling release

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

Is it possible to also add some logic to populate boot entries using https://uapi-group.org/specifications/specs/boot_loader_specification/ ? I have been experimenting with systemd-boot, and it's working fine apart from the missing loader files. Those files look something like this:
/usr/lib/live/mount/persistence/loader/entries/1.4-rolling-202210050218-vty.conf

title     "VyOS 1.4-rolling-202210050218 (KVM console)"
version   1.4-rolling-202210050218
options   boot=live quiet rootdelay=5 noautologin net.ifnames=0 biosdevname=0 vyos-union=/boot/1.4-rolling-202210050218 console=tty0
linux     boot/1.4-rolling-202210050218/vmlinuz
initrd    boot/1.4-rolling-202210050218/initrd.img

There will be similar files for serial and USB console.

Proposed fix in - https://github.com/vyos/vyos-build/pull/299

Fixed in commit: https://github.com/vyos/vyos-1x/commit/6eea12512e59cc28f5c2e5ca5ec7e9e7b21731da

Error reporting: PR's
https://github.com/vyos/vyos-1x/pull/1789
https://github.com/vyos/vyos1x-config/pull/12 (merged)
https://github.com/vyos/libvyosconfig/pull/6 (merged)

Backport PR https://github.com/vyos/vyos-cloud-init/pull/60

Fixed in the https://github.com/vyos/vyos-cloud-init/pull/58

Fix for 1.4: https://github.com/vyos/vyos-cloud-init/pull/59
It must be backported to 1.3 now.

If I don't use advertise-all-vni I get an error

This command is only supported under EVPN VRF

Please use

advertise-all-vni

My full bgp config:

Ok I'll re-check with the latest rolling.

r14# show version 
FRRouting 8.4.2 (r14) on Linux(6.1.6-amd64-vyos).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

hmm, very strange.

The Original FRR log
This command is only supported under EVPN VRF

r14# conf t
r14(config)# router bgp 65000
r14(config-router)# address-family l2vpn evpn 
r14(config-router-af)# 
r14(config-router-af)# vni 100
r14(config-router-af-vni)# 
r14(config-router-af-vni)# route-target import 65000:100
This command is only supported under EVPN VRF
r14(config-router-af-vni)#

In testing this I found that ocserv validates its config on startup and using radius accounting without radius authentication fails to validate and the service will not start. As a result i'm not treating OpenConnect accounting as dependant on the radius as the authentication mode.

migration script modified in current; lower task priority to test error reporting from libvyoconfig.

Yeah, in my case as well, NPTv6 is mostly only useful if it it works with a dynamic (from DHCPv6-PD) prefix, since that's how my ISP provides addresses (AFAIK I'd have to pay for a business connection to get a static prefix, though I haven't actually called and asked myself). I'm tempted to play with hacking something together by building from source myself with some tweaks to auto-update the nat rules when it gets a new PD prefix.

I've created a pull request which add support for this, and yes, it does use raw command.
I know that here we want to avoid "raw options" but I think this is one of the most needed feature and I don't see any other way else to do this. Until a better option is found, I think my PR should do just fine.

Tested in a server/client setup:

I can confirm that with VyOS 1.4-rolling-202301250317 the issue is gone.
At least based on my setup and configuration
Thx for fixing quickly

Please test with latest rolling

There is also a service called "pppd-dns.service" that references "/etc/ppp/ip-down.d/0000usepeerdns", this service is enabled by default and fails on new installs.
It should be disabled and optionally, the file removed too.

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

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

@erkin this should not be an issue in practice, I believe: it is true that humps decamelize(None) returns "", however the PR here will reject non dict or list values. In practice, if an op-mode script has no data, it will raise an error, for example, DataUnavailable, or should return, say, {}.