@danhusan IPv6 should not be affected. Workaround for IPv4:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 23 2019
Just tested the most recent nightly (1.2.0-rolling+201902222123) and it works! Thank you so much y'all.
Feb 22 2019
@oleksandr.ovsiannikov any updates?
binaries (lcdproc, lcdproc-extra-drivers) added to rolling releases.
@fromport http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-openvpn/vyatta-openvpn_0.2.60+vyos3+current2_all.deb or next rolling release (Feb 23rd).
@fromport http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-3_all.deb or Feb 23rd rolling release. If it's urgent I can trigger a build for you.
Just tested the next day nightly build.
Root cause is the inability of tftpd to listen on multiple addresses.
Will test with the next rolling before I close off the task.
Feb 21 2019
https://github.com/vyos/vyatta-openvpn/commit/9166dde7fd5ca7b313de585067b06af6a8b9c82a Should be in the next latest rolling, can you please test?
just compared 1.20-rc7, 1.2.0 official & the current rolling:
In T1259#33041, @varesa wrote:Hopefully a fix: https://github.com/varesa/vyatta-openvpn/commit/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725
After doing: sudo curl https://raw.githubusercontent.com/varesa/vyatta-openvpn/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725/lib/Vyatta/OpenVPN/Config.pm -o /opt/vyatta/share/perl5/Vyatta/OpenVPN/Config.pm commit with my above config succeeds.
Produced command seems to be:
Also managed to reproduce, some set-commands to help reproduction:
Added the above snipped to vyos-1x and the latest rolling releases
Yeah, I agree.
Unfortunately this is not implemented in ntpqc. The reason it worked for me was my firewall blocking everything else.
As there is no recorded bug in this behavior on 1.2 we only would increase the risk on the LTS versions without legitimate benefit.
We should NOT backport this to VyOS 1.2 crux
It didn’t cure it I’m afraid. It has, however, changed the error message to:
and thanks for the help hagbard ...
So i have test it and ... hmm the Problem is that the grub menu is ripped apart.
Feb 20 2019
Please test with a rolling relase build date newer than 20120220 - Drivers have been replaced with the ones provided by Intel
Please test with a rolling relase build date newer than 20120220 - Drivers have been replaced with the ones provided by Intel
[ 227.874683] dca service started, version 1.12.1 [ 228.282193] ixgbe: loading out-of-tree module taints kernel. [ 228.288861] Intel(R) 10GbE PCI Express Linux Network Driver - version 5.5.3 [ 228.288863] Copyright(c) 1999 - 2018 Intel Corporation. [ 295.462589] e1000e: Intel(R) PRO/1000 Network Driver - 3.4.2.1-NAPI [ 295.462592] e1000e: Copyright(c) 1999 - 2018 Intel Corporation. [ 299.685648] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 2.7.29 [ 299.685651] i40e: Copyright(c) 2013 - 2018 Intel Corporation. [ 303.095404] i40evf: Intel(R) 40-10 Gigabit Virtual Function Network Driver - version 3.6.15 [ 303.095406] Copyright(c) 2013 - 2018 Intel Corporation. [ 306.534477] Intel(R) Gigabit Ethernet Linux Driver - version 5.3.5.22 [ 306.534480] Copyright(c) 2007 - 2018 Intel Corporation. [ 313.059333] ixgbevf: Intel(R) 10GbE PCI Express Virtual Function Driver - version 4.5.2 [ 313.059336] Copyright(c) 1999 - 2019 Intel Corporation.
We should NOT backport this to VyOS 1.2 crux
Yes, please migrate that function, too. One more migrated command.
Feb 19 2019
/opt/vyatta/share/vyatta-cfg/templates/system/static-host-mapping/host-name/node.def writes the entry, I think the functionality should be integrated into host_name.py. I contacted @c-po to hear his opinion.
Tested it myself and can't find any issues.
No idea what that could be, it's for sure a config problem since many others use it as well as myself with no issue at all. Is there any way I can access your env?
Tried both and they solved the issue but same problem with the tunnel not going up is the same.
I tried regen keys on both ends. No dice.
In T1247#32887, @oleksandr.ovsiannikov wrote:@hagbardIt fixes the issue with WANLOADBALANCE_PRE chain, but we still observe unexpected behavior.
I will write a little bit more letter.