root@OpenWrt:~# ethtool lan2
Settings for lan2:
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: 2
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
my rpi5 (htpc) on lan1:
Settings for lan1:
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
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Transmit-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
dangowrt mentioned that some link partners might have problems, but i assume its something different then what i reported because i had problems on client side. guillo seems to have problems on all lan ports after using that 100mbit device?
That would be bad and should probably be considered a bug.
If you have one 100 Mbit device plugged into the switch, you’d normally expect other devices to still run a 1Gbit if they are capable.
who all have this issue can you please show ethtool like @oli did for the port having a 1G client while having 100M client on another port? just to nail this a bit down (advertisement issue should be fixed, but maybe it is another one)
@oli can you do 1G bidirectional traffic to the rpi5?
so seems like i was not having this problem anymore because i was using eth1 (sfp-rj45 adapter) to connect my workstation. so this bug is still open then
Skimmed through the thread. If I read it correctly, when you have one client (A) physically limited to 100Mbps and connected to R4’s switch. A second client (B) capable of 1Gbps and connected to R4’s switch. The problem is client B will transmit at 100Mbps instead of 1Gbps.
If you have a third client (C, say Win PC) capable to 1Gbps. Could you test: set client C to limit by software to 100Mbps. Connect client C to R4’s switch in place of client A. Now for client B, does it still only able to transmit at 100Mbps ?
whats the purpose of this test? i dont want to mess around anymore with my ethernet cable (from/to my workstation) as its already so fcked that i often lose connection. so if you are a developer and need this for figuring out whats going on, i am willing to mess around with my cables or get the laptop from the basement with another cable. but if not, dont get me wrong, i dont want to test that. maybe guillomep want to give this a try.
also, for me it makes no sense why it should behave any different when i set a client to 100mbit and plug it into an “old” 100mbit port.