The above patch breaks sorting for other nodes that contain text, not a number. We'd need some way to distinguish different node types (text, IP, number,...) and chose different sorts depending on that.

Is this only for interfaces or for other rewrites (NAT, Firewall, BGP) too? If so, I'll add all the related tasks.

What's the reason for enabling flow control by default? I'd have assumed disabled is more common and causes less problems. The node naming is not the best IMO as it has "disable-" in it, more reasonable would be to have a node called "flow-control" that enabled it if set, the default being disabled, and it could have sub-nodes to tweak the exact flow control settings.

I would check in main, before get_status, if a interface is disabled in config, then I'd just print "vtunX is disabled" and skip all other processing for that interface. If a interface is enabled but its status file isn't readable, print "Error: status file for vtunX is not readable" (I'd use try/except around the open in get_status, and return a exception so that main can print the error).

I can confirm the above commit fixes booting with interfaces that don't support flow control. I have no way of checking that it properly applies if the interface does support it.

After discussion on the PR it was determined this functionality wasn't needed.

I tested it today and it doesn't work yet.

+1, I'd also like if all failed commits were stored in a permanent log somewhere to make debugging easier, I can't find one right now.

The file exists on my system (1.3-rolling-202003291001):

-rw------- 1 root root 377 Mar 31 11:44 /opt/vyatta/etc/openvpn/status/vtun0.status

and show openvpn server works:

vyos@rt-home:~$ show openvpn server

I vote for this as well. I have a lot of addresses I need to add to a nat source address so I need to create one rule per IP. Because I have a specific rule numbering scheme, I'm running out of space in it so I had to break the scheme. The ability to use groups in nat source and destination addresses would greatly help.

While you're looking at it, can you try to move it to a systemd service? I opened a task for discussion: T2185

It's useful when the user is sure he doesn't want IPv6, as it lessens the attack surface, especially if the user doesn't know he needs to configure a IPv6 firewall separately to the IPv4 firewall. Even link-local addresses can be used to launch attacks in the absence of a firewall config.
IMO the configured interface addresses and v6 nodes should become no-ops, possibly print a warning on commit.
On the other hand, leaving IPv6 enabled, would be better to move in the direction of v6 adoption. Personally, I'd prefer this, and leave v6 enabled by default.

also I would remove L107-L109 and move the debug message to the exception handler of L114

I think this throws a exception that isn't caught: https://github.com/vyos/vyos-1x/blob/583e9d907236a4a98fe40e97a378c1fb655f8a95/python/vyos/ifconfig/ethernet.py#L114

root@vyos:~# /sbin/ethtool --show-pause eth0
Pause parameters for eth0:
Cannot get device pause settings: Operation not supported
root@vyos:~# echo $?
76

@thomas-mangin Which commit do you mean, https://github.com/vyos/vyos-1x/commit/60d35d1d4d3a5acec6e39cccb166fd33490b6c27 ?
I can definitely say that did not fix the issue for r8169, the router failed boot after upgrading to 1.3-rolling-202003250217. If there were any patches after that, I can't see them.

I'm still getting the same behavior on 1.3-rolling-202003250217:

vyos@vyos:~$ show interfaces wireless
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
wlan0            -                                 u/u  
vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces wireless wlan0 disable

Actually I had link-mtu 0 on br0 for a long time now and it worked without problem previously, maybe 0 was a special meaning for radvd?
br0 is the only interface that had ipv6 router-advert, I included one of the eth's for completeness:

interfaces {
    bridge br0 {
        address 192.0.2.1/24
        address 2001:db8::1/64
        aging 300
        description LAN
        firewall {
            local {
                name lan-local
            }
        }
        hello-time 2
        ipv6 {
            dup-addr-detect-transmits 2
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag true
                max-interval 600
                other-config-flag false
                prefix 2001:db8::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        max-age 20
        member {
            interface eth0 {
            }
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth4 {
            }
            interface wlan0 {
            }
        }
        priority 20480
        stp
    }
    ethernet eth0 {
        duplex auto
        hw-id xx:xx:xx:xx:xx:xx
        smp-affinity auto
        speed auto
    }
}

I already hotfixed the issue on mine by adding r8169 into the unsupported list - but as said, that's not the real solution.

Maybe check the physical interface support via ethtool in the ethernet validate() function and raise a configerror if it doesn't? Or should the default be disabled and should a config command be enable-flow-control? The script that actually sets the flow control should definitely just print a warning to the syslog and not fail.

I'll open a new task for it.

I suspect the driver blacklist won't be enough for a lot of users. A lot of very common ethernet cards don't support setting pause frames.

Please add r8169 as well. The config failed to load at boot after upgrading to latest rolling because of this error. The script should check if the interface supports pause and silently continue if it doesn't, otherwise maintaining a list of all pause-unsupported interfaces is going to be next to impossible. I suspect a lot more of them don't.

Closing, 1.3 has rewritten the perl code from scratch in python, but the functionality should be the same.

We could make compat-names a configurable option that defaults to disabled, e.g. "set interfaces openvpn vtunX tls compat-names {no-remapping}"

The implementation mostly works, but still behaves unexpectedly when keys don't have a BEGIN EC PRIVATE KEY or BEGIN RSA PRIVATE KEY, but have just a plain BEGIN PRIVATE KEY, which is valid for both EC and RSA (and is the default output format for openssl ec -out, for example when removing a passphrase from the key). We need to switch to checking the key type by actually trying to read it with openssl and checking its error status.

Couldn't reproduce in 1.3-rolling-20200319

Sorry, the task name was wrong, "save" resets it, "commit" doesn't. Personally I prefer if it'd stay the same, but I don't care if it resets it either.

The discussion says the container should be started with --privileged, as is documented in the vyos-build readme. Did you test it with --privileged?

Duplicate of T421

Still present in 1.3-20200319

The above commit fixes value help on tab (it displays correct quoted values, the script doesn't error any more) but the completion itself is still broken.

I opened the PR for our custom build of the package in vyos-build as well: https://github.com/vyos/vyos-build/pulls. I was waiting on testing results from anyone, but I went and tested it myself. The basic functionality works, I couldn't test the above bug. If it's merged and the new package build is added to CI, the above debian PR isn't needed (or our custom build isn't).

I ran into this today after upgrading to latest 1.3 rolling image. All interfaces were added and appeared to have the correct macs (the output of ip link matched what was in the config), but the physical interfaces to which they corresponded weren't right. I found this by looking at the link state of each interface and saw that two if them were swapped. The interface that should be eth2 was physically eth4 and vice versa, but the macs it was showing in ip link was wrong for that physical card, as if it were set to the other interface's mac erroneously.
I got the cards to detect properly after 2 reboots.

I haven't encountered this since, but the single 1.2 router is still on rc11, which has updated pdns-recursor 4.2, before being reverted: https://phabricator.vyos.net/R3:8c22ceead487b745d6b7c058c4d1c0a0eaa051c8 so it may still possibly be an issue in 1.2.
I've never encountered it on 1.3 rolling.

I'm not in the VyOS core team so I'm not able to make direct decisions on the resolution, but as I see it, there are several possible ways to approach this.

https://github.com/jjakob/vyos-build/tree/conntrack-tools-wip builds conntrack-tools from upstream git snapshot 20200301.

Fixed temporarily for now in https://phabricator.vyos.net/R3:1c4414dd363bdb268038ae238686be3e0b7f988b
We should re-add building it from upstream to fix T1538.

https://github.com/vyos/vyos-build/pull/84

@cpo I think you need to add it to CI in addition to vyos-build

Upstream still hasn't made a release with this patch: https://git.netfilter.org/conntrack-tools/commit/?id=c12fa8df76752b0a011430f069677b52e4dad164
So we could wait on upstream to release it and debian to package it, or build our own as we used to in 1.2.
It would be better to ask upstream to make a release as there's less work for us.

We don't build conntrack-tools in 1.3 (current/equuleus) any more, upstream Debian Buster conntrack and conntrackd packages are used. So as upstream gets patched, we'll pull in those patches automatically.
If I see things correctly, there are references to conntrack-tools in the build scripts that still need to be removed.

Sorry, I titled the task wrong. The error is in building conntrack-tools.

I think you're right, I couldn't find any package depending on it, vyatta-conntrack-sync only depends on conntrack.
I also found this https://phabricator.vyos.net/T1538 in which the conclusion is we should upgrade conntrack-tools.

https://github.com/vyos/vyos-build/pull/83

I personally don't mind the raw options, and there are other people using them too (T127, T1246, T1383, T1421, T1430).
There is no option for tls-crypt, just tls-auth. Also I'm experimenting with the various mtu options (tun-mtu, link-mtu, mssfix, fragment) and keepalive options (ping-restart, ping) that can't be set through the existing keepalive options (keepalive doesn't take 0 as a value if I want ping-restart 0 for example, and there's no way to not have keepalive be set with default vaules). So yeah, if all of these options were integrated, I personally wouldn't need the openvpn-options. But I think there are other places that use raw values with quotes that are affected by the autocompletion bug too, dhcp-server for example.