Accidentally committed a crux fix with https://github.com/vyos/vyos-1x/commit/920d87447ca479c311102260e5816ec0f5268a9b

Hi @jack9603301 your PRs are much appreciated but triggering my eMail inbox won't get your stuff merged faster - it actually will be quiet the opposite as I think you will trigger me again when it's urgent.

Sorry on behalf of the team. The process of PR review is not ideal. I appreciate that you have asked for merge, and would be probably expecting some feedback As it was not, and that you got neither yet. I know it can be a bit frustrating .. I also have PRs waiting! 🥱
Hopefully there will be more regular review going forward, in the meanwhile please be assured that your contribution is appreciated and again sorry for the wait.

@c-po This PR has been open for several days, requesting a merge

@c-po This PR has been open for several days, requesting a merge

@c-po This PR has been open for several days, requesting a merge

Resolved via T2653

Yes, I have migrated this a long time ago

It does param "verbose" in the check.
https://github.com/vyos/vyatta-cfg-quagga/blob/current/templates/protocols/static/route6/node.def#L4

Fixed, VyOS 1.3-rolling-202007240117

It reproducible in VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

A workaround is in place for this

https://github.com/FRRouting/frr/issues/6797 Opened an issue with FRR.

@thomas-mangin Thanks. I've joined the channel yesterday. It'll be fine for asking around every now and then.

PR for crux https://github.com/vyos/vyatta-cfg-quagga/pull/53

@efficiosoft understood. We tend to all hangout there to help each other. If you have another way I/we can relate to you to support you (but here) let us know.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/52

I thought the problem could be related to VyOS, but now I have found the same behavior when using directly tc hfsc.

VyOS 1.3-rolling-202007240117

Fixed.

VyOS 1.3-rolling-202007240117

https://phabricator.vyos.net/T2653

Well I think its not necessary to change this back - we rather should extend the smoketests to detect those errors!

I will check next couple of days

This is expected as disabling an ethernet interface is different than any other interface, they're still present but just put admin down. All other interfaces get deleted and thus throw this error.

Oh - I'm sorry - I mixed up the lines in the kernel. The patch is actually in VyOS.

@c-po Thank you for clarifying. I guess I misinterpreted what i read on patchwork. I'd be eager to test a kernel with the patch!

@fetzerms the mentioned patch is not included in the mainline kernel!

Also happens with 4.19.131-amd64-vyos - I guess that patch mentioned by @Viacheslav is either not included or not solving the problem.

@elbandi can you check it on the latest rolling release?

With ethernet works fine, VyOS 1.3-rolling-202007230117

vyos@r1-roll:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             192.168.122.11/24                 u/u  
eth1             -                                 A/D

Fixed, VyOS 1.3-rolling-202007230117

@suuei Can you try the lateset Rolling release?

Currently, we don't have the option "link" in vxlan which was provided in config.

As workaround

Fixed.

vyos@r1-roll:~$ show vpn remote-access 
No active remote access VPN sessions
vyos@r1-roll:~$ 
vyos@r1-roll:~$ show version

Fixed, VyOS 1.3-rolling-202007230117

Fixed, VyOS 1.3-rolling-202007230117

set interfaces tunnel tun16 encapsulation ip6ip6
set interfaces tunnel tun16 local-ip 2001:db8:aa::16
set interfaces tunnel tun16 remote-ip 2001:db8:aa::26
set interfaces tunnel tun16 address 2001:db8:bb::6/64
commit

@c-po Request merge

@c-po Request merge

@c-po Request merge

With that replace I see this is an error in each commit

PR https://github.com/vyos/vyatta-cfg-system/pull/126

I replace

my $cmd = "curl -#";

to

my $cmd = "curl --insecure -#";

No, not yet. But generally I don't like it too much because I'm blind and their desktop client isn't very accessible, and writing things like code examples on a smartphone, well, is something I try to avoid ;-).

@efficiosoft are you on our slack channel ?

Yes, it would be a solution. However the behaviour the daemon should really be "fixed" when loaded. It may be simpler to have a reload feature on SIGHUP. This would allow changing the file on disk when developing, testing it without breaking things, and only when confident that it is right, then asking for the reload.

Well, it would be trivial to add an --auto-reload switch to the daemon for development purposes which could enable an inotify watcher over the XML files.

Fixed

It's impossible without re-adding network driver (modprobe -r xxx; modprobe xxx)