PR: https://github.com/vyos/vyos-1x/pull/3099

Tested in different possibilities:

There is the task for the bug with "backslashes" T5996

Yes, boot\x86\wdsnbp.com is a proper filename, and this further correctly translates to double backslash in the dhcp.conf file at /run/dhcp-server/dhcpd.conf, as I noted. Why it is so, explained for example here: https://www.linkedin.com/pulse/quit-thinking-look-matthew-topper
And with such a setting network boot works just fine.
The problem is that after each reboot the vyos configuration scripts, I guess, double the number of backslashes in the config, that further leads to doubling them in the dhcp.conf. And on, and on. This actually breaks the network boot, and manual intervention is required after each router reboot.

Is "\" really a valid path for bootfile?

The 1.3.x behaviour,

1. VTI interfaces without IPsec is not created

# 1.3
set interfaces vti vti10 address '10.0.0.1/30'
commit

Create the PR without smoketest. This case is not tested.

@c-po, while I don't wish to put words in the mouths of others, I believe the belief is that the interface should stay oper-down.

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

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

Revised PR:
https://github.com/vyos/vyos-1x/pull/3089

kea_parse_leases was deleted in https://github.com/vyos/vyos-1x/commit/c44d24eae276f77c700e961a22c0cd5582416dff
Probably the correct function is kea_get_leases

Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.

Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.

Perfect, that's what I was trying to better understand. Thanks for the clarification!

The regex should be [-_a-zA-Z0-9.\s]+ instead of [-_a-zA-Z0-9\s]+

The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.

PR: https://github.com/vyos/vyos-1x/pull/3088

PR: https://github.com/vyos/vyos-1x/pull/3087

PR: https://github.com/vyos/vyos-1x/pull/3087

For 1.5 fix works as expected

vyos@r4:~$ cat /run/opennhrp/opennhrp.conf
# Created by VyOS - manual changes will be overwritten

works with version 1.5-rolling-202403050022