How this can be implemented in practice was tested with https://github.com/thomas-mangin/vyos-extra

• the program can be installed using pip/setuptools and the "vyosextra.main:main" entry point, generating a "vyos" program.
• the "release" program in the root folder generates a self-contained executable (using the builtin python3 zipapp library) which can be place before in the path, taking precedence over the installed version.
• each feature "vyos ssh", "vyos update" is a single program and could be installed independently using other entry points
• dropping a program in the folder automatically registers it to the main "vyos" program, each program has a "def main()" with a docstring used for the "-h"
• the assets in the data folder are converted into python dict and used when the program is a zipapp.

retest on 1.2 and resubmit if the issue exist there

please retest on 1.2 and resubmit if the issue still exists

moved to frr in 1.2

dropping 1.1.x

please test on 1.2 and open new task if issue still exists

got no follow up

Is this reproducible with 1.2 ?

In T740#16862, @dmbaturin wrote:

Should we delete user home dirs when deleting a user then?

Should we delete user home dirs when deleting a user then?

Thanks for pointing that out, I tested manually aswell again on both 1.1.7 and 1.1.5.

Above was on 1.1.7, the same thing happens on 1.1.8:

I don't think the alphabetic order is even relevant (or ansible for that matter). Once you delete a user it frees up the UID but leaves the home directory around with the now unused UID. If you re-create users in a different order the UIDs that still own the home directories no longer match the corresponding users.

IKEv2 is not good in Strong Swan 4.5 at all. There is incompatibility with some other clients.

Can you check behavior on 1.2 ?
Thanks

The "problem" is inherited from the old SNMP CLI definition which was re-generated in XML by me and is now generated here: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/snmp.xml#L230-L237.

nuviso@ubuntu:~/vyos/build-iso/pkgs/vyatta-wirelessmodem$ cat 0001-T701-LTE-interface-dosen-t-come-up.patch
From 00a04474535ec0eb2b17fe1d4368abff7f3aae46 Mon Sep 17 00:00:00 2001
From: Subramonia Pillai <[email protected]>
Date: Wed, 20 Jun 2018 10:57:53 +0530
Subject: [PATCH] T701: LTE interface dosen't come up

I could see that T656 was already created, as a result of https://forum.vyos.io/t/inconsistency-in-wirelessmodem-wlm-interface-behavior-could-be-bug/1492.

In T174#15659, @syncer wrote:

as PPTP phasing out and this is on 1.1.x
marking as wontfix
please try on latest rolling and resubmit if needed

as PPTP phasing out and this is on 1.1.x
marking as wontfix
please try on latest rolling and resubmit if needed

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

Hello,
please retest on 1.2 and submit results
Thanks

We moved to pdns in 1.2 and will not be fixing it in 1.1.x
if you can reproduce on 1.2 mention this task or create new

@dmbaturin stock quagga also missing pbr?

@dmbaturin can i mark this as wontfix for 1.1.x?

Tested on 1.2.0-rolling

I think we can use Debian jessie package for 1.2.0-rolling. But for 1.1, we have to build special version, because there is no upstream package.

@syncer my bad ... then we have to integrate the fixes manually or better, identify why we have to use a special version and decide if this is still necessary. A lot of patches from the past have been removed in the latest Kernel update, too which were no longer necessary.

@c-po vyatta-quagga is our package

c-po, does it mean that the fix will be included in an upcoming 1.1 release and in 1.2.0 when released ?

Thanks for sharing. Debian security updates get automatically pulled in every night diring creation of the rolling release ISO.

can you repeat same on 1.2 ?

Well, as I previously said, I finally know why it doesn't worked as expected for me, since lines like "listen-on vti0 and listen-on vti1" were missing, for requests incoming from tunneled networks.
However, it seems to be strange that requests are sometimes still forwarded, as we can expect that none are forwarded, or all are forwarded, but why sometimes only some request are forwarded ? This seems to be a bug, however this ticket can be closed since for my needs it's ok...

P.S. This is really starting to get more into the territory of support than bug reporting, have you considered purchasing support?

At first glance it looks like the name servers you are using are not reliable, and the lack of response is because the forwarder is also not getting a response.

(By the way, it would be interesting to be able to add more than only one inbound-interface to a NAT rule...)

(And I guess that it's the same reason for NAT rule : the inbound-interface should not only be eth0...)

1. There are no firewall rules set, and no firewall rulset set to the interface on the affected VyOS instances
2. The problems seems to occur whatever the name resolution request is
3. Yes, see below

We'll need some more information.

Yes, I thought about that too, but with or without setting the dns
cache-size to 0, I have the same result !

By default the DNS forwarder will cache recent responses. Have you disabled DNS caching on the forwarding service with the following configuration?

Nope, tested both the vrrp (999.201711150853) and frr (999.201711012230) builds with the same configuration commands as I ran on 1.1.8 and it drops the bridge member properly.

Works fine in vyos-999.201802270337-amd64.

@pers.edwin does this happens on 1.2 too?

Can you test on nightlies please

Created bug T559

Pull request: https://github.com/vyos/vyatta-cfg-vpn/pull/18