Problem exists on 1.2.2
The same thing applies to the global configuration of push options.
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.
Sat, Jul 20
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
Fri, Jul 19
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.
Thu, Jul 18
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.
@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.
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.
Wed, Jul 17
Please backport to Crux.
closed as requested since there is no need for a new implementation.
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/ :
Tue, Jul 16
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.