Ah, I missed that it's for 1.2, 1.3 has a newer isc-dhcp.

https://github.com/vyos/vyos-1x/pull/349

The previous commit didn't fix it, this one does: https://github.com/vyos/vyos-1x/pull/348

My first thought would be something wrong with offloading on the NIC -
there was a change recently that turns all the offloading settings on by
default, you can disable some in the ethernet config. My suggestion to
leave the default disabled and enable it on demand wasn't taken into
account.

https://github.com/vyos/vyos-1x/pull/345

That's how DNS forwarders usually work. If they can find a domain
locally, they'll use it, if not forward to upstream. The same behaviour
is everywhere, on all resolvers.

Sorry for the noise, it was disabled. I forgot to save the config before upgrading, doh.

vyos@rt-home# show openvpn 
 openvpn vtun0 {
     encryption {
         ncp-ciphers aes256gcm
     }
     hash sha512
     keep-alive {
         failure-count 60
         interval 59
     }
     mode server
     persistent-tunnel
     server {
         client jernej-note3 {
             ip x.x..7.10
         }
         client-ip-pool {
             start x.x.7.127
         }
         domain-name home
         max-connections 10
         push-route x.x.0.0/24
         subnet x.x.7.0/24
         topology subnet
     }
     tls {
         ca-cert-file /config/auth/openvpn/ca.crt
         cert-file /config/auth/openvpn/rt-home.crt
         crypt-file /config/auth/openvpn/tls.key
         key-file /config/auth/openvpn/rt-home.key
     }
 }
 openvpn vtun1 {
     description b
     device-type tun
     disable
     encryption {
         ncp-ciphers aes256gcm
     }
     hash sha512
     keep-alive {
         failure-count 60
         interval 59
     }
     local-port 1195
     mode server
     persistent-tunnel
     server {
         client jernej-note3 {
             ip x.x.8.10
         }
         client-ip-pool {
             start x.x.8.6
             stop x.x.0.3
         }
         domain-name home
         max-connections 10
         push-route x.x.0.0/24
         subnet x.x.8.0/24
         topology subnet
     }
     tls {
         ca-cert-file /config/auth/openvpn/ca.crt
         cert-file /config/auth/openvpn/rt-home.crt
         crypt-file /config/auth/openvpn/tls.key
         key-file /config/auth/openvpn/rt-home.key
     }
 }
[edit interfaces]

I tried removing client-ip-pool if it was a issue with it, no difference.

vyos@rt-home# delete openvpn vtun1 server client-ip-pool 
[edit interfaces]
vyos@rt-home# commit
[ interfaces openvpn vtun1 ]
Warning: Client "jernej-note3" IP x.x.8.10 is in server IP pool, it is not reserved for this client.
Diffie-Hellman prime file is unspecified, assuming ECDH

This is a old quirk that's long known (probably was already reported) and
can be worked around by adding a pseudo-ethernet interface with the DHCP
client on it.

https://github.com/vyos/vyos-1x/pull/339

I use http://jinja.quantprogramming.com/ to test templates. With it you
can test all possible combinations of input variables. (You need to test
all combinations if you're stripping whitespace, as some combination can
have a good format, another can have too much whitespace stripped)

Yes, that would be useful, for example conf_mode scripts could print warnings that would go to the syslog when the config is applied on boot. Other scripts output is seen by the user anyway so I don't see a use elsewhere.

Oh, nice!

How do we use this new "airbag.py" for on-demand logging from scripts? For example if I want to print a warning when executing a conf_mode script that should go both to stderr and to a file, but is not a fatal exception?

no link-local IPv6 address for eth0

IIRC vyos doesn't support setting link-local addresses on interfaces
through the CLI, though a IPv6 interface should get one by default by the
kernel (I may be mistaken, what does "ip addr" say?)

WIP: https://github.com/vyos/vyos-1x/pull/325
We won't do strict exclusion of client IPs from the server pool, but just print a warning if they overlap. This way old configs won't require migration and will still work, and new configurations will be able to manually set a smaller pool.

https://github.com/vyos/vyos-1x/pull/323
Bridged mode still doesn't work until T2064 is fixed, but at least the validation should be fixed.

It's best if we just use packages targeted for buster, not another debian release. I suggest you create PRs for all pathches needed (in addition to the one you already submitted) in Debian's PTS for buster's conntrack-tools, and then ask them to make a new release with those patches included.

https://github.com/vyos/vyos-1x/pull/321

Is this normal?

vyos@rt-home# set interfaces ethernet eth4 vif 20
[edit]
vyos@rt-home# commit
[ interfaces ethernet eth4 ]
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gro off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 sg off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 tso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 ufo off'
DEBUG/ifconfig returned:
Cannot change udp-fragmentation-offload

T2199 for the firewall rewrite - free for the taking. I wouldn't stray much from the old code logic, as some things have hidden meanings. Especially leaving checks out could introduce bugs unless you're absolutely sure they can be bypassed.

There was a new upstream release 1.4.6 7 days ago, but that shouldn't make it to debian stable (buster). Only the patch done by elbandi via PR could get released as 1.4.5-3, but it hasn't been yet. We could make a backport of 1.4.6 into buster-backports and add a custom apt pin for the package. (I'd rather not go the backport route, as that means the backporter needs to always update the upload for security fixes, rather I'd add all patches for bugs into 1.4.5 for buster and ask for a new buster release).

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

Personally I'd use systemd-journald which I think provides the same logging facilities as rsyslog used to, but vyos still runs both. IMO the logging section is a mess and would need a complete rewrite to journal.

Re: logging, DANOS mounts a permanent /var/log at boot (I think it's shared by all images). If any work on logging is going to be done, /var/log should be mounted before any vyos config migration or load is done so it can be used as the destination for logging.

I couldn't find anything in /var/log/vyatta the last few times I've ran into boot-time commit errors. It seems like the python code doesn't log commit errors into a file or syslog, or at least I couldn't find it. I had to log into the console, go into config mode, load the config (usually pre-migration when there are migrator script errors) and commit it, then the errors are printed to the console. Someone can correct me if I'm wrong.

duplicate of T149 ?

I can try to tackle this if noone else is working on it.

https://github.com/vyos/vyos-1x/pull/298

Currently none of the offloading (gro, gso, sg, tso, ufo) settings are checked either at src/conf_mode/interfaces-ethernet.py verify() or in the module python/vyos/ifconfig/ethernet.py. Setting one of these when the driver doesn't support it will result in an unhandled exception. This may not be so disastrous when setting the options in config mode, as the commit will fail due to the exception, but will have more disastrous results when a config which has these options set is loaded into a system with NICs that don't support it - this will cause boot time commit to fail. As per T2158 and PR#272 none of these calls should result in an exception, but rather just print a warning and continue.

This PR still needs to be merged: https://github.com/vyos/vyatta-cfg/pull/23

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.