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.

GARP is needed for VRRP but the GARP setting is also needed when doing NAT.

Logrotate just renames the logs so that doesnt bring many writes.

Personally I would prefer that the "automagic" firewall ruleset would be done optionally through method described in:

Another good thing is that any logging can be done without spoling the user/pass which otherwise is the case with todays oneliner approach.

Could for example be that set system options logtoram enables the feature while set system options logtoram size 32M sets the desired size where the default is 32M or whatever would be needed as a sane minimum.

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

How come partprobe fails but not partx?

Having support for vhost is handy when you dont want just to blindly share a single documentroot but have the ability to use multiple at a single host.

Hopefully this can be resolved for VyOS 2.0 in the future...

Hopefully this can be resolved for VyOS 2.0 in the future...

Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?

You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?

Related to the list provided in https://vyos.dev/T5706 ?

Instead of "TEST-NET-X" and "TEST-IP-X" it could use "REPLACED-NET-X" and "REPLACED-IP-X" or such (where X defines the unique item thats being replaced).

I think its a bit odd to completely disable EEE where the solution would be to disable EEE by default but having the config option to adjust for EEE if wanted.

Also while at it, the smoketests regarding UPnP should probably be updated by this task aswell since they claim everything is OK:

Wouldnt this rather be a task for secure60 to add compatability to parse and understand snmp and syslog received from a VyOS device?

"hw-id" should define which physical interface is mapped to which ethX VyOS interface.

Wouldnt this break things with compatibility with other vendors?

I agree, even if its "odd" at first sight I like that all interfaces are named ethX within VyOS and then its a matter to map each to physical interface by hw-id (which is done automagically during first install but can be remapped if wanted).

Does all the interfaces at bananapi represent a hw-id which can be used to map to the ethX syntax of VyOS?

The fear of having the HTTP-API part of nginx compromised by another virtualhost config (as in they are sharing the same process) should be overcome by having a dedicated config file and start a 2nd nginx process.

I would vote for that (using nginx as backend since it already exists).

Instead of "file-server" I think "http-server" would be a better name or even "web-server" in this context.

Verified with VyOS 1.5-rolling-202311081451.

I would mainly want to log new conntrack entries for various reasons.

Do you have any example of in which context that exists?

In that PR, shouldnt also ifb* be included?

Shouldnt dummy* and some others be excluded aswell?

@shthead: Im talking about features in VyOS. I dont care what others such as Juniper does or doesnt do.