As both PRs have been merged now, I'm resolving this issue.

Ok. I just found out, that I had an error, when porting my changes to github.

I hope I can find some time tomorrow to also test with crux. My current build job only builds the 1.3.x branch, but should be easy to adjust.

I think I found the issue. Please see https://github.com/vyos/vyos-build/pull/207/

Update: If I run

@sever To me it seems it's not even present in the iso and according to the dpkg logs it seems to install vyos-xe-version.

@sever I think you implemented that feature. Am I using it wrong?

Wireguard has its own fwmark setting, such as:

Thanks for the info. I think (indeed) that *might* work for wireguard. But never the less, it would be cool to have the possibility to route by fwmark.

@c-po Thank you for clarifying. I guess I misinterpreted what i read on patchwork. I'd be eager to test a kernel with the patch!

Also happens with 4.19.131-amd64-vyos - I guess that patch mentioned by @Viacheslav is either not included or not solving the problem.

With 4.19.123-amd64-vyos I am having the same problems. I would assume, that the patch from 2016 is already in this kernel?

Thanks for picking up this task. I think it is a duplicate of T2505.

Does anyone have some idea on how to test with different kernels? For now this is a deal breaker while using the 1.3.x branch. Tho I would really love to keep using bleeding edge in order to help testing things :-)

I replaced the distributed guest utilities (vyos-xe-guest-utilities) with the ones that come with xcp-ng. But this changed nothing regarding the packet loss. Tho, now they get properly recognized by xcp-ng :-)

@Sonicbx @jjakob I also created https://phabricator.vyos.net/T2504 - I think we duplicated the issue here. You can close whichever issue you want.

@jestabro Sorry for the delay, I did not find a proper maintenance window... Today I verified the fix and it seems to work. My automation scripts run through just fine, without the error.

In T2474#64078, @c-po wrote:

@fetzerms thanks for getting back to us - I also successfully tested it.

I guess there is always room for improvement in the documentation. Maybe you want to contribute a fix for the missleading parts?

I was able to build 1.2.5 iso (but there is no git tag for it?) with the docker container. I just misunderstood the documentation and thought that the vyos-build-repo is only the repo for the docker image. But it seems the docker image is just from the docker file and the repository needs to be cloned anyways.

In T2474#63995, @jestabro wrote:

You want to fetch the repo before building; cf. the 'Generating the container section':

git clone -b crux --single-branch https://github.com/vyos/vyos-build

@jestabro I installed new rolling images today and will verify tomorrow.

Isn't the image published on DockerHub supposed to be equal to building it manually?

I can try on four nodes with a recent rolling release in the next few days. I just need to find some proper maintenance window.

I think I can pinpoint it down to the mesh generation using wireguard. Please see the logs of two failed nodes attached. I dont find older rotations of the log file. Thats all I have.

Does this get cleared on each reboot? Because I usually rebooted after it "locked".

The code is now merged. Can somebody update this task?

Having this feature would eliminate any use of vyatta-postconfig-bootup.script for me, which would lead to a "clean" vyos installation again.

I am not sure, if I should update here or at github. I did some tests and fixes with my PR. Now generate and show seem to work fine.

I created a pull request for those features: https://github.com/vyos/vyos-1x/pull/238
It is still work in progress, as I was not able to test it (yet).

Is there any chance to get this feature back into 1.2.x? I could heavily use this for management traffic and for pinning tunnels to specific interfaces.