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.
I had old wifi AP running during my tests and tuning ac/x hostapd on R4. This old AP have only 100Mbps eth, and there was really all other RJ45 eth communication only on 100Mbps.
I realized that I had all LAN ports bridged together. Whenever I removed the 100Mbps LAN3 from the bridge and set a subnet on it and added routing, all other LAN ports communicated on 1Gbps as expected.
I do not know if it is bug or not, but it looks like bridge is as fast as the port with lowest speed.
I’m not familiar enough to make any guess. But if I were, I would look at when a cable is plugged into one port of the switch, what routines are triggered and speed set. Then check if something else is wrongly set in the possible ‘rogue’ function…