Pull request: https://github.com/vyos/vyos-1x/pull/353

We saw something similar to this, but it seems like FRR eventually connected to RTRR. I think it has a timeout parameter — is that how often (slowly) it tries to re-establish?

We had this bug earlier today on 1.2.4.

I have made pull request in https://github.com/vyos/vyos-1x/pull/352, please help to review it.

I have made pull request in github, please help to reviw it: https://github.com/vyos/vyos-cloud-init/pull/8

OpenVPN was migrated to a systemd service with auto restart so it's possible it could have fixed this issue. Please retest with latest rolling.

The recent work on openvpn added net30 as an option for "server topology" and marked it as default in the shell value help so at least users should now know it's the default. Personally I'd like the default topology to be subnet but that would mean adding a migrator script for old users who use net30.
It also rewrote some parts of the ifconfig setting logic. This should be retested if it's still an issue.

So if we wanted to not use compat-names because of T2113 the client node names would need to have spaces, I don't know how the config system would handle this? It could probably take a quoted value as the client node, but I'm not sure the shell completion would handle this - it already has problems autocompleting quoted values (for example if you try tab-completing a description with a space in it, you'll see what I mean). Shell completion would very likely break with quoted node names. A workaround could be to remap underscores in the config client node names to spaces for the actual ccd file names. I don't quote like that option, but the alternative would be to have to fix the shell autocompletion for quoted values (better in the big picture but more complex and time consuming), or not fix T2113.

@Dmitry Looks good.

@Viacheslav can you check?

@trae32566 thanks for reporthing the issue so clearly, fix will be in next rolling release

This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved

This is a known Issue on Debian 8 and reported multiple times. As a fix would require rebuilding coreurils we just stick with the debian version. Equuleus has this already resolved

I'd also recommend not using a variable named stdout later on since it's very confusing (easily confused with sys.stdout, which took me a minute to figure out).

I've found that on the most recent releases of VyOS, Netflow flow-accounting is also broken. I've managed to fix the first 2 errors I encountered and verify uacctd is indeed running; however, if IPv6 is used, another error is encountered which I did not fix. I also probably did not fix Sflow entirely with these changes.
Initial error:

vyos@cr01a-vyos# commit
[ system flow-accounting buffer-size 2048 ]

PR for other servers https://github.com/vyos/vyos-1x/pull/350

I can confirm this bug, also exist in 1.2.5 OVA

@UnicronNL not sure where exactly you resolved it but the problem exists till now

Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.

Is 1.2.3 was deployed from OVA or install from ISO?
Which hypervisor?

This is really a good feature i hope i can see this feature in LTS version soon

https://github.com/vyos/vyos-1x/pull/342 should add IPv6 support for all use cases (server, listening socket, p2p, client).

The script now prints a warning on commit if the server client IP is in the pool. There is a new config node for setting the pool start/stop/netmask/disable, if not set, the defaults of openvpn are used.

Some other people reporting similar here.

Yes, that changed it: neither single or double quotes worked previously --- with the change to use crypt(), single quotes around plaintext password with (those) special characters now works; double quoted special characters are still interpreted.

No it's the shell interpreting from Popen (cmd), but you may have already resolved this by using the library function; I'll check.

@jestabro is this probably another case for the CLI input reading discussion we hat the other day about special characters?

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

PR for fixing this issue https://github.com/vyos/vyos-1x/pull/347
After drawing some use cases I will propose to modify auth schema by LUA

As noted earlier in the ticket, this is a problem with the version of ISC DHCPD that VyOS 1.2.x is shipping. It's a very old version.

This issue exists in firmware 6.8 and 7.1.
Starting with 7.1 i can see that the disable command 'sudo ethtool --set-priv-flags <interface name> disable-fw-lldp on' also works.