Sorry guys - the fix worked, but only for community strings that are network-specific. See new pull request for the non-specific network version as well.

Certainly not fixed in 1.1.x - but I'll see what I can do with it. 1.2 has such completely different handling that I couldn't even guess what it does. I'll have to work out a lab to reproduce it. Might get to it at the weekend.

As I say... I don't have the standing or the background to really question the approach. If you guys aren't really interested in commits that are perl-based, though, then I'm afraid I don't really have a lot to offer.

just a thought - much of this is porting EdgeOS features, right? Those guys are still using perl, so any features they implement that VyOS wants is going to be perl by it's nature, surely?

This is fixed, too. Can we close it?

This is definately fixed. Can we close this one?

Cool.

I'm all about compatibility with existing behaviour. Looking back over just about every network device I've ever operated, and the bits that annoy me the most is when behaviour is changed in a surprising fashion. I know there's a tension with the ability to actually continue to improve the product, but where there's a choice between 'make it unsurprising', or 'make it cooler', from a user perspective, you want the developers to have exhausted every option to do bother before making it surprising.

OK. Minor tweaks - actually wired 'show vpn ipsec sa' to use the pretty-print code, rather than just calling swanctl to get half a page of ugliness.

Yeah, C-po. That doesn't surprise me.

To my mind... I'd rather keep a compatible syntax than a new one, even if there are benefits in terms of uniformity and parsing.

Right. Pull request merged. I'll make sure that it's all working once it's made it to the nightlies, and then close this one.

Yup. Definately not reproducible.

Hi Line2.

Gimme the ticket, and I'll take a look at it.

There's a pull request against vyatta-op-vpn that implements all of this.

Hmmm. Can't reproduce this on v999.20170626 at least.

Can't reproduce this on (at least) 999.201706262137, at least on my local network getting DHCP for eth0.

Pull request sent to fix this one.

Pull request sent to fix this one.

Indeed. Looking at the original script, it looks to aggregate config and log entries into a big pile of output, presumably so that somebody can attempt to diagnose it in a support sense.