Updated PR to use multi nodes: https://github.com/vyos/vyos-1x/pull/3202
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
current - https://github.com/vyos/vyos-1x/pull/3195
sagitta - https://github.com/vyos/vyos-1x/pull/3196
Yesterday
Tue, Mar 26
Been digging into this but have hit a block.
Mon, Mar 25
Sure but if the function "port auto-power-down" is mapped to the ethtool function of disabling EEE then it should be safe?
@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.
Sun, Mar 24
disabling it on a per interface basis will still crash the OS if the register read/write is implemented improperly.
Reopened with status "Known issue" due to revert by PR 3177.
To clearify:
Reverted via https://github.com/vyos/vyos-1x/pull/3177
Using igb.EEE=0 or EEE=0 on the kernel commandline has no effect
Sat, Mar 23
Thanks for your reply.
But I have some questions about this situation.
Because it is something different with I knew "version meaning".
Fri, Mar 22
Tags show the code base at the step where the tag was added.
But binary can be changed since this time. For the same reason, you will not be able to build 1.1.8 or 1.2.1, etc. exactly with those binary that were on the step of tagging.
Close it as wonfix.
And remove set protocols static route xxx.xxx.0.0/0 interface pppoe0 unless you use set interfaces pppoe pppoe0 no-default-route.
PR for Sagitta: https://github.com/vyos/vyos-1x/pull/3168
set interfaces pppoe pppoe0 default-route-distance '255'
Wouldnt PPPoE always assign IP dynamically?
In T6140#180604, @Apachez wrote: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.
This way we can find out what the difference is in the request flow (from the client) but also in the response flow (from the server) - in case DHCP would be to be blamed on this behaviour.
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.
In T6140#180242, @pepe wrote:Show this commands output if that happens:
show interfaces pppoe pppoe0 show ip route show log pppoeShow performance test results from versions 1.3 and 1.4
Thu, Mar 21
In T6140#180451, @dongjunbo wrote:The Root Cause is this 'Static routes not working with PPPoE and VyOS 1.4'
https://forum.vyos.io/t/static-routes-not-working-with-pppoe-and-vyos-1-4/14102I
Does the problem only appear after your 5am reboot every day?
Wed, Mar 20
This likely because the global state policy being reintroduced was not accounted for in the firewall check in conf script. I'll check this week.
At least tech-support-archive.tgz MUST not copied between updates
Tue, Mar 19
yeah I had this problem too, also @Viacheslav I think you are right:
Show this commands output if that happens:
show interfaces pppoe pppoe0 show ip route show log pppoe