Already implemented in https://vyos.dev/T4940

technically the limit would be defined by the http header length (and httpd configured allowed header sizes), http basic auth itself has no restrictions in the context of being Base64 encoded.
Often restrictions are from tooling side, not protocol side. I.e Apache htpasswd generated passwords and usernames (under windows) are limited to 255 chars, but again this is a tool limit, not a header limit
(Source: https://httpd.apache.org/docs/2.4/programs/htpasswd.html#restrictions)
256 (255) could be a reasonable value that matches this specific constraint.

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

We use common-generic password which uses limits
We should change it here.
What number of symbols is better to make?

forum post with the same problem: https://forum.vyos.io/t/vyos-1-2-traffic-policy-shaper-match-interface-not-working/8389

exmaple test with shaper policy:

Implemented handling for the CLI command to set a filter by interface(rt_iif).
Implemented a command such as set qos policy limiter test class 10 match test_match interface 'eth1' to generate filters similar to those used in VyOS 1.3.

Upon review, I don't think that this is still an issue any longer in the current rolling release. When saving the config, the effective/running config tree is fetched instead of the session config, and so the incomplete session configuration is not written to disk. The vyatta-bash package also provides a "Warning: you have uncommitted changes that will not be saved." message now when the session has non-committed configuration.

This is not valid for 1.4 and 1.5
Only valid for 1.3 and older images.

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

Thank you, this is my first actual contribution so please feel free let me know if this approach isn't the way you want to do it. If you point me in the right direction, I will implement it however you suggest. I mostly searched the source for other situations where VyOS asks this type of question and copied the idea.

Hey @insignia96
Give it a try and come back if you have questions or doubts
@Viacheslav @dmbaturin can you take a look and suggest if the approach suggested by @insignia96 is ok?

If this could be assigned to me, I am working on a patch that will prompt with ask_yes_no when session_changed() is true of the config, warning the user that the configuration has uncommitted changes and saving it may result in failure to load config on boot.

Thanks for bringing this to our attention @paulywog

I was able to update my router to VyOS 1.5-rolling-202411070006 and my xen vif interface is working once again. Thanks everyone!

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

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

Hi marekm

Needs testing, will be fixed in the next rolling release

@syncer not it doesn’t
JSON parser wasn’t back ported so other branches are not affected

@Viacheslav, does this require a backport?

Is the binary file data/live-build-config/archives/zabbix-official-repo.key.chroot correct? Other key files there are text files.

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...

Please make it possible to load the microde separately (file downloaded directly from CPU vendor, independent of VyOS update) to address the last edge case. Especially important for some Intel CPUs that self-destruct with too high voltage, as update applied too late will not reverse any permanent damage already done.

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.

@paulywog Can you check the latest rolling?