I forgot to fetch commits for the latest build-ami version when submitted report.
Now I confirms that problem exists in the latest version with the last commit:

@aaliddell No worries! It was a really easy fix. :)

What about Dockerfile in vyos-build?

@syncer, this is a quite serious security issue and a deal breaker for dmvpn. As we have earlier stated that dmvpn is working now (http://blog.vyos.net/vyos-development-news-in-august-and-september) i think this needs to be fixed before 1.2LTS ... OR. We need to make a new statement that states that dmvpn will be broken in 1.2LTS..

I've been trying to get a dev environment for vyos-strongswan up and running for a couple of days now but are unable to compile it.. right now i'm stuck with the compile system not finding my libsoup-2.4 package :/

Just ran into this with 1.2 RC9. eth0 and eth2 swapped devices, presumably due to differences in the timing of device init in the new kernel version, meaning DHCPd ran on the WAN interface, which the upstream won’t appreciate. Having proper static device naming would have prevented this.

@UnicronNL can you explain right way to create 1.2 ami

@UnicronNL we need to have ability to create link files and update initrd with them

@c-po @rps @hagbard @dmbaturin
let's do it in subtasks and in 1.3

@gadams I could have sworn I'd put $ifname in there, but the git history doesn't lie; apologies for missing that and thanks for catching.

Or drop by our slack channel for help

First you need to specify a new version of your subtree,
https://github.com/vyos/vyatta-cfg-system/commit/f68dda9d619ea74bed266122ac86604284e1a9e4

Ok. Fine. Can you give me a hint about docu and an example of such a migration script? So I'll try to implement one for this case: Migrate from webproxy proxy-bypass 1.2.3.4/24 to webproxy whitelist destination-address 1.2.3.4/24

@dsteinkopf I think almos every command is good when there is a discussion ongoing and we can agree on somehing. VyOS has so called migration scripts which are executed once we do CLI changes and thus migrate old configuration nodes to new ones. We already make use of this feature alot and it is transparent to the user.

Thank you for your positive feedback. I am open to all changes.
We can rename the command, of course. But let us think about this shortly:

I really like the idea and thank you for the contribution.

@dmbaturin you want too look into this

While it is work ongoing on this, the code for LLDPD is quite old. i would request an upgrade to the newest version . https://github.com/vincentbernat/lldpd/tree/1.0.1

So exploring some wider thoughts.

I have now implemented the syntax I described above. There are still some edge cases, mostly because of the fact that dhclient is started in a whole bunch of places, and making it all consistent is tricky. Perhaps refactoring /opt/vyatta/sbin/vyatta-dhcpv6-client.pl (probably rewriting it in Python) is in order. I may not do that right now, though.

What do you propose as CLI syntax?

So how do i do this officially? Or get the work done for this to be official?

Having lifted the hood and bent a few rules....

OK! I'm happy to say that I have prefix delegation working with ISC dhclient, now, using a dhclient exit hook to collect the delegated prefix and farm out chunks of it to local interfaces. Now I'm tnhinking about the configuration syntax.

I've also started to hack a bit on configuring dhcpd on my router(s) so that upon delegation or update of a prefix delegation, I can re-configure dhcpd to provide delegated prefixes to other devices on my network as I have a few routers "inside" my network, and I'd like all devices to get addressed with proper v6 addresses.

Hey, laziness is a programmer virtue, remember!

@gadams, now you're really making me look lazy!

Aha! Looking into it a bit more, the hook scripts are given the environment variables new_ip6_prefix and old_ip6_prefix, so that's where we should get the delegated prefix (and remove an old one, as appropriate). So, all we need to do is add some configuration settings to request PD and to indicate a subnet number within the delegated prefix to assign out to any desired interfaces. Then, it's a simple matter of exit-hook scripting to set this all up.

That's very interesting. Thanks for sharing.

did some dirty "hacking" to get this working for myself. I use Cogeco in Canada, and I can get *either* a dhcpv6 lease on my outside interface, *or* a /56 prefix delegation.

Since the fix is far from trivial, a workaround exists, and the entire PBR subsystem is due for a rewrite in the next release, I'm moving this to 1.3.x.

Even better! Thanks for the hint!

@c-po actually accel-ppp provides SSTP server

@syncer seems this is the only available SSTP Linux implementation

@sokrates No problem at all, whenever you have time.

@hagbard yes i am sorry for being late i am sick in the bed ... i hope to have time for this on weekend

@sokrates Can you please test with the latest rolling release?

Hmm, it works for me flawlessly. Can you try https://downloads.vyos.io/testing/1.2.0-rc7/vyos-1.2.0-rc7-amd64.iso please?

Yes i have test this case -> 115200n8

What are the parameters you connect on rs232? Have you tried to switch to 115200 baud after grub started?

My serial interface don't show me the Boot after fast grub ( i am not able to see the menu only a line with a timer ) and i have no shell after boot, only ssh on the default image 1.2.0.rc7
the image i used to install ( 1.1.8 ) works after i build a new iso following the guide on the wiki
but it is the stable version.

sh version
Version: VyOS 1.2.0-rc6
Built by: [email protected]
Built on: Tue 06 Nov 2018 01:28 UTC
Build ID: c5283369-3c07-4539-97fb-76e701e97a77

What's the problem @sokrates ?

Hi, I requested this feature, but due to the addition of username/password it can work as a good workaround.

Its a little hack, but not the ultimate one i think :p temporary files for storing state is used quite a few times inn the original bash/perl scripts

This looks like an ultimate hackaround. Maybe we should check if we can change the C implementation

as noted on slack:
A way to implement the run once for tag :
If we in the tag after first execution add a temp file 'touch /tmp/complete-blah' , then we check for existance on that file on every run and skip of it exists..
in eg. wireguard/node.def:

end: if [ ! -f /tmp/runonce-wireguard.lock ]; then
         sudo sh -c "${vyos_conf_scripts_dir}/wireguard.py"
         touch /tmp/runonce-wireguard.lock
     fi

Whis way the wireguard.py shuld only execute on the first "execution" and be skipped on all recurring runs.

I've been looking into how this is implemented in all instances of interfaces/* and everyone uses the same run on every tag value instance approach.
Here are a couple of examples of easy implementations looked from node.def
openvpn:
sudo /opt/vyatta/sbin/vyatta-update-ovpn.pl "$VAR(@)"

Actually I only wanted to use it got configuration backup.

I'm pretty sure it's supported, whether intentional or not... on 1.1.8 it's right in the tab completion, with help and all:

Don't think that adding key options ever was supported
@dmbaturin @c-po how you think we can address this?