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.

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

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

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.

@c-po this is just DHCP-client in this case, Windows, Linux or VPC (Virtual PC).

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.

@trae32566 the reason I used the call is b/c it was the call used in VyOS 1.2 - no particular reason to not look into crypt()

@Dmitry how can I test the IPoE server? Is there a client for Windows or a "howto"?

Any reason in particular you're not using crypt.crypt() here?

Still facing the issue of two initrd images for building iso using latest latest crux branch. Using this kernel rebuilding steps https://wiki.vyos.net/wiki/Rebuild_VyOS_kernel_Step#VyOS_1.2.x

I'm seeing this in Vyos 1.2.5 just released:

I've just encountered this bug with Vyos 1.2.5 (final, official ISO)

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

Improve op-mode commands for ipoe-server
https://github.com/vyos/vyos-1x/pull/344

vyos@vyos:~$ show ipoe-server sessions 
ifname | username |    calling-sid    |     ip     | rate-limit | type | comp | state  |  uptime  
--------+----------+-------------------+------------+------------+------+------+--------+----------
 ipoe0  |          | 00:50:79:66:68:09 | 100.64.0.2 |            | ipoe |      | active | 00:00:11 
 ipoe1  |          | 00:50:79:66:68:0a | 100.64.0.3 |            | ipoe |      | active | 00:00:09

These 2 PR are needed for new xml format

thanks for explaining the backgrounds! I wonder if a removal of the hostfile-update option should be suggested.

@adestis The status 'Backport Candidate' indicates the intention to include it in 1.2.x; I may have mistakenly removed the specific project (1.2.6) when I changed the status.

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.

Found the culprit.

@jestabro you removed VyOS 1.2.6 does this mean it will not be included in 1.2.x ?