I've tested the fix on latest rolling and so far it works as expected.
Thanks for the quick patch!

https://github.com/vyos/vyos-1x/commit/36f8a1e4e5966c43c5330ff223fa2ef07d346b6e

Problem exists on 1.2.2

The same thing applies to the global configuration of push options.
E.g. These:
set interfaces openvpn vtun0 server push-route '172.16.41.0/24'
set interfaces openvpn vtun0 server push-route '172.16.42.0/24'

We may have to migrate to networkd to have that functionality, since netplug seems to cause issues with interfaces which are up and running.

@dienac any results to share?

I can't reproduce your issue, so I suspect no issues with the pppoe client we ship in vyos.

Your filter was a bit to tight, all I see are the LCP echos. I' more interested in the PAD packets, in particular what sides sends a PADT and if PADS is clean.

Thanks for the reply,

VyOS 1.2.2 only contains DHCP op mode definitions from the following packages:

fix backported to crux

your are confused with client and server commands.

I wonder if the bgp daemon is being started before the hostname is changed by the config script. Seems possible since we added a lock so it executes later.

@zsdc Hostname is still showing as 'debian' in 1.2.0-rolling+201907191807

xe-daemon.service is missing, please add it

https://github.com/vyos/vyos-netplug/commit/81fd74bfbfa6daed506693ecc20deff09042bc71 broke it, I have to find out why he commited it.

I'll set up monitoring, sure.

I have ran VyOS 1.2.1 and now 1.2.2 for quiet some time and can no longer see this issue. 1.2.1 and 1.2.2 are both based on PowerDNS recursor 4.1 series.

Can be set to finished on 1.3 Equuleus

That's unfortunate. I've had to restart dns every few days at some clients due to an outage because of this bug. It would be not nice if it were to regress. Is there a way to build on buster with newer packages?

Unfortunately PowerDNS no longer supports the 4.2 series on Debian oldoldstable (Jessie) - reverting this on current to fix the build.

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

Create PR https://github.com/vyos/vyatta-cfg-system/pull/104/commits/ec407d330649e687da42edcca46b6ea544f65458

fixed via https://phabricator.vyos.net/T1065

We cannot backport anything that introduces a syntax or behaviour change, much less if it may possibly need a migration script. ;)

Even if it was allowed, dhcpd would fail to start with the generated config so it shouldn't be a problem? Unless some had their invalid config kept even with broken dhcp-server, which I doubt.
It would be fixed first in current, of course. It's not a priority for me so I won't be tackling it.

@zsdc I've included keepalived 2.0.17 in the rolling release repo and it will be in tomorrow's nightly build. Please test.

I would be wary of including it in Crux, since it's a behaviour change.

These are default VyOS installations without any modifications other than to the running configuration. During these recordings I set IP address, duplex, and speed on eth0, set a static route, hostname, and ntp, time, and dhcp server configurations. While doing so, I used ? to enumerate possible configuration paths and [tab] for CLI completion to hopefully illuminate the latency in these operations.

https://github.com/vyos/vyatta-ipv6-rtradv/commit/2c543f7f369f9429e7dad89bb7bb9f9dec823856

@mb300sd, yes - nothing newer yet. Just test, please, when a new build will be available. :)

This also affect manually built iso's that also fails because of pdns-recursor

Hi! The rolling release is broken because pdns-recursor has stopped to provide packages for jessie and the current index points to a file that is currently not available. We are working on fixing this and it migth be that we need to start building it ourself instead.

@zsdc Rolling builds appear to be broken. ( T1533 ) Nothing newer than 201907150337.

The problem, which leads to the malformed hostname in Hostname Capability was fixed in T1531. I am marking this as "Resolved", because the problem with DNS servers was resolved also, according to feedback.

Thank you, @ekim!
What exactly you were doing at the moment of this log record? I see a lot of scripts, which are almost permanently do something in the system. Is it possible that this system contains some custom scripts (in /config/scripts folder, for example)?
If yes, you should check the schedule of execution, and requirements of modification for 1.2 version command syntax.

@bmtauer, @mb300sd, the proper fix was applied. You can check again with any rolling release after 2019-07-17. Write back, please, if the problem will be still there.

Please backport to Crux.

closed as requested since there is no need for a new implementation.

Update:
I did tested several server-related option combinations, such as "--ping-restart 0", "--reneg-sec 0", "--reneg-sec 36000"(10h).
Then I realized that I might interpreted --reneg-sec option incorrectly. As stated in(read text in bold) https://openvpn.net/community-resources/reference-manual-for-openvpn-2-3/ :

This is already fixed in the latest rolling images (equuleus).

This is really a broken abstraction. There is no separate namespaces for IPv4 and IPv6 groups in IPset.
We'll have to autoprefix the groups or similar, if we want it to work that way.

Fixed for rolling release.
https://github.com/vyos/vyos-1x/commit/016524841da12b68468468cf8f4947b82213ffcd