The device has 4 physical ethernet ports, split as eth0 (1 port) and eth1 (3 port switch). These all are gigabit ports, and have worked as such for all previous versions of OpenWrt.
I just updated my device from 19.07.7 (ath79) > 21.02.0 (ath79). I did not retain settings, and I rebuilt everything manually. The port connects at 1G during the initial boot process (PoE), but then drops to 100M/Full.
ethtool is reporting 10/100 supported, but not 1000 on eth0. If I force the port to 1000, the link simply dies, and if I re-initiate the auto-negotiation, it negotiates a 100M/Full link. And I have tried multiple cables -- I am confident that this is not the issue.
Can anyone confirm this issue? Or any ideas for troubleshooting this and/or providing the appropriate supporting evidence of a bug?
root@openwrt:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Full
Advertised pause frame use: No
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: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 4
Transceiver: external
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/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
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
EDIT: I verified that I flashed the correct image (and not the one for the non-pro RouterStation). What is interesting is that the non-pro version has 100M ports.
I can now confirm that there is a bug in 21.02.0 for at least the RouterStation Pro with respect to eth0.
Below is the ethtool output from a completely fresh 19.07.8 (ath79) flash (with only the ethtool package installed, everything else stock/default).
I will refresh 20.02.0 and follow up with the same output from the new version.
root@OpenWrt:~# ethtool eth0
Settings for eth0:
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: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ ]
Supported link modes: 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Both tests with the ath79 branch means this could likely be dissected to the commit that broke the ethernet speed. 19.07 was branched on 17 Mar 2019. So maybe trying a master commit before the branch, like b61495409bb398b1967d7da305a49a6f077cb55a, that should be fine. And then try a recent master commit, it should turn out bad. And then dissect until you find the commit that caused the regression.
Not sure if you feel like doing this. This would take quite some time I imagine, compiling and flashing the router multiple times and such.
Other way would be to raise a bug and hope that somebody else looks into it.
You can git cherry-pick 766e0f584a325b0b80a97bbc86ca515d97c63001 and then build 21.02.0 with working gigabit. It would be nice if this fix gets included in future releases of version 21.
Awesome. I'm going to build with this cherry pick for my RouterStation Pro. Thanks for finding this and the tip! I'll report back when I've had a chance to test.
So I bricked my RouterStation Pro. I was able to recover using TFTP, so I'm back to the standard 21.02 build.
I'm not sure if the cherrypicked commit was the problem, or if there was some other issue with the image I created. So I'm going to start over and build plain 21.02.0 again (effectively the default build), and if that works, I'll repeat the process with the cherrypicked commit and test again. This will probably take a few days or more due to both compile time and personal time.
First, I recompiled everything and it worked this time. I clearly made a mistake in my earlier attempt to compile the firmware, but my self-compiled 21.02.0 worked properly. Then, I recompiled with the cherrypicked commit included, and it indeed solved the gigabit issue. My uplink port is now operating properly at gigabit speeds!
Thank you @dreamlayers for all the work you did to test and find that commit! Now we just need to get this commit into 21.02.1 -- I'm hoping we can get this in front of the right part of the dev team to get it pulled in.