Ah, that is just legacy. Ironically, when I updated the code manually to mitigate this problem, I deleted the root user. Lol. Still, there may still be users out there from the Vyatta days that still have it there. Off topic here but I am also a PPPoE user and am now running the latest version with all the recent PPPoE re-write and all is working fine.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 27 2020
For TLS crypt please see T2075
looking at your config I see the issue, it is b/c you define a root user which triggered an exception. I will fix the code to mitigate this bug.
Thanks for testing and reporting.
i think, you sould use crux branch for 1.2 build, current branch is 1.3
This should actually be possible after the PPPoE interface rewrite in the latest rolling image.
No answer from user.
Feb 26 2020
Yes there are definately other places like DHCP.
I personally don't mind the raw options, and there are other people using them too (T127, T1246, T1383, T1421, T1430).
There is no option for tls-crypt, just tls-auth. Also I'm experimenting with the various mtu options (tun-mtu, link-mtu, mssfix, fragment) and keepalive options (ping-restart, ping) that can't be set through the existing keepalive options (keepalive doesn't take 0 as a value if I want ping-restart 0 for example, and there's no way to not have keepalive be set with default vaules). So yeah, if all of these options were integrated, I personally wouldn't need the openvpn-options. But I think there are other places that use raw values with quotes that are affected by the autocompletion bug too, dhcp-server for example.
Thats the downside of those nodes which allow passing raw values down the config. I never liked them and they should be removed. The CLI should be extended to support the raw options instead.
Feb 25 2020
There you go
Could you provide me with your full 1:1 configuration (paswords can be omitted)? Then I check again
Feb 24 2020
Robert did new tests on his GNS3 lab (results attached).
PR for 1.3-rolling https://github.com/vyos/vyos-1x/pull/228
FWIW, this issue is still occuring on 1.3 rolling (1.3-rolling-202002180217) for interfaces with DHCP set. While the above referenced repository is archived, the script here https://github.com/vyos/vyos-vmwaretools-scripts/blob/current/scripts/resume-vm-default.d/ether-resume.py seems to be the latest version.
For any interface with DHCP enabled, it will try to run
ip address add dhcp dev ethX
Since dhcp is not a valid address this fails and after the interface loses it's IP until dhclient is run manually or the system reboots. The script linked by @dmaasland works correctly.
The patch is ready for inclusion.
This work raised an issue with the current pattern of using Interface(..).remove() which is used in VLANIf as it requires Interface to know that EthernetIf can not be deleted (an implementation detail which should remain in EthernetIf).
@hagbard thanks, works as expected. I think this might be backport candidate to 1.2.X
https://github.com/vyos/vyos-1x/commit/d9fa3fb7d7613cd5d6297115da0dc63462d4cf69
@Dmitry next rolling will have it enabled, let me know if it works for you as intended.
Feb 23 2020
This is the bottom of the config that fails the upgrade
Hi, That wasn't the problem. I did remove some of the config. I must have left a bit.
removing the check makes it work like a charme push request incomming..
On first glance this looks to me like zone policy issue.
A fix for this is available in the latest rolling release
run into the same. If I add parameters default 'no-ipv4-unicast' to my config and commit I get the waring above. All runs fine, cause the sessions where already configured before.
If I do a reboot, bgp config in frr is neartly empty only "router bgp 64512" was there not more. Removing it and do an commit nothing changed. Removing it an reboot helped.
Feb 22 2020
Feb 21 2020
Pull Request: https://github.com/vyos/ppp-upstream/pull/2