I sure hope this custom waagent build will be removed once the upstream (debian packages) have been updated with this fix.

Personally I thing there should be a difference between setting PKI manually like set pki certificate and set pki ca vs whatever the command is to utilize letsencrypt or acme or whatever they might be called automatically through VyOS (lets say set pki letsencrypt and set pki acme etc).

Care to elaborate some on that "data integrity issues" claim since you will have integrity changed by all sort of writes (atomic or not)?

There are 2 usecases of option82 when it comes to DHCP:

The suggested change as in matching number of "x" with number of characters in each octet/hextet in the IPv4/IPv6 address will be less anonymizing than todays method.

Care to elaborate on why this became "wontfix"?

Because not all netadmins sits physically close to the devices being managed.

Yes but this is what the peer would do on its own - if the opposite device is lost in connectivity it can rollback to previous config which is enabled by default (that is history of configs).

This can be handled just like "how others does it" as in if the peer is lost after a sync then the peer will automatically return to previous config.

Please paste exact VyOS versions you have tested this with incl the config (in full or partial output of show config command | strip-private) of both VyOS and the opposite side.

Also the config section could perhaps be name "custom" (with subsections) so that section will survive an upgrade aswell - otherwise config lines will vanish during boot/commit.

Just dont, please see my comment fro april 2024.

I assume that workaround would only work for a single VRF or can one do something like this?

I think a warning is better than to block it from being set, specially since the workaround to load it through already existing config still remains.

In T5835#187963, @dylanneild wrote:

