https://serversideup.net/generating-wireguard-qr-codes-for-fast-mobile-deployments/

@trystan Can you re-check it ?

Do we need "awscli" for it?

It was a broken image.

equuleus: https://github.com/vyos/vyos-1x/pull/788

bug fix PR: https://github.com/vyos/vyos-1x/pull/787

I put in a PR for this:

T3333

Everything looks fine on a 1.3 ISO I just built from source:

Something's wrong with the filesystem; symlinks have been replaced by directories at the root:

Actually there is nothing that stops us from adding rules to netfilter referencing an interface that doesn't exist yet so this could be done at the time of interface and VRRP configuration rather than dynamically.

The problem with "ip" path

It gets DHCP address and removes it

Possible reason https://phabricator.vyos.net/rVYOSONEXff6afe62e801e570f6478decf2b4a813a5c0ee94
Need to check. T3300 T3392

PR for saving configurations to /run/frr/{daemon}.conf
https://github.com/vyos/vyos-1x/pull/784

In T3350#90321, @Viacheslav wrote:

Another solution it include "user" defined file for options
An example CLI

set interfaces openvpn vtun10 openvpn-option-include '/config/openvpn/included.conf'

diff --git a/data/templates/openvpn/server.conf.tmpl b/data/templates/openvpn/server.conf.tmpl
index 79288e40..bcc88c09 100644
--- a/data/templates/openvpn/server.conf.tmpl
+++ b/data/templates/openvpn/server.conf.tmpl
@@ -288,3 +288,8 @@ compat-names
 {%     endfor %}
 {%   endfor %}
 {% endif %}
+
+# Include file for configuration options
+{% if openvpn_option_include is defined and openvpn_option_include is not none %}
+config {{ openvpn_option_include }}
+{% endif %}
diff --git a/interface-definitions/interfaces-openvpn.xml.in b/interface-definitions/interfaces-openvpn.xml.in
index effbdd67..2cba59af 100644
--- a/interface-definitions/interfaces-openvpn.xml.in
+++ b/interface-definitions/interfaces-openvpn.xml.in
@@ -314,6 +314,14 @@
               <multi/>
             </properties>
           </leafNode>
+          <leafNode name="openvpn-option-include">
+            <properties>
+              <help>Additional OpenVPN file configuration. You must
+                use the syntax of openvpn.conf in this file. Using this
+                without proper knowledge may result in a crashed OpenVPN server.
+                Check system log to look for errors.</help>
+            </properties>
+          </leafNode>
           <leafNode name="persistent-tunnel">

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

I'm not really sure what the issue is. I can narrow it down to this:

Can you share more examples/configs?
How can we reproduce it?

This affects downstream clients as well

@Viacheslav The issue persists in vyos-1.3.0-rc2-amd64.iso

The root of the problem here is changed place for custom options and the ability to configure options that should be applied differently, depending on the place. In other words, "Additional OpenVPN options" becomes "Additional OpenVPN options. You must use the syntax of openvpn.conf in this text-field", but actually these variants are not fully equal and cannot be converted directly.

@francis try please vyos-1.3.0-rc2-amd64.iso
https://community.vyos.net/get/snapshots/

Another solution it include "user" defined file for options
An example CLI

set interfaces openvpn vtun10 openvpn-option-include '/config/openvpn/included.conf'

@c-po, you cherry-picked the wrong commit: equuleus needs the fix from current, not crux.

In T3418#90244, @c-po wrote:

The first error is related to T2759 and can be ignored.

For the second one, can you please provide your full BGP config by pasting the content of show configuration commands | match bgp\|policy

This is still an issue with 1.2.7-epa1

The first error is related to T2759 and can be ignored.

This is still a issue i build a new image with https://github.com/vyos/vyos-1x/commit/911fe645928750f3ce38061a94c9b6db50db0749 and it was spitting out errors :/

Service still with no description VyOS 1.3-beta-202103170443

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

RFC-compliant VRRP has been broken for all releases of 1.2 so not likely that it will be fixed in 1.2.7 but I think we should make an effort to fix it in 1.3 (?)

@zadm do you test it?