Ethernet link suddenly 100mbit

Ask Fedora
, ,
1

Helo.
I’ve got two Fedora 42 workstation machines, both stationary, one Intel NUC 12 pro, the other is an AM5 platform machine. The NUC machine suddenly gets a 100mbps link speed acc to ethtool (I noticed it while transferring files across the local network, the speeds weren’t what they used to be).

The topology is like this:

Ubiquiti unifi express router → unifi flex mini gigabit switch → rpi5, AM5 machine(RTL8125BG) and Intel NUC(I226-V)

(The rpi5, just like the AM5 machine, establish a 1gbit link. The Rpi5 is running the latest raspberry pi os)

ethtool says that the link is 100mbps, the ux interface says the same (and I can’t change it there that I know, and haven’t ever tried it). If I under network settings set “Link negotiation” to anything but “ignore” which it defaults to, the machine tries to establish a link repeatedly (networkmanager) and never succeeds. This includes “automatically” and “manual” to 1gbit.

If I set the AM5 machine Link negotiation to “automatically” it still works, and still gets 1gbit acc to ethtool and the ux gui.

I’ve updated the bios fw of the NUC 12 pro and checked its settings, LAN has a checkbox for on and off, it doesn’t appear I can change any speed props there.

I’ve tried connecting the NUC directly to the UX, no difference.
I’ve switched the cat 6 tp cables between the AM5 machine and the NUC, no difference.
The NUC 12 pro was booted to a Kubuntu live usb, no difference (in terms of eth link speed).

Is there anything else I could try (short of a different router which I will try eventually if this doesn’t resolve before)?

Thanks for reading.

Edit. This is the output of ethtool:

Settings for enp100s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
3

What does “suddenly” mean?
Do you mean after an update? Or changes after boot?

Check cable and switch port by using a new port and a new cable.
Does that help?

Check the system journal for messages about your network.
What do you find?

4

“Suddenly” means I don’t know precisely. I don’t perform actions that verify the link speed on a regular basis. “Probably within the last two months” is about as specific as I can be. Definitely sometime after I got the switch. The only other thing regarding the network that I’ve changed since adding the switch is further upstream (from the ux) and since the ux acts as a router (dhcp+nat) I fail to see how that could be the reason.

Using the AM5 machine’s cable and port in the switch makes no difference. The AM5 machine gets a (I want to say “negotiates” but I have no idea what the KDE network setting “Negotiate: ignore” means then) GBE connection and green light on the switch, the NUC doesn’t.

When I plug the cable in the journal says

maj 17 09:44:55 skuggborg kernel: igc 0000:64:00.0 enp100s0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.6983] device (enp100s0): carrier: link connected
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.6991] device (enp100s0): state change: unavailable -> disconnected (reason 'carrier-changed', managed-type: 'full')
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7010] policy: auto-activating connection 'Trådbunden anslutning 1' (d618f8ca-d898-378b-9986-ad6c55bfd570)
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7017] device (enp100s0): Activation: starting connection 'Trådbunden anslutning 1' (d618f8ca-d898-378b-9986-ad6c55bfd57>
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7018] device (enp100s0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7022] device (enp100s0): state change: prepare -> config (reason 'none', managed-type: 'full')
maj 17 09:44:55 skuggborg audit[1157]: NETFILTER_CFG table=firewalld:12 family=1 entries=34 op=nft_register_rule pid=1157 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7159] device (enp100s0): state change: config -> ip-config (reason 'none', managed-type: 'full')
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.7164] dhcp4 (enp100s0): activation: beginning transaction (timeout in 45 seconds)
maj 17 09:44:55 skuggborg avahi-daemon[1057]: Joining mDNS multicast group on interface enp100s0.IPv6 with address fe80::69fb:5ce6:97d7:ee57.
maj 17 09:44:55 skuggborg avahi-daemon[1057]: New relevant interface enp100s0.IPv6 for mDNS.
maj 17 09:44:55 skuggborg avahi-daemon[1057]: Registering new address record for fe80::69fb:5ce6:97d7:ee57 on enp100s0.*.
maj 17 09:44:55 skuggborg NetworkManager[1183]: <info>  [1747467895.9249] dhcp4 (enp100s0): state changed new lease, address=192.168.1.19, acd pending
maj 17 09:44:56 skuggborg NetworkManager[1183]: <info>  [1747467896.1082] dhcp4 (enp100s0): state changed new lease, address=192.168.1.19

