I'm building OpenWRT from source. Currently using SNAPSHOT r7093-4fdc6ca running on a WRT3200ACM.
The problem I'm having is with an old SURFboard SB6121 cable modem. The modem uses a 100mbps ethernet connection. When I connect it to the WAN port on the router there is absolutely no data flowing whatsoever and it appears that the WAN port is stuck at 1gbps or something. If I put the modem and WAN port on a 100mbps switch or hub then everything works. So it appears to be some sort of link speed negotiation failure.
If I remember correctly the stock LinkSys firmware worked fine with the modem.
Is there a way to force the WAN port to 100mbps or otherwise fix the negotiation? I've tried some of the basic methods and nothing is able to change the link speed on the router. Sorry it was a few weeks ago when I last tried and I forgot which commands I have tried. Any hints would be appreciated.
I believe that ethtool should be your friend here.
Something along the lines of
ethtool -s eth1 speed 100Mb/s autoneg off duplex full
should do the trick. BUT better first look what the current settings are by running
I assume that eth1 is the actual ethernet device for your wan interface, you can use the following command to confirm that:
ifstatus wan | grep -e "device":
Thanks! Yes, ethtool is what I was playing with. When I tried before I wasn't turning off autoneg which is why it was rejecting changes.
Unfortunately even though I can set a new speed now it still doesn't work. No data. It's not getting errors either. It detects the link but communication between the modem and router isn't working at all. Very difficult to troubleshoot because normally I would stick a hub in between them so I could debug on a 3rd machine but in this situation when I do that it makes everything start working... eh
Well, can you post the output of "ethtool eth1" or whatever your wan interface is? I had issues in the past with EEE (https://en.wikipedia.org/wiki/Energy-Efficient_Ethernet) which I could work around with ethtool, but I fail to remember any details. But this might not be related at all with your troubles.... sorry.
This is with autoneg off, speed set to 100, connected to a 100Mbps switch, and working:
type or Settings for eth1:
Supported ports: [ MII ]
Supported link modes: 1000baseX/Full
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Supports Wake-on: d
Link detected: yes
paste code here
The output is identical when connected directly to the router and not working.
It's weird. I've never had a problem connecting this modem to anything else. I may have to go back to the LinkSys firmware and see if I can figure out what it's doing differently. I hate to do that though, such a pain.
Mmmh, maybe the issue is that you need autonegotiation (say if you have a straight instead of a cross-over cable, but you also need to restrict the speed)
ethtool eth1 -s advertise 0x008
From man ethtool:
Allows changing some or all settings of the specified network device. All following options only apply if -s was
Set speed in Mb/s. ethtool with just the device name as an argument will show you the supported device
Sets full or half duplex mode.
Selects device port.
Selects MDI-X mode for port. May be used to override the automatic detection feature of most adapters. An ar‐
gument of auto means automatic detection of MDI status, on forces MDI-X (crossover) mode, while off means MDI
(straight through) mode. The driver should guarantee that this command takes effect immediately, and if nec‐
essary may reset the link to cause the change to take effect.
Specifies whether autonegotiation should be enabled. Autonegotiation is enabled by default, but in some net‐
work devices may have trouble with it, so you can disable it if really necessary.
Sets the speed and duplex advertised by autonegotiation. The argument is a hexadecimal value using one or a
combination of the following values:
0x001 10baseT Half
0x002 10baseT Full
0x004 100baseT Half
0x008 100baseT Full
0x010 1000baseT Half (not supported by IEEE standards)
0x020 1000baseT Full
0x20000 1000baseKX Full
0x8000 2500baseX Full (not supported by IEEE standards)
0x1000 10000baseT Full
0x40000 10000baseKX4 Full
0x80000 10000baseKR Full
0x200000 20000baseMLD2 Full (not supported by IEEE standards)
0x400000 20000baseKR2 Full (not supported by IEEE standards)
0x800000 40000baseKR4 Full
0x1000000 40000baseCR4 Full
0x2000000 40000baseSR4 Full
0x4000000 40000baseLR4 Full
Maybe that does the trick, assuming that eth1 is your wan interface
So this is not 100Mbps, but still gigabit ethernet, I guess I gave a wrong command it should be:
ethtool -s eth1 speed 100 autoneg off duplex full
But potentially your problem is not so much the autonegotiation of the bandwidth but rather the wrong cable (see https://en.wikipedia.org/wiki/Medium-dependent_interface) at least I see no "MDI-X: on" as part of your ethtool output indicating that the ethernet port might not do this. Under that hypothesis the switch might help as it might do the MDI-X thereby fixing your issue... just a hypothesis though. (Says the man that once spend an hour trying to get a link to operate at 1000Mbps with ethtool and friends before realizing that the 4-wire cable connecting the devices under test simply was lacking the additional 4 wires for gigabit ethernet....)
You got it! Using a crossover cable makes it work. Well that's still weird because I haven't seen a modern ethernet chipset that didn't do MDI, ever... It has been so long that I totally forgot about it and had to dig the crossover cable out of an ancient box of 10Mbps hardware, ha!
I believe the hardware must support it but OpenWRT isn't doing whatever needs to be done. The LinkSys software must be using some special setting/firmware that turns it on. Maybe the modem doesn't support MDI so the router has to try something abnormal to get it to work.
Who knows. Whatever the case, it works with the right cable so I'm not worried about it. Thanks for your help! I never would have figured it out otherwise.
If your problem is solved, please consider marking this topic as [Solved].