PR for this task
https://github.com/vyos/vyos-build/pull/97
https://github.com/vyos/vyos-1x/pull/274

Add show commands for multicast/igmp/pim

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

Thanks - understood.

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.

Hi jjakob, AFAICS the patch above should have fixed any problem with the ethtool. If not I will need to understand why.

Good catch!

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.

@jjakob I had that discussion with @thomas-mangin already - the best solution would be a dynamic probe via ethtool in verify()

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.

was this was not already fixed ?
https://github.com/vyos/vyos-1x/commit/8f39784c847801c0b766a0c9289da0976ffd0604#diff-ca1457dc16e0b9a43de02cf08140b65aR123

let me try to put a quick patch for you.

we can fix it in two ways: undo the commit which check the return code of the program, hiding the issue and add a first BIG PRINT warning stage or find the root cause and fix it (harder).

Can you send me your previous config.boot file prior of the upgrade? I'm happy to take a look

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.

I'll open a new task for it.

Oh, I see my changes were already pulled in, missed that!

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.

In T2158#56542, @jjakob wrote:

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.

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.

I'm not expecting a persisted-across-reboots FRR config — hence suggesting tmpfs — so when the system boots there is nothing there. Obviously something would need to create the (empty) FRR config files in tmpfs before running FRR, otherwise I expect all the FRR daemons will fail to start.

A router reboot last week reminded me to never to write mem in vtysh (but after looking it was automatic bij me :( )
The router booted with the configuration in FRR already loaded, and then Vyos tried to populate FRR based on the Vyos configuration and everything was broken :-)
It didn't help that the configuration i saved in FRR was a couple of months old.

We've seen this recently on bleeding-edge (yesterday's version) of 1.3. I'm currently investigating what tripped ospf6d, but I suspect it's going to be some Ubiquiti routers spewing their nasty OSPFv3 implementation.

ok, thanks! I can test on xen aswell, when the fix is in 1.3/rolling.

This fix is for 1.3 rolling only and should not be a problem on 1.2 as long as users do not explicitly set speed/duplex.

does this also affect vyos 1.2, or only 1.3/rolling?

also all calls to start-stop-daemon need to have a --oknodo option added

The code should be in the op-mode script rather than the class.But the PR was merged in, so I suppose it's ok.

https://github.com/vyos/vyos-1x/pull/263
https://github.com/vyos/vyatta-cfg-system/pull/121

PR262 should fix that last one @alien

I believe your default settings are not bad as, in our case, we are part of the ntp pool and our kit will use our own NTP servers :-)

Hello,
It's been a long time since the last comment.
Are there any real plans to add NETFLOW module to the next version (rolling release) ?
@mickvav Are you still using VyOS and this module? Would you be able to send me a version for 4.19.112-amd64-vyos ?

Deletion should be possible with tomorrows rolling release.

pushed https://github.com/vyos/vyos-1x/pull/261 which should fix the issue.
@lluu131 if you know how to use vi and only if you are sure you can run:

sudo vi /usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py +123

and you change CalledProcessError with RuntimeError

Please provide the VyOS version used

PR260 should fix this