Okay, the encrypted passwords are re-read from /var/lib/snmp/snmpd.conf and set on the CLI. The truncation originats from that file.

Ah, yes. In the past the Perl scripts re-read the newly generated configuration and altered the running configuration using /opt/vyatta/sbin/my_set or /opt/vyatta/sbin/my_delete. That's indeed missing. Thanks for the commands and I'll fix it this evening.

I think I set it in an older VyOS version by "set service snmp v3 user nms auth plaintext-key blabla" and VyOS encrypted the key.
I changed now to plaintext-key as in your config in newest build with the same negative result.

@Line2 thanks for the feedback. Could you tell me how you generated that encrypted key so I can retest this evening and bugfix this?

I just tested vyos-1.2.0-rolling+201806050337 with this config (same as in the past worked):

A first implementation is merged

Tested using:

@syncer @higebu Yes, stock quagga is missing many things that ours has. We have no choice other than to integrate the patches by hand.

It was just an error in the help. Someone probably copied it from somewhere else (e.g. the address option of firewall rules) and forgot to edit.

After installing pppd from T677, it seems to work again.

@dmbaturin i think we should do /config/providers or something and keep repo for that data

Found the issue. First, renaming is hadled in a pre-up script that was in the ppp package rather than vyatta-ravpn, so it is not included in 1.2.0.

State files are updated properly after keepalived upgrade, no need for this workaround anymore.

When we get to it, we should also get rid of built-in support for a handful of north american wireless providers (which is likely very out of date by now) and add support for custom connection strings etc.

Completely dead:

Working again with 1.2.0-rolling+201806020337

Just verified that install_routes = no has no adverse effect on L2TP/IPsec.

Downgraded packages are in the latest nightly build.

Correction: 5.5, not 5.2.

No amount of messing up with the config in 5.6 fixed this, but when I downgraded strongswan to 5.2 (from stretch-security), it just worked. I'm downgrading it in the repositories.

I also agree that option 2 seems cleaner. We'll have to deal with migrations, but the result is worthwhile.

It looks pretty clear from configuration point of view. Actually this request was made to avoid potential security breach if somebody doesn't have correct acl on wan facing interface.

Should be working now in the code rewritten for pdns, and dnsmasq is gone so issues specific to it will not be a problem anymore.

Should be working now that we've added syslog forwarding to journald.

@aopdal I agree it would be nice to have RFC compatibility, but when it was introduced, it relied upon a kernel hack that never made it into the mainline. If mainline keepalived and kernel do not support it, and we cannot add support for it that can be merged into the mainline, then it's more trouble than it's worth I think.
Cross-vendor VRRP is more of a hypothetical situation than a common setup.

The fault was in XorpConfigParser, whose "set" function behaves as if all nodes were multi nodes, so it was adding a value where none was needed (that's on top of the fact that it didn't properly check if it exists).

I've setup a minimal WLB config and it worked for me.

Serial is, sadly, a hard problem, especially on machines that need it most, i.e. those without any graphical console. Since it's impossible to automatically find out the correct port and speed/parity settings, it will always need some manual configuration I suppose.

I have reservations about actually using it though. The whole point of the vyos-1x package is to stop multiplying submodules and consolidate everything instead. ;)

Without the new sysctl options:

For the VRRP group running IPv6 you need 'vrrp_version 3' at least in the keepalived config.

Even simpler way to reproduce:

@syncer this is implemented and working with a patched xl2tpd (T605).

This one should be closed and reopened if required @syncer

Good catch. The proper solution should be:

As soon as someone sets set system ntp allow-clients address 172.16.0.0/12 we act as NTP server for this network,too. It's a bit odd that this node is under system but ... it is as it is.

that is weird,
i was under impression that we have it as client.
So it perfectly make sense have it under service

@syncer we do offer NTP as service (unfortunately it's unter the system tree instead of service.