From the Git commit:
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 17 2020
set service pppoe-server authentication local-users username test password 'test' set service pppoe-server authentication mode 'local' set service pppoe-server client-ip-pool start '192.168.0.1' set service pppoe-server client-ip-pool stop '192.168.0.10' set service pppoe-server client-ipv6-pool delegate '2001:db8:8003::/48' delegation-prefix '56' set service pppoe-server client-ipv6-pool prefix '2001:db8:8002::/48' mask '64' set service pppoe-server name-server '8.8.8.8' set service pppoe-server name-server '2001:4860:4860::8888' set service pppoe-server interface 'eth1' set service pppoe-server local-ip '10.100.100.1'
May 16 2020
May 14 2020
May 12 2020
I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6
No Problem - nice to see races for bugfixes
May 11 2020
Thank you for the good explanation in the issue!
Okay the problem here is that FRR stores the network as fe::/64 and not as fe::0/64 which was specified on the VyOS commandline. Thus the grep command used when deleting the route does not find the proper FRR entry and gives that error.
May 10 2020
That could als help on debugging like adding vyos-config-debug option or as I like on my hosts, vga=773 when debugging and checking for config migration issues.
In regards to 1) I do not remember why I added it there as FRR seems to accept that kind of routes - but its actually a warning only no real error.
The inconsitency of the naming is b/c the default routing table naming is inconsitent, too - thus it makes it consitent again :)
May 8 2020
May 6 2020
New commands added:
May 4 2020
Wireless AP completely rewritten. If issue reappears please reopen or file a new bug.
Forum says issue is fixed. Also WWAN underwent a major rewrite - should be all good now.
@MikeLupe Are you using a custom dyndns provider/script? It ifs compatible with the dyndns2 "API" this is already possible using the "custom" dns dynamic service.
This has been completely rewritte in Python/XML. Please reopen if this is still a problem - and if so what do you think should be the "real" rendered configuration.
I suggest adding a "validate" function to vyos.validate. We should determine the hypervisor used and if a setting is allowed on that hypervisor or not. Thus we can throw an appropriate erorr message by raise ConfigError() in the Python file changing the interface setting. This would be the cleanest way then the "false" setting never reaches the configuration backend at all.
May 3 2020
Sure it can (was in the initial ifconfig.py rewrite IIRC)