Actually, specifying wireguard peer as a hostname only worked on initial setup. The reason for this is that the hostname is resolved only on initial startup of the wireguard tunnel. On boot the ip stack is not fully operational resulting in wireguard beeing unable to resolve hostnames. (But this avtually could depend of the execution time of the initialization scripts) .. a better alternative to this is to make a initialization script that is delay'd and then resolves the hostname and inserts the correct ip in wireguard when the router is fully booted. This could be created using a custom script called from the post-bootup script or something like that.

I tried this today with 1.3-rolling-202004180117 ...

This change has removed the ability to specify a wireguard endpoint by hostname, rather than IP address. Is there an alternative resolution which maintains this ability?

PR for this task https://github.com/vyos/vyos-1x/pull/354

While testing T1874 the procedure we followed was:

From Slack;

Marek Isalski 09:25
If anybody is using 1.2.4 or earlier for BGP, and wants to do RPKI, I can highly recommend updating to 1.2.5 which fixes this nasty segfault in FRR's bgpd: https://phabricator.vyos.net/T1874 (and devs can probably consider closing T1874 now that we know it's fixed in 1.2.5)

This is looking like it might be fixed in FRR version 7.2.1 onwards:

We managed to reproduce this on a test instance running VyOS 1.2.4 talking RTRR to Routinator3000 0.6.4:

@alainlamar any chance to implement the reset button to clear the config?

The LED assignment could be handled in a generic startup script where the hardware platforms and LEDs will be assigned

Pull request: https://github.com/vyos/vyos-build-kernel/pull/6

Pull request: https://github.com/vyos/vyos-1x/pull/353

We saw something similar to this, but it seems like FRR eventually connected to RTRR. I think it has a timeout parameter — is that how often (slowly) it tries to re-establish?

We had this bug earlier today on 1.2.4.

I have made pull request in https://github.com/vyos/vyos-1x/pull/352, please help to review it.

I have made pull request in github, please help to reviw it: https://github.com/vyos/vyos-cloud-init/pull/8

OpenVPN was migrated to a systemd service with auto restart so it's possible it could have fixed this issue. Please retest with latest rolling.

The recent work on openvpn added net30 as an option for "server topology" and marked it as default in the shell value help so at least users should now know it's the default. Personally I'd like the default topology to be subnet but that would mean adding a migrator script for old users who use net30.
It also rewrote some parts of the ifconfig setting logic. This should be retested if it's still an issue.

So if we wanted to not use compat-names because of T2113 the client node names would need to have spaces, I don't know how the config system would handle this? It could probably take a quoted value as the client node, but I'm not sure the shell completion would handle this - it already has problems autocompleting quoted values (for example if you try tab-completing a description with a space in it, you'll see what I mean). Shell completion would very likely break with quoted node names. A workaround could be to remap underscores in the config client node names to spaces for the actual ccd file names. I don't quote like that option, but the alternative would be to have to fix the shell autocompletion for quoted values (better in the big picture but more complex and time consuming), or not fix T2113.

@Dmitry Looks good.

@Viacheslav can you check?

@trae32566 thanks for reporthing the issue so clearly, fix will be in next rolling release

This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved