It let you know ufo could not be changed, but your interface will work :-)

Yes, it is as you have as file in /tmp/vyos.interface.debug' which turns on this debugging :-)

the Problem comes with the connect-on-demand option. As the default route setup was changed some days ago by me to support PPPoE for VRFs this introduced a regression (T2219).

@c-po Shure, config attached to task https://phabricator.vyos.net/T1315 (left-r1, left-r2, right-r1, right-r2)
Section "Autostart commands"

The time-out issue is resolved in T2252; other issues as summarized above.

Is this normal?

vyos@rt-home# set interfaces ethernet eth4 vif 20
[edit]
vyos@rt-home# commit
[ interfaces ethernet eth4 ]
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gro off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 sg off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 tso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 ufo off'
DEBUG/ifconfig returned:
Cannot change udp-fragmentation-offload

T2199 for the firewall rewrite - free for the taking. I wouldn't stray much from the old code logic, as some things have hidden meanings. Especially leaving checks out could introduce bugs unless you're absolutely sure they can be bypassed.

There was a new upstream release 1.4.6 7 days ago, but that shouldn't make it to debian stable (buster). Only the patch done by elbandi via PR could get released as 1.4.5-3, but it hasn't been yet. We could make a backport of 1.4.6 into buster-backports and add a custom apt pin for the package. (I'd rather not go the backport route, as that means the backporter needs to always update the upload for security fixes, rather I'd add all patches for bugs into 1.4.5 for buster and ask for a new buster release).

https://github.com/vyos/vyos-build/pull/99

Please find below, with some comments redacted.

I can't reproduce it with the code in the rolling image that will be available by tomorrow.

Can you please share your configuration on the pppoe interface with us?

The only major differences I've noticed are the kernel versions:

Re-assigning to @Dmitry after checking with him as he's more experienced here.

Where do I get the local address from? Can you share your complete config? Maybe we need source-address or something similar in CLI.

Yes - there are some parts which make use of this bad practice (mostly introduced by me), cleanup required.

There is an issue with storing the state of the interface and then applying it in bulk. For some interface we want to admin it down before performing change and then bringing it back up.
If we store this then only the change and the up command will be applied, this is not going to work.

@cpo should another task be created to make sure we exclude the interfaces themself from source-interface (s) ?

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

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