Seeed reRouter LAN78xx always negotiates to 100Mbs

I'm trying to set up a Seeed reRouter (Rapsberry Pi CM4 based router board that has 2x ethernet ports). I'm struggling to get my Vodafone Gigastation modem/router running in bridge mode to work with the reRouter at 1000Mb/s. The combination of those two ports seems to have trouble negotiating the connection and falls back to 100Mb/s. I'm using bridge mode because my understanding is that I want to avoid double NAT, and I'd like to use Openwrt and Wireguard to connect to my home network. I contacted Vodafone to have them activate something to permit my modem / router to run as a bridge. During this process they mentioned that means I cannot use IPv6.

My connections go:
Gigastation in bridge mode > to reRouter eth0, the built in Raspberry PI ethernet port
reRouter eth1 (second ethernet port, LAN7800 chip on the USB3 bus) > DLink switch
Switch to desktop Mac

Regardless of what I do I cannot get the connection between the bridged Gigastation and the reRouter's USB3 based ethernet device to run at 1000Mb/s. On Openwrt ethtool always reports the speed of eth1 as 100Mb and the lights on the modem's ethernet port stay orange and flash very fast, I never get the green light. Before any connection is made between these two ports, there is at least 30 seconds delay. I suspect because the autonegotiation of speed is not working correctly. The ethernet port on the reRouter shows green and orange lights. Have tried the obvious such as swapping out cables, wiring direct to other devices to eliminate combinations of device and cable. Also less obvious things such as using ethtool to disable auto negotiation. The port stubbornly stays at 100Mb always. If I reverse the physical connections and connect the built in ethernet port to the bridged modem it immediately functions at 1000Mb/s. Suggesting that it's not cables or anything of that sort (right?). Only the connection between Gigastation and eth1 runs slow like this.

I have tried various cables, all of them can handle gigabit between various other devices. I have run the Gigastation in modem mode and it didn't seem to make a difference when connecting to the reRouter. If I take reRouter out the set up and just run the Gigastation as a modem and router it immediately runs the port at 1000MBs (lights function as I would expect with green flashing) so I know the port is physically OK. Have updated the reRouter's onboard CM4 firmware to the latest version. Tried the Openwrt build from the manufacturer (https://github.com/Seeed-Studio/seeed-linux-openwrt) and from official stable. It always results in the same issue.

Currently running Seeed's build:

OpenWrt 22.03.3, r20028-43d71ad93e

I collected some output that might hopefully be relevant:

root@OpenWrt:~# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fd53:cb88:40ef::/48'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth0'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.2.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.docker=interface
network.docker.device='docker0'
network.docker.proto='none'
network.docker.auto='0'
network.@device[1]=device
network.@device[1].type='bridge'
network.@device[1].name='docker0'
network.@device[2]=device
network.@device[2].name='eth0'
network.@device[2].ipv6='0'
network.wan=interface
network.wan.proto='dhcp'
network.wan.device='eth1'

Ethtool showing port stuck at 100Mb/s

root@OpenWrt:~# ethtool eth1
Settings for eth1:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	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
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: pumbag
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

These are the only log messages related to eth1 that I can find:

root@OpenWrt:~# dmesg | grep eth1
[   14.107795] 8021q: adding VLAN 0 to HW filter on device eth1
[   14.107827] lan78xx.napi20201111 2-3:1.0 eth1: kevent 4 may have been dropped
[   51.136399] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  515.143537] 8021q: adding VLAN 0 to HW filter on device eth1

and the driver seems to load:

root@OpenWrt:~# dmesg | grep lan7*
[    7.859733] lan78xx.napi20201111 2-3:1.0 (unnamed net_device) (uninitialized): USB_CFG0 0x60768164
[    8.060245] usbcore: registered new interface driver lan78xx.napi20201111
[   14.065996] br-lan: port 1(eth0) entered blocking state
[   14.071315] br-lan: port 1(eth0) entered disabled state
[   14.082840] br-lan: port 1(eth0) entered blocking state
[   14.088081] br-lan: port 1(eth0) entered forwarding state
[   14.107827] lan78xx.napi20201111 2-3:1.0 eth1: kevent 4 may have been dropped
[   15.112154] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready

The module seems to load:

root@OpenWrt:~# modinfo lan78xx
module:		/lib/modules/5.10.161/lan78xx.ko
license:	GPL
depends:
intree:		Y
name:		lan78xx
vermagic:	5.10.161 SMP mod_unload aarch64

cat /sys/kernel/debug/usb/devices
....
T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.10 Cls=ff(vend.) Sub=00 Prot=ff MxPS= 9 #Cfgs=  1
P:  Vendor=0424 ProdID=7800 Rev= 3.00
S:  Manufacturer=Microchip
S:  Product=LAN7800
S:  SerialNumber=<snip>
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=896mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=lan78xx.napi20201111
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=  16 Ivl=4ms

But still the connection always runs at 100Mb/s :frowning:
If anyone has some suggestion of how to get this working at 1000mbs I'd really appreciate some help at this point!

You could try to swap lan and wan on the OpenWrt side - this is more a workaround, but I agree that it looks as if autonegotiation didn't complete correctly.

Thanks andy for your suggestion. This hasn't fixed things but it has prompted me to troubleshoot further. When I swapped the ports in OpenWRT eth1 still ran at 100mbs, even though it's now connected to the DLink switch.

While playing around with this setup, I tried connecting eth1 directly to a client (macOS) and immediately ethtool reported it working at 1000mb. I noticed that there is a tiny difference in the ethtool output when connected like this:

Link partner advertised pause frame use: Symmetric Receive-only

whereas when the port is running slow at 100mb ethtool reports:

Link partner advertised pause frame use: Symmetric

I wonder if anyone know what's going on there?

This says that the highest advertised speed for the device that is connected to the port is 100Mbps. There are three 'normal' situatoins that would cause this:

  1. The partner device only supports 10/100 and is not actually a gigabit device
  2. The cable is casuing the bottleneck - it may not be a proper 4-pair (8-conductor) cable and/or it may be damaged
  3. The partner device may have a software configruation to cap it at 100Mbps/Full (i.e. turned off auto-negotiate and/or a specific speed setting)

Thanks for the input psherman. FWIW I think I have ruled out those three common situations and my post was more of a question as to what else might cause the port (eth1 / LAN7800 based port) to run slow like this. Based on Andy's suggestion I swapped eth0 and eth1's function, so at the moment eth0 is going to WAN and eth1 to DLink switch, then wired to clients various. I was surprised that eth1 still runs slow like this, as my original theory was that it was problem between eth1 and the ISP's modem.

To verify your situations:

  1. I have tried connecting eth1 directly to a client device, rather than either the switch or modem I was trying before, it runs at 1000mbs. Which was quite a surprise to me today! As soon as I connect eth1 back to the DLink switch it slows down to 100mb again. But the same was true for when it was connected to the modem.

  2. I have tested a few cables, all marked at either CAT5e or 6. I have used these cables to run other ports at 1000mb no problem, so I think cables can be ruled out. But I appreciate that's a pretty common gotcha. I've tried 3 cables, all running other connections at 1000mb no prob. Is it worth e trying any more cables? My gut feeling is no.

  3. Weirdly I can connect eth1 to the DLink switch, and then client device to the switch. The client's port seems to run at 1000mb no problem, but eth1 runs at 100mb when connected like that.

I understand that suggests something is pretty weird here!

I wonder, given that eth1 worked at 1000mb as soon as I connected it directly to the client (i.e. take DLink switch out of the equation), would there be any sense in trying a cross over cable? I realise that's a throwback and reveals my age, and that Gigabit connections should handle the cross over, but I'm running out of ideas at this point!

Any further trouble shooting suggestions would be appreciated...

Connect your Mac to the same port of the switch that you were connecting to eth1. Does it link at 1000?

That seems to run at expected speed when I ran on the mac:

networksetup -getmedia en0
Current: autoselect
Active: 1000baseT <full-duplex flow-control>

It reported the same when connected directly to reRouter's eth1, i.e. when I took switch out of setup and eth1 ran at 1000mb.