If I change the Negotiate setting in network settings for the ethernet connection to Auto then this happens in a loop (and this setting works on the AM5 machine):

maj 17 09:55:20 skuggborg kernel: igc 0000:64:00.0 enp100s0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6334] device (enp100s0): carrier: link connected
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6338] device (enp100s0): state change: unavailable -> disconnected (reason 'carrier-changed', managed-type: 'full')
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6349] policy: auto-activating connection 'Trådbunden anslutning 1' (d618f8ca-d898-378b-9986-ad6c55bfd570)
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6362] device (enp100s0): Activation: starting connection 'Trådbunden anslutning 1' (d618f8ca-d898-378b-9986-ad6c55bfd57>
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6364] device (enp100s0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6367] manager: NetworkManager state is now CONNECTING
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.6850] device (enp100s0): state change: prepare -> config (reason 'none', managed-type: 'full')
maj 17 09:55:20 skuggborg audit[1157]: NETFILTER_CFG table=firewalld:31 family=1 entries=26 op=nft_register_rule pid=1157 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.7008] device (enp100s0): state change: config -> ip-config (reason 'none', managed-type: 'full')
maj 17 09:55:20 skuggborg NetworkManager[1183]: <info>  [1747468520.7014] dhcp4 (enp100s0): activation: beginning transaction (timeout in 45 seconds)
maj 17 09:55:20 skuggborg avahi-daemon[1057]: Joining mDNS multicast group on interface enp100s0.IPv6 with address fe80::69fb:5ce6:97d7:ee57.
maj 17 09:55:20 skuggborg avahi-daemon[1057]: New relevant interface enp100s0.IPv6 for mDNS.
maj 17 09:55:20 skuggborg avahi-daemon[1057]: Registering new address record for fe80::69fb:5ce6:97d7:ee57 on enp100s0.*.
maj 17 09:55:26 skuggborg NetworkManager[1183]: <info>  [1747468526.6867] device (enp100s0): state change: ip-config -> unavailable (reason 'carrier-changed', managed-type: 'full')
maj 17 09:55:26 skuggborg audit[1157]: NETFILTER_CFG table=firewalld:32 family=1 entries=26 op=nft_unregister_rule pid=1157 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
maj 17 09:55:26 skuggborg NetworkManager[1183]: <info>  [1747468526.7060] dhcp4 (enp100s0): canceled DHCP transaction
maj 17 09:55:26 skuggborg NetworkManager[1183]: <info>  [1747468526.7060] dhcp4 (enp100s0): state changed no lease
maj 17 09:55:26 skuggborg avahi-daemon[1057]: Withdrawing address record for fe80::69fb:5ce6:97d7:ee57 on enp100s0.
maj 17 09:55:26 skuggborg avahi-daemon[1057]: Leaving mDNS multicast group on interface enp100s0.IPv6 with address fe80::69fb:5ce6:97d7:ee57.
maj 17 09:55:26 skuggborg avahi-daemon[1057]: Interface enp100s0.IPv6 no longer relevant for mDNS.
maj 17 09:55:26 skuggborg NetworkManager[1183]: <info>  [1747468526.7554] manager: NetworkManager state is now DISCONNECTED

At this point a different router or switch or Windows on the NUC seems like good troubleshooting. A different router or switch it is then..

1 Like
5

Trying a different switch sound like a good test to do.

What was the model of switch that you are using?

6

Will try a different setup (apart from the ux and switch) since the issue was the same connected to the ux as well as to the switch but the fact that it had the issue with both signals that it may very well have the same issue connected to a third router/switch.

(And just as a slight addendum, the kernel message when the ethernet cable is connected isn’t identical on the AM5 machine:

kernel: r8169 0000:0a:00.0 enp10s0: Link is Up - 1Gbps/Full - flow control off

)

2 Likes
7

A small update:
I tried connecting the device to another router (Asus TUF AX5400) (without any other network device) it has gigabit lan ports and the affected machine gets a 100mbit link when connected to it with a cat 6 cable acc to eththool as well as the router. The router doesn’t log that anything appears anything amiss, it just states that a link was established at that speed.

If I employ the same cable, port of the router with my AM5 desktop ethtool and the router agree that a gigabit link is established.

I’m starting to wonder if the physical eth port of the NUC might be damaged in some way? (Edit. it doesn’t appear so when inspected visually)

