How to force 100baseT ethernet

I have a POE splitter that is capable of 100/10 baseT connections. How do I force that WAN connection to be 100baseT? I don't need a Gigabit connection.

I'm running FriendlyWrt on a NanoPi R2S (based on OpenWrt 19.07)

I tried:

root@FriendlyWrt:~# ethtool -s eth0 speed 100 autoneg off
Cannot set new settings: Invalid argument
  not setting speed
  not setting autoneg
root@FriendlyWrt:~#

Also tried changing the advertised modes:

root@FriendlyWrt:~# ethtool -s advertise 0x00f (and 15, 0F, etc)
ethtool: bad command line argument(s)
For more information run ethtool -h

Just to clarify:
I am in an industrial environment.

  • I am connecting 20 NanoPi R2S's as gateways between the plant network and industrial PLCs to collect production data.

  • The switches are standard commercial POE switches that meet IEEE 802.3af or better.

  • The cabling is all CAT6 grade.

The POE splitter is from Adafruit. From the website:
"This is an economical, practical, high-performance, and reliable Isolated 5V 2A PoE Splitter with USB C Plug based on IEEE 802.3af standard. It can divide power and data signals from a network cable and can be used with any PoE injector that is compatible with IEEE 802.3af, and supply power and data for non-PoE network equipment. "

The POE Splitter is not capable of 1Gbps but I do not need that speed. 100Mbs is fine for my application. I have used this splitter with other devices and had no issue but they were 100M ports.

I don't understand why I am getting the error from ethtool? Am I not using it right or are my ports incapable of being reconfigured? How test if either is true??

If your PoE splitter is not capable of 1Gbps, the device connected to it should auto-negotiate to 100Mbps. Is this not happening reliably? or is there some other reason that you want to force the link to 100Mbps vs allowing it to auto-negotiate?

1 Like

Those splitters usually work by using a pair of the ethernet cable wires to carry power. That two wires are not connected to the data lines.

That port simply cannot run in Gbit even if it wanted to, there are not enough electrical contacts for the data lines to do that. It should notice it and auto-negotiate down to 100Mbit automatically.

Do you have connection issues? If you don't have issues you don't need to do anything

2 Likes

The gigabit standard does not require any fallback in case of a two pair connection. That situation is considered a faulty cable, not a valid operational mode. In many cases GbE devices at both ends will fail to connect at all unless the cable is four pair. I would upgrade to a Gb ready power injector.

This is true that gigabit devices are not required to auto negotiate, but many (consumer) devices do indeed include this functionality. So unless the any of the devices in question don’t have this feature, there should be no need to force the link to 100Mbps (but as @mk24 alludes to, both sides must support 100Mbps links - a gigabit device that doesn’t fall back won’t be able to talk to a device that is forced to 100Mbps)

When first connected, Ethernet ports exchange a series of signals over the 1,2 and 3,6 pairs to advertise the speed(s) that they are capable of. Then they will proceed to connect at the highest mutually supported speed.

One end advertising that its maximum is 100 Mb (either because that is its capability, or that is how it is configured) will force the other end to drop to that speed, if it is allowed to. Dropping the speed of a connection below the hardware's capability is based on not advertising a higher speed, not on rejecting attempts to connect at a speed that has been advertised. Configuring the advertised speeds is generally not supported in OpenWrt.

If both ends advertise 1000, then they will both start up a four pair connection at 1000, which will fail if the cable is only two pair (the advertising occurs on two pairs, but the actual connection requires 4). The standard behavior then is to restart the negotiation, which will simply repeat the same failure again.

I don't think this is quite right -- at least not if they both support auto negotiation. This is easy to prove out -- just take 2 gigabit devices such as a router and a switch, router and a computer, switch and a computer, etc. and connect them with a 2 pair cable (or really any cable that does not have all 4 pairs working properly). They will establish a 100Mbps connection as long as the 1-2, 3-6 pairs are working correctly. I know this to be true from my own experience as well as troubleshooting other people's issues.

There are some devices out there that only support gigabit and will not function on anything less than 1000Mbps links. Those devices are relatively uncommon outside of more industrial/provider grade equipment. For example, this Ubiquiti FiberPoE device does not support 10/100 at all, but this is not something most end users would ever need to worry about.

1 Like

Gigabit autoneg will fail because a pair is missing, but the 100 and 10 Mbit are two-pair, if the interface claims it can run in 100/10Mbit then it HAS to be able to run in that mode so it will autoneg at that.

The cheapo chinesium PoE adapters use one pair to transfer power from the injector to the adapter near to the device.

I think it is kinda standard too https://pinoutguide.com/Net/poe_pinout.shtml (Alternative B of IEEE 802.3af standard?)

1 Like

Yes, I have connection issues. I have heard that these POE adapters can cause connection troubles with Gigabit devices. That is why I want to force the device to 100baseT.

Both ends support Gigabit connection. The POE adapter does not. This is a known issue and the accepted solution is to force the device to 100baseT connections max.
My issue is that ethtool is not letting me do that.

I am unable to get a link through the POE splitter. This is a known issue with these kinds of devices. The normal solution is to force the link to 100baseT using ethtool.

You only have to force one end down to 100. Almost any managed switch supports that.

FYI running your command on my 21.02.1 worked fine:

Summary
root@magiatiko:[~]#ethtool -s eth1 speed 100 autoneg off
root@magiatiko:[~]#ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: no
root@magiatiko:[~]#ethtool -s eth1 autoneg on
root@magiatiko:[~]#ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: no

Better seek advice in FriendlyWRT forum.

1 Like

Ethtool is just sending commands to ethernet driver, and if the driver is not smart enough to do autonegotiation to 100Mbit on its own, I'm not surprised it fails to understand ethtool requests.

If that is a nanopi R2S, if you say it works in 21.02 his best bet is probably upgrade the firmware to OpenWrt 21.02 https://openwrt.org/toh/friendlyarm/nanopi_r2s

Yes, just look at the driver. Turning off autoneg is not supported on the R2S eth0 port:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c#n392

Get better hardware or set the config on the switch as @mk24 suggested

It's a RPi4B, sorry I didn't clear it out.

This is where I was going to go next. I can have that done here but it takes time. I might slide home and test that on my own managed switch equipment. Thanks

I see a few options:

  1. If the device is supported by OpenWrt 21.02 (official builds), hopefully the driver supports auto-negotiation and fallback.
  2. Force the other side of the connection to 100Mbps (again, this is dependent on the driver above working properly)
  3. Upgrade your PoE splitter to a gigabit rated 802.3af compliant setup.
  4. insert a gigabit switch between your Friendly device and your PoE adapter, and let it handle the negotiation. This way, your Friendly device connects at gigabit, but the PoE connection will happen at 100Mbps, and the switch is responsible for the stuff in the middle (i.e. forwarding frames between the ports). If you're not using VLANs, a simple gigabit unmanaged switch should do the trick. If VLANs are in the equation, make sure you are using a VLAN aware smart/managed switch.

Thanks for clearing that up. I was able to get IT to reconfigure the switch and that works. Thanks, everyone for your help.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.