You can via https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27, which just sets the completion help.
For T1845, yes it solves the issue with setting address:port _and_ moves protocol up from facility to host. Do you want me to revert and do 2 commits, which requires then 2 migrations, once for address:port and one to solve the logical issue with protocol. Right now you can set a different protocol for different facilities for the same host.

Will interfere with T1845, while I think T1845 should be the backport candidate. Facility is a tag node, protocol has been moved on level up and is host specific. Having the availability to set different port per facility doesn't really make sense.

Ah yes, it's taken entirely from the string, my fault I tested with the version you can only use an IP address.

Actually I found out that the address:port wasn't implemented at all even if you were able to set it, it never was used within the config. I have that fixed now (not pushed yet). I also moved that part within the nodes, so it's going to be:

If your node exists, you won't see that issue, only if it doesn't. The above PR should fix that, but I have requested a review from @dmbaturin to make sure I don't introduce something into it he doesn't want there.

https://github.com/vyos/vyos-1x/pull/172
should also fix https://github.com/vyos/vyos-1x/pull/171 which wouldn't be required then anymore

@dmbaturin

c.return_value('local-ip') &&  c.return_value(['local-ip'])

would work, shall I rewrite it to a single item list? conf.exists() does only accept s string as argument.

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

Hmm, that's actually a good point (http://docs.frrouting.org/en/latest/ipv6.html). I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.

https://phabricator.vyos.net/T1228 sent the bug and I backported from upstream . The PR is in T1228 but needs to be merged into our package which I don't have permissions for.

After looking into this, the problem seems bigger than originally thought. If the syslog config is being removed from the config the syslog.py script is called and syslog stopped. However if the system is rebooted the init system starts syslog and the config is not calling the script since there is no 'system syslog' node in the config. systemctl disable rsyslog doesn't work some type of depend unit is starting it during reboot.

Yes, I think set service ra interface ... or something like that might be the best option. That would eliminate the template generator script all together and I was thinking to remove interface by interface from the generator, as the rewrite progresses.
Since it needs a migrator script for each interface then as well, even if the option are the same.

Next rolling will have it included.

https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27

Gotcha, I start implement it for the rolling release for now. Since it affects multiple other nodes as well, I'll do it for all of them equally. aka facility has no constraint and completion help too. There are a few more I've found, so I crawl through all of them and enhance it a bit.

@c-po I used the 1.2.3 iso from the download portal and can't reproduce the issue. The help message was also already there since it was (re)implemented, could it be an issue with your installation?

Looks like no one really wants it except for 2 people, going to cancel it.

@kroy AFAIK, intel drivers, KVM (VM performance and I/O), Kernel memory I/O etc.
Performace data can be recorded and replyed asewll. Looks like candidate for debug images as @c-po pointed out.

perf is a tool to gather performance and debug data on a running system with a deep insight into program functions etc. Since it will need a bunch of new libs within the system, I'd like to find out if there is the need for it or not.

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201911102307-amd64.iso or later has it included.

packages are being built via CI:
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-qat/

pending review: https://github.com/vyos/vyos-build-kernel/pull/1

As you pass auth and get the config sent, can you please check that you have a default route set up? Ideally that should happen automatically. It looks like your ISP offers you IPv6 which seems rejected as unknown by the pppoe client, but that't not the primary issue. Check if your default route is being set up.

looks neat. I merged in in already. Can you add some explanation to https://github.com/vyos/vyos-documentation please.

https://github.com/vyos/vyos-1x/pull/149 merged. While I think the UP/DOWN status is a little brave. It leads users maybe to believe that the wg interface has really a up/down state.

For now, it has been decided not to support arm officially, due to lack of resources.

For now, it has been decided not to support arm officially, due to lack of resources.

Thanks for your contribution.

Perfect. Thanks a lot guys.

@Harliff Does curl work for you?

Is that still and issue, sorry I lost track a little while I was busy with other stuff.