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

I don't have a RADIUS server handy for testing right now, but radius_user and radius_priv_user are both missing membership to the _kea group as well.

Have installed 1.5-rolling-202403200018 in a VM as a clean install (no prior configs) to dig at this but have hit a block.

@dmbaturin was this completed already?

Yes, as described in the issue, using dynamically added routes works fine. But I want to add the routes manually as I did before with the 1.3.x release.
Using both automatically added routes from PPPoE and setting them statically does not sound like a "sane" config to me.

I have also created a pull request that fixes this issue: https://github.com/vyos/vyos-build/pull/543

Delete set interfaces pppoe pppoe0 no-default-route will let it works. it is the same issue.

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

PR for current: https://github.com/vyos/vyos-1x/pull/3188

Comments can be set via the API with the following request format:

@jestabro Thanks, a solution definitely seems close.

@L0crian thanks for the details: c-po's PR is part of the solution, but there is more to the story, as you point out.

In T5991#181120, @Viacheslav wrote:

It is not an actual ethernet interface, but you name it as an ethernet interface.
You can check the output sudo ip link show type wireguard or sudo ip link show type tun

It is not an actual ethernet interface, but you name it as an ethernet interface.
You can check the output sudo ip link show type wireguard or sudo ip link show type tun

I tested https://github.com/vyos/vyos-1x/pull/3173 today, and it definitely helps the original use-case of this task. Configuration calling interfaces that come up post-boot, like those installed from a container, persist. The one problem is the interface level config is still deleted on-boot from some check that is performed.

@tjh already backported

In https://www.rfc-editor.org/rfc/rfc2181#section-11

This is still an issue for 1.4.0-epa2.

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

This is how the PKI subsystem works. You should add the LE root certificates manually so we can build a full chain using the internal PKI tools for HTTPS server.

disabling it on a per interface basis will still crash the OS if the register read/write is implemented improperly.

What about OSPF,OSPFv3 and the other routing daemons?

confirmed fixed in 1.5-rolling-202403240925

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

To clearify:

Thanks will test the next release

This pretty much feels like the same issue - a fix will be present in the next 1.5 rolling release.

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

hardware details below

In theory that could work as a workaround as-well, it would be more precise than my current workaround, but would require the build process for my tool to download the iso, spin up a vm, and extract the info.

Sounds interesting but isn't it enough to query dpkg?

Reverted via https://github.com/vyos/vyos-1x/pull/3177

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

Using igb.EEE=0 or EEE=0 on the kernel commandline has no effect

My best bet would be an issue with reading back the EEE registers of the Realtek r8169 driver.

In T6162#180836, @Apachez wrote:

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

Well sure but did you file a case and send the commit to Intel aswell?

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