This has a simple fix: starlette commit c568b55d set the attribute

Request._form = None

to support use of Request.form() as a context manager. Since we override the Request class for backwards-compatibility support (translation) of form-data requests, we need to check for value, not existence, of the attribute. Adding this fix allows updating FastAPI past 0.91.0.

This has not been seen subsequently. Close unless recurrence.

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

The similar task/bug with address-group T3390 T469 and port-group

confirm, it's working :

PR for 1.4:
https://github.com/vyos/vyos-1x/pull/1911
PR for 1.3:
https://github.com/vyos/vyos-1x/pull/1912

Some related tasks T2557 T4885

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

Thanks Keving: https://vyos.dev/T5009

FYI When I was troubleshooting I used:

In Both version, restarting relay service solved the issue:

I can confirm this behavior, which occurs when changing IP address on listening interface (where dhcp-discover is captured).
Issue present in 1.3.2 .
It's also present in latest vyos-1.4-rolling-202302140317, regardless if old interface syntax is used, or if new upstream-interfces plus listen-interface commands are used.

You can either run both address-families through one tunnel

In T5004#142577, @n.fort wrote:

Can you provide this configuration on both setups:

show config comm | grep relay

# And route to relay server
show ip route <relay_server>

Can you provide this configuration on both setups:

In T4774#142529, @c-po wrote:

Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing

Keys should not be re-used

Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing

@sdev @c-po @Alfa80 Can we look at rolling this back until it works fully, or fixing it so that it allows the above scenario please? Newer versions of 1.4 are unusable for me for a few months due to this. Let me know if I should file a separate bug.

PR for 1.3 which makes the change available for every config subsystem https://github.com/vyos/vyos-1x/pull/1798

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

PR for 1.4: https://github.com/vyos/vyos-1x/pull/1795

accel-ppp doesn't support FQDN for RADIUS https://docs.accel-ppp.org/en/latest/configuration/radius.html#radius
So it is impossible until it is available in the accep-ppp

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

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

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

Similar tasks T2045, T1519

PR https://github.com/vyos/vyatta-cfg-quagga/pull/98

For 1.4 resolved in the https://github.com/vyos/vyos-cloud-init/commit/d385e3655e9eed77397136f5e27325a93719332d
Waiting several days for tests before doing a backport.

PR with fix is here: https://github.com/vyos/vyatta-cfg-firewall/pull/35

@pasik please see https://github.com/vyos/vyatta-cfg-system/pull/191

@marc_s Would you be able to open a PR against 1.3 ?