Hi @drac, good catch and nice reverse engineering of our code.
Driver will be included in next rolling ISO
Thu, Oct 22
Besides the command proposal there is a common issue with how we build op-mode commands. The best example is the ping op-mode command where and artifical node.tag folder is created which links (ln -s) back to itself.
The current NTP config always binds to localhost and localhost is not a part of the mgmt VRF thus this error message.
Mon, Oct 19
Unfortunately I can not reproduce this issue on my test system and also our smoketests (https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_interfaces_openvpn.py) do not trigger the bug when run locally on the VyOS device by calling:
Do other vendors suppert highjacking/altering of DHCP options? I feel this kills the whole concept of DHCP.
There have been some deletion errors yesterday - are you running the latest rolling release? They should have been fixed in there. If noe please provide me some CLI samples to reproduce the issue.
Sun, Oct 18
It seems that calling openvpn --mktun is what we need.
The root cause of this problem is that OpenVPN when the deamon is started and in tries to connect to the server, yet did not create the vtun11 interface on the system. Thus all calls to the ifconfig python library will fail big time.
Sat, Oct 17
This will break builds in out Docker environment where we ship a packer version. See T2792 and https://github.com/vyos/vyos-build/commit/e2dd9db8a2539b6d13c98d89e18872336cf8f974
Fri, Oct 16
That would be a workaround only - see IPv6 syntax above. Using the refactored interface handling (T2653) makes this a low-hanging fruit.
Thu, Oct 15
Also submitted PR for FRR 7.3 series https://github.com/FRRouting/frr/pull/7318
Wed, Oct 14
Could you share also Client1 and Client2 configuration? Would be nice adding this lab setup to the docs
Please share your OpenVPN config
Tue, Oct 13
Sun, Oct 11
@Dmitry is this a limitation of Accel-PPP or can we increase the limits on the CLI?
I can feel that pain! When looking at the source from VyOS 1.2 (crux) it looks like it always behaved in this way.
Sat, Oct 10
@christophedc0 Have you enabled NAT rule logging?
Fri, Oct 9
cpo@LR4.wue3# lsmod | grep qat qat_200xx 20480 0 intel_qat 299008 2 usdm_drv,qat_200xx dh_generic 16384 1 intel_qat uio 20480 1 intel_qat authenc 16384 1 intel_qat
Mon, Oct 5
Okay 2017 is like yesterday in NIS history so we then should keep it!
Any rolling newer then vyos-1.3-rolling-202010050117-amd64.iso will have this included.
I did a minor improvement and reused the fqdn validator in our system. In addition I refactored the domain-search into an includable snippet - so changing grammar, validators can be done in one single file.
@christophedc0 please check out any rolling release which is newer then vyos-1.3-rolling-202010050117-amd64.iso as I have found two bugs in the implementation (one for source nat logging) and the other for the warning you have posted.
Sun, Oct 4
This was infact only a warning - but for whatever reason nftables is not logging to kernel log :/