For KEA6 its defined as "The IPv6 address of a TFTP server" with example of IPv6-address:

If its common of this misuse of option66 I would suggest that VyOS would allow for URI characters (@, :, / and what else) but type a warning during re/config like:

@syncer Yeah, it was at the forum:

DHCP option 66 is not intended to carry an HTTP URL. According to RFC 2132, option 66 is specifically designed to provide the TFTP (Trivial File Transfer Protocol) server name, typically used to specify a hostname or IP address of a server from which the client can download a boot file via TFTP, not HTTP.

Interesting interpretation of the standard. Guess it's time to go bare metal again

can be ipv4 or hostname

This is not a bug, this is according to RFC

This is not a bug, this is according to RFC
@Apachez I recall you have cited it but do not recall where it was here or at the forum

Clarification: this was in fact a consequence of the cleanup here:
https://github.com/vyos/vyos-build/commit/d50707bb295dbd4bc50e3d0301fc8be605448429
not the cleanup of deprecated packages, consequently, the solution is simpler: simply revert the above. As previously mentioned, although this is not used by new installs, the file is expected to exist in a new image, when doing a compatibility-mode update from a system with legacy image tools. If the legacy images are subsequently removed from the system, the new image tools will switch out of compatibility mode, at which point the file is no longer needed.

This has a simple solution, and was an artifact of the much welcomed retirement of the packages vyatta-cfg-system and vyatta-op (T6527). One missing file is needed from the retired packages: since the legacy update tools look for a small number of scripts in the mounted image of the new image, a few need to be available for legacy compatibility. PR in preparation.

In T6870#207379, @Viacheslav wrote:

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

When you create a bug, the most important thing is that it should be possible to tell if it's fixed.

You should include the following information:

    A sequence of configuration commands or a complete configuration file is required to recreate a setup where the bug occurs. Please avoid partial configs: a sequence of commands is easy to paste into the console, a complete config is easy to load in a VM, and a partial config is neither! At least not until we implement a "merge from the CLI" feature that allows pasting config file chunks into a session.

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

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

Hi marekm

BTW @SteveP these iperf speeds look quite impressive, I thought USB overhead would make it difficult to see much more than 1 Gbps in practice. Realtek was traditionally a "low cost, low performance" brand, it seems they have made a lot of progress...

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

I created a separated bug report https://vyos.dev/T6856

Where does this leave us?

Ah, does that explain what I commented on earlier?

I'm going to close PR, https://github.com/vyos/vyos-build/pull/832#pullrequestreview-2420618828

I'll let you know.

@SteveP Thanks!
I created a PR to exclude these rules https://github.com/vyos/vyos-build/pull/832

It seems to be the 50-usb-realtek-net.rules file causing the strange behaviour.

This version has a 6.9.0 section so you would think it would also cover 6.6.x

New version 2.19.2 same problem!

I'm inclined to say that there's no case for it, especially when VyOS Stream images start offering a semi-stable preview version, so that tools can work with the API thatis close to the upcoming LTS, rather than chase the changes in the rolling release where anything may change at any time.