If I had to recommend anything, it'd be that VyOS just remove UPnP completely. What is included doesn't work (or didn't when I last checked) and the attitude from the VyOS community seems to be that it's not wanted/needed anyways.

Could this perhaps be extended into something like this in the help of the command and documentation?

In T5835#187927, @syncer wrote:

I fail to comprehend how a firewall that autonomously opens ports via calls from internal networks is appropriate for an enterprise.
Indeed there are some use cases but this functionality can be used by malicious code and allow bypass security configuration that is enforced otherwise

In T5835#187927, @syncer wrote:

I fail to comprehend how a firewall that autonomously opens ports via calls from internal networks is appropriate for an enterprise.
Indeed there are some use cases but this functionality can be used by malicious code and allow bypass security configuration that is enforced otherwise

I have rarely seen UPnP in enterprise environments and rarely at home even if the main purpose is to use it at home and let applications backdoor your firewall (which often is a bad thing in enterprise evironments).

As already commented in the PR itself:

Just so I dont get the vocabulary wrong here...

Ill put it into "known issue" since IMHO a complete "resolved" would be when this feature exists in config-mode aswell.

The thing is that adding this as op-mode only doesnt really solve anything.

Also NAT-rules are in the need of a resequence feature in the config-mode:

I dont think this is resolved.

When/If doing so it would be great if the docs would suggest for alternative methods to achieve the same thing.

It can be handy to have the option to have it disabled (or you can just in bash-mode do "apt-get remove intel-microcode --purge" if you dont want it after install) but it should be enabled by default due to security reasons.

Shouldnt this be adjusted in more files and places?

@peter, did you try various offloading settings for the NIC being used with reboots in between?

NETNS was removed from the 1.4 series the other day so hopefully that feature can be worked on for 1.5 since its needed:

For added service when typing just:

You would still be limited to not be able to use " as part of your password.

Probably related: https://vyos.dev/T5388

Perhaps those changes should be within the firewall context?

Im thinking since sysctl can be changed after the system have completed its boot shouldnt the "system sysctl" be runned among the last tasks according to "/usr/libexec/vyos/priority.py", which would also fix this issue ?

Note that "base_reachable_time_ms" is still valid while "base_reachable_time" is obsolete.

I sent a question to ISC regarding https://www.isc.org/blogs/dhcp-client-relay-eom/ and:

I have asked the OP @canoziia to provide such in the forum.

I can only refer to whats unfolded on the forum at https://forum.vyos.io/t/how-to-set-net-ipv6-neigh-etha-b-base-reachable-time-in-vyos/14304

Perhaps Im missing something here but where is Option82 information included (injected into the DCHP-request reaching the DHCP-server)?

Here is a post from an OPNsense forum administrator in august 2023 (dunno if the below is still valid for OPNsense):

When evaluating proper replacement (other than choosing the best one for the task) another thing to consider is, if possible, to select something that not everybody else uses in terms of if/when a vuln is found in that softrware then not ALL vendors are affected at once.

It would be handy if the GARP announcement wouldnt be a separate list but rather picked up from any DNAT or SNAT rules.

Probably related:

How is this supposed to work?

Will a migrationsscript be included so that users who used the default of:

Will a migrationsscript be included so that users who used the default of:

You can do the QoS priority on the VyOS by matching the traffic based on VLAN ID and then set the DSCP (TOS) using "set-dscp" according to the manuals below:

You mean you want QoS based on VLAN which is named 802.1p ?

According to https://community.intel.com/t5/Ethernet-Products/XXV710-V2-NIC-doesn-t-support-quot-ethtool-m-quot-Is-this-a-bug/m-p/730841 you need to:

In T6221#182954, @fetzerms wrote:

I only created a vrf (but did not assign it to anything else). Is that intend to break connectivity?

Thats common with other vendors aswell.

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Personally I dont think its a good idea to be able to use VyOS as a jumphost towards victims of scanning.

I think the wrapping should be left for the output to select since you can either be in a regular serialconsole of 80x25 or some highresmode which brings more characters per line or even through SSH with a 4k monitor which will be plenty of lines.

Since descriptions can be very long I assume there will be a linewrap at the end?

Sure but if the function "port auto-power-down" is mapped to the ethtool function of disabling EEE then it should be safe?

Reopened with status "Known issue" due to revert by PR 3177.

To clearify:

In T6162#180827, @ErnyTech wrote:

In T6162#180826, @Apachez wrote:

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?

This is up to Intel as far as I know

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

Wouldnt PPPoE always assign IP dynamically?

Comparing to other vendors setting the password either in cleartext or as a salted hash (where when saved in config file its always saved as a salted hash - but it will accept a cleartext edition too if you wish that for whatever reason) through the CLI is the standard in NOS.

Also since dynamic and not static IP is being used it would be handy if the DHCP exchange can be captured using tcpdump and do this both on the 1.3 where this works and on 1.4/1.5 where this doesnt work.

Proper would be to throw out chrony and use ntpsec instead which supports proper filtering.

There do already exists tasks regarding commit and boot times such as: https://vyos.dev/T5388

I wouldnt call 1m37s of commit time for a single line of configchange as "resolved"...

Also probably related: https://forum.vyos.io/t/long-commit-time-for-multiple-vrfs/14053

Is this related to the long commit and boot times when one have more than a handful routes or firewall rules as described in https://vyos.dev/T5388 ?

1.3.3 and rolling from 2020?

While at it, whats the configured response time in nginx?

Is "\" really a valid path for bootfile?

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

Instead of that sysrq stuff, how does it work if you try these 3 tests?

If the peer reconnects after the first disconnect - does the local VTI interface go "UP" again?

How do one re-open? :-)

Similar task(s):

While at it having a description for a firewall rule within the firewall itself thats longer than 256 is just "wrong" IMHO aka "you are doing it wrong".

In T5619#177706, @ErnyTech wrote:

Unfortunately I haven't seen this before, for me this choice of using the out-of-tree driver is extremely wrong!

Most of the community's development is done on the mainline kernel driver (where among other things I'm working on sending patches to improve the ixgbe driver), if there are issues in the mainline driver they should be reported or resolved with a patch to be applied in vyos downstream and then send it to the Intel-wired-lan mailing list.

Please @samip537 can you tell me in a short list what exactly problems you encounter with the mainline Linux driver?

Adding https://forum.vyos.io/t/quick-and-dirty-benchmark-of-cores-vs-mhz/13831/ for reference which also concludes that something is off with the commit and boot times of VyOS.

Its mainly a headsup for maintainers to go through the report and fix whats possible.

Its not clear if its fixed or not:

Same as with https://vyos.dev/T5619.

Related?

Again, notifing upstream (or downstream) is not only about VRRP.