I suppose I can try installing Windows…buut I don’t think I will. Even if it established a gigabit link, what would be the point? It isn’t going to run Windows. And with the way things are pointing I doubt it would establish a gigabit link there either.

Closer at hand is probably a USB-C → gigabit ethernet adapter.

8

I think you can force a link to be 1000baseT with ethtool.
You could try that and see if it will operate.

9

I tried it with sudo ethtool -s enp100s0 autoneg on speed 1000 duplex full which results in the link going down (and not coming back up).

I actually imaged the system disk, installed Win 11, then the NUC’s ethernet drivers from Asus (else no ethernet) and Win 11 said the same thing : 100mbps link. Forcing it to gigabit in the “duplex and speed” setting resulted in that setting remaining at 1 gigabit but the connection reconnecting at 100mbps.

I briefly thought about downgrading the NUC bios (it’s on the latest from earlier this year) but that isn’t supported by Asus, explicitly, and seems not recommended.

I think I’ll run it via wifi , wifi 6 5GHz is a little faster than 100mbps, then see if there’s another bios update, if that will change anything.

I made a post in the NUC subreddit too since this isn’t strictly a Fedora or even Linux issue.

Thanks for your advice.

1 Like
10

I wonder if this means there is electrical damage to the Ethernet port?

11

I can’t think of what it could be except firmware/bios or some type of physical damage (or electrical, which might make more sense since the port bears no physical marks that I can see). It hasn’t been subjected to anything terrible as far as I’m aware.

12

Would not this be a problem. Turning on auto-negotiate then specifying both speed and duplex would seen to conflict with allowing auto-negotiate

Also it seems that cat5 cable may not always successfully use 1G speeds depending upon cable quality. It may require either cat6 or cat6e cable for those network speeds.

Some times in the past I have seen situations where autoneg enabled at both ends would fail, but setting the port on ONE end of the link to a fixed speed would allow the other end to properly negotiate the link

I have also seen some interface ports that just failed at the higher rates (1G+) but would work fine at 100M

13

From wikipedia

Category 5e specification (Cat 5e ). The cable standard provides performance of up to 100 MHz and is suitable for most varieties of Ethernet over twisted pair up to 2.5GBASE-T[1][2][3][4] but more commonly runs at 1000BASE-T (Gigabit Ethernet) speeds. Cat 5 is also used to carry other signals such as telephone and video.

No need for Cat6.

2 Likes
14

Agreed; try without autoneg.

1 Like
15

I see. Well, I don’t know how to turn auto-negotiate off at the router end, from what I’ve seen it isn’t possible. And most if not all pages I’ve seen on the internet regarding ethernet recommend auto negotiation at both ends or neither end.

But I don’t doubt your experiences so I tried
sudo ethtool -s enp100s0 autoneg on speed 1000 duplex full and..
green light on the switch port (for gigabit) and ethtool says:

Settings for enp100s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

and transfer speeds across the lan corroborate.

I am surprised : ) Many thanks for your pieces of advice!

Edit…hwell, it lasted for approx 4 minutes, then the ethernet link died and re-established at 100mbit

16

Try this:

# Advertise 1000baseT/Full Link Speed on Interface
sudo ethtool -s enp100s0 advertise 0x02f
17

The igc module has parm: debug:Debug level (0=none,...,16=all) (int).

18

Thanks for the suggestion. The result was the same as the prior attempt: a gigabit link is established for a few minutes, then it reconnects with 100mbit.

Edit. Although I noticed something physical. The rj45 connector of the patch cable has play when connected to the NUC 2.5GB ethernet port - it can be pushed in a little bit, while remaining physically “locked”. And when pushed in the gigabit link seems to stay (ten minutes and counting). I wonder if it has developed this because the NUC stands by the edge of the desktop and the cables connected to its backside are going 90 degrees down toward the floor. The weight is merely the cable for most of a meter and I’ve subjected other machines to the same thing without incident, I’ve never known a patch cable needing to lie flat for a meter or more before angling down. Or maybe this is a NUC ethernet port design flaw that become apparent only recently.

19

I’m afraid I don’t know how to apply that.
I see GitHub - jksinton/intel-igc: igc driver for the Intel(R) I225-LM/I225-V 2.5G Ethernet Controller , there’s no “igc” command on my Fedora and no manpost for “igc”. In the Fedora packages “intel-igc” has nothing to do with ethernet it seems.