Backport to crux complete

cf. T1001 as a related issue:

The real problem is the config parser it seems as it can not deal with special characters used in a pre-login banner.

Ah you were using bleeding edge equuleus builds. Ddclient 3.9.0 has been added to recent rolling image.

Upgraded to 1.3-rolling-201911041446 and the config file issue is still present.

Confirmed using a copy of the Hyper-V VM

ppp0 not renaming to pppoe0 on 1.8.0 https://community.ui.com/questions/ppp0-not-renaming-to-pppoe0-on-1-8-0/b4aeea88-5d52-4222-b065-e6903afdda9a

600MB

that's really strange. As I can reproduce the problem on both intances in 100% of the cases. But not the same config and not the same inital VyOS version.
Can I do some troubleshooting steps for you?
I can also give you the vhd, but on a private channel if possible (is it possible on slack?)

This is weird. I can not reproduce it either with VMWare vSpher enot using Hyper-V.

1vCPU, 512MB RAM

What is your VMs CPU/RAM configuration?

Well, then there is a bug in the interface renaming script with later ifupdown scripts which should be fixed.

No good I'm afraid. NAT is not working set to pppoe0 and is still offering ppp0.

the interface name ppp0 is wrong. If we configure it to be pppoe0 on the CLI it should also have this name on the bare linux system. This sounds a bit like: T1242 which was fixed in commit https://github.com/vyos/vyatta-cfg-op-pppoe/commit/4330d41fcda30553ca1b3e2588d05eebdd59fc80

Interface doesn't work if changed to ppp0. The interface seems to expect pppoe0 and everything else seems to expect ppp0. pppoe0 is still showing as 'coming up', even though everything seems to be working

More info,

After a bit of fiddling, I have found the problem. The config.boot conversion from 1.2 to 1.3 did not chnage the NAT interface entries from pppoe0 to ppp0. Once changed, all is working. As can be seen below, NAT & monitor traffic interface expect ppp0, whilst the actual interface and firewall zones expect pppoe0. I think this is a little confusing and should probably be made consistent one way or the other.. pppoe0: is also still showing as "Coming up" even though everything appears to work so there is still a reporting problem there at the very least.

Wait, Argo tunnel uses Cloudflare's WARP VPN system, which under the hood is basically wireguard...

Tested using the below configuration on VyOS 1.2-rolling-201911030217

I've used the following script to get the argo tunnel running and encrypting dns, i then use 127.0.0.1 as the system nameserver and as the dns forwarder's only upstream nameserver. Works well so far but the integration is lacking with the vyos config

At first glance this looks like a very "easy" priority issue. Bonding interfaces are set up before the ethernet interfaces (makes no sense though).

@starcraft66 is it working as expected?

Hi, the routes are there.

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.

PR #26 https://github.com/vyos/vyatta-cfg-vpn/pull/26

Merged to equuleus branch.

The ddclient config file got moved to /etc/ddclient/ddclient.conf but ddclient is still trying to load /etc/ddclient.conf in the latest VyOS 1.3 rolling image.

My hypothesis is that Interface.set_mac is being called AFTER the bond is applied, which sets the mac of the interface back to what it was originally. Probably adding a check to see if it's a bond member may solve it

Basic config that duplicates this problem

To summarise, the MACs of interfaces that are bonded should all be the same (and should also match the mac of the bond interface). This works correctly in the older July build. However, this no longer works *on boot* in the latest builds. The screenshot above shows eth0, eth1, and bond0 all having different MACs which is why it's not working.

@xrobau WOW! What a bisection and research on that problem! Thanks a lot!

On the old image, the macs are set correctly

I'd keep it open as a reminder what to add to the validator steps in a possible rewrite.

Hi @c-po and @dmbaturin

This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py

With this, will there also be possible to parse the same json into an json import? This to allow for a more programatic way to add things than via set commands