Fix applied in this commit:
https://github.com/vyos/vyatta-cfg-op-pppoe/commit/4330d41fcda30553ca1b3e2588d05eebdd59fc80

ok, that was a test for new statuses
so we can track backport process better

Backport is done already by me

Package now included in VyOS builds - please test

How to build:

$ git clone https://salsa.debian.org/kernel-team/ethtool.git
$ cd ethtool
$ git checkout debian/1%4.19-1
$ dpkg-buildpackage -uc -us -tc -b
$ ls -al ../ethtool_4.19-1_amd64.*
-rw-r--r-- 1 vyos_bld vyos_bld    992 Apr 21 08:32 ../ethtool_4.19-1_amd64.changes
-rw-r--r-- 1 vyos_bld vyos_bld 113986 Apr 21 08:32 ../ethtool_4.19-1_amd64.deb

Using ethtool 4.19 results in:

vyos@vyos# sudo /sbin/ethtool -K eth0 gso off

We use ethtool provided by Debian Jessie (3.16) which is bound to 3.16 Linux Kernel.

Already in 1.2.1

This can not be backported easily to 1.2 (crux) b/c of jumps in the system@ config version string.

Its already in 1.2.1

@c-po please backport this to crux

@c-po can you backport this to crux, please

updated tools to 10.3 that solves the issue

@syncer The only thing I can do it monitoring upstream, which hasn't released a patch for over a year to address that issue.

Feel free to add patches that needs testing.
I will report back my findings with my setup (as previously PMed about)

Working on interface-route. I think the best way is to stip that off as well, so basically interface-route has it's own script, set proto static route, route-map, table and so on too. Less likely to break when something needs top be changed, better code maintenance (at least that's what I hope for) and can be easily extended. Well, will test it out, so far there is a good performance benefit already.

arp - https://vyos.readthedocs.io/en/latest/routing.html#arp

@hagbard @zx2c4 rolling should be ok now
please test and we need to backport this to the crux

@zsdc it's in http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.19.1+vyos2+current8_all.deb, but you better wait until the rolling release is working again, there were some frr dependencies added, which makes the packge not backward compatible. If you need it urgently, I can compile you a working one which works on the older releases (it's really only a dependency issue). So far I have it only implemented for IPv4 routes, let me know if you need it for route6 as well. I planned to start with the backend rewrite for frr asap.

@zsdc would the below help you?

Sorry I can't replicate your issue, tested it with VyOS 1.2.0-rolling+201903110337.

I've finally managed to test this (apologies, we've had a super busy couple of months) and don't appear to be able to connect to the VPN anymore :(

moving 'set protocols static arp' into it's own python script. - done-

@zsdc How quickly needs that to be resolved? It requires quite some work on the backend for the cli.

Since it's not a wireguard issue rather then a network issue between both systems, I'll remove it from 1.2 and put it into 1.3 .

That information is not easily visible, never been according to the openvpn folks.

Do you see now the udp arriving on both sides?