Hi I want to force eth0 to: Full duplex - 1000Mbit/s.
And if this speed can not be negotiated I want the connection to drop.
How can I configure this? And make it persistent across reboots?
Thanks in advance! ~kwinz
1 Like
I don't think you can, especially not with 1000BASE-T, which heavily depends on auto-negotiation (for pretty basic functionality already, such as auto MDI-X). Obviously 'anything' can be done somehow with access to the source, chewing gum and some duct tape, but I wouldn't expect any ready-made procedures to be in place.
This answer is very surprising to me! This has worked so far on every distro that I tried and every hardware that I tried is capable of letting you either force a speed, or change the list of advertised speeds for autonegotiation. Commonly with the GUI, ifupdown scripts, NetworkManager, mii-tool or ethtool.
So what you are saying is I can not do this via LuCI? But there must be another way to configure this!
1 Like
You do realize the flash sizes commonly found on typical plastic routers used for OpenWrt?
Neither ethtool not mii-tool are installed by default (although they are installable), but their settings don't persist over a reboot.
Feel free to prove me wrong, if you find it somewhere in netifd/ uci - great, if not - start with the chewing gum and duct tape to get it supported, bonus points for getting it merged into OpenWrt.
--
Usually the hardware phy knows best what it can do over the given cable, if not - fix the cable or the driver. Blindly forcing a connection speed the auto-negotiation rejects rarely leads to happiness.
1 Like
Hi slh, I appreciate it! I am not here to prove you wrong. I am asking for advice if this is already built into OpenWRT (it seems not). And if not, then what would be the most native, dogmatic way to do it on OpenWRT?
Yes, worst case I can probably find ethtool in a package and use that. I still have more than enough flash space
Is there a script that runs on bootup or as the interface comes up where I would put an ethtool call?
Cheers, ~kwinz
You could look at a hotplug script that triggers on ifup/ifdown. /etc/hotplug.d/iface for examples, but as @slh notes, I think you'll end up chasing your own tail.
1 Like
Ethtool-full is a pretty well used port manipulator in our developememt for the realtek switches.
Especially for the SFP settings, inkl speed.
But in Luci I don’t know of any tool interface to manipulate port settings, ethtool-full is run in uci environment.
But I don’t know of hardware and driver support do manipulate ports in home equipment either. The Realtek switches are business class smart managed switches so the hardware supports is that also, and the price tag is at least equivalent of 2-3home routers.
But why do you need to force eth speed to begin with?
1 Like
But why do you need to force eth speed to begin with?
I would rather the link go completely down and trigger an alarm, than it degrading unnoticed to 100M because of a bad cable or something. I had that happen to me not too long ago and I don't want this to happen again.
Why not trigger an alarm if the link is at 100Mbps. You can theoretically probe the link speed and trigger an action... but at least then you would still have connectivity.
Aside from all of that, is there a specific reason you need to force the OpenWrt side of the link? What about forcing the other side of the link to 1G speeds -- it would similarly fail if the cable causes a fallback to 100M.
Anyway, if you want to add some hardware to the mix for a brute force approach -- you could connect a device that cannot work at anything other than gigabit speeds. There aren't many such devices, but there are a few esoteric applications where such products exist and are useful -- such as this one aimed at the WISP market. Put this in place and the link would theoretically fail entirely if it can't negotiate.
1 Like
My OpenWRT install is on a x86 build with Intel NIC. I am 100% sure it can support fixing the link speed. This is not an issue.
I tried fixing the speed on the DGS-1510-28X switch first but it has a firmware bug. The Dlink support team is currently working on a fix.
Why not trigger an alarm if the link is at 100Mbps. You can theoretically probe the link speed and trigger an action... but at least then you would still have connectivity.
I already have scripts in place to alarm on link down. Probing the link speed would be just more complicated.
It may be more complicated than detecting link down, but possibly less complicated than forcing the link to 1G. Food for thought.
1 Like
Just to give an update:
After installing the ethtool package I was able to force 1000M speed.
What did not work was creating a script in /etc/init.d/ to set the speed.
It would work for some interfaces but not for others.
What did reliably work was creating a script in /etc/hotplug.d/iface/ as suggested by @RuralRoots
root@OpenWrt:~# cat /etc/hotplug.d/iface/06-forceethspeed
#!/bin/sh
logger "forcing-eth-speed-from-hotplug"
ethtool -s eth0 speed 1000 duplex full autoneg on
ethtool -s eth4 speed 1000 duplex full autoneg on
Substitute eth0 and eth4 with your interface names or get the interface names from the defined constants. This would be cleaner and doesn't unnecessarily set the the speed, but I didn't bother with the defines.
That script doesn't even have to have the executable bit.
PS: The bug in the D-Link switch mentioned above was also fixed (in FW Build 1.70.B035).
1 Like
This thread that I just discovered after the fact could also be helpful: How to make ethtool setting persistent on br-lan - #13 by mindwolf
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.