[SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

the_jest · 2022-02-11 17:08:31

I'm not sure how to describe what's happening, and I don't know what logs would be helpful here, so please bear with me....

I'm new to Arch, and have a new install on a desktop, with a static IP set in dhcpcd.conf. No other networking is enabled. This same desktop previously ran Debian for many years, and there were no networking issues, and nothing has changed with my network infrastructure. The motherboard has an Intell I211 network controller.

Every day or two, the connection drops, and "ip a" will show "NO-CARRIER" for eth0, though the interface remains up. Manually setting the link "up" has no effect, nor does restarting dhcpcd. After some amount of time--10m, an hour--the connection will come back up.

I don't know why this is going down, and I'm honestly not sure where to look--I don't know where and how this might be logged. As far as I can tell, there's nothing going on with the rest of the network; i.e. this is happening on this computer, not because of a network thing. I'd like to prevent this from happening at all, of course, and secondarily to be able to re-connect the interface if this does happen.

I'm happy to provide any information that would help evaluate this. Thanks.

Last edited by the_jest (2022-04-23 21:02:04)

V1del · 2022-02-11 17:14:58

Check your journal, in doubt post the entire

sudo journalctl -b

of a boot covering such a failure: https://wiki.archlinux.org/title/List_o … n_services

Also to verify the no other networking claim:

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

the_jest · 2022-02-11 18:56:54

Thank you. The output of the second command is:

bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dhcpcd.service                           | multi-user.target.wants
dirmngr.socket                           | sockets.target.wants
display-manager.service                  | system
getty@tty1.service                       | getty.target.wants
gpg-agent-browser.socket                 | sockets.target.wants
gpg-agent-extra.socket                   | sockets.target.wants
gpg-agent.socket                         | sockets.target.wants
gpg-agent-ssh.socket                     | sockets.target.wants
lm_sensors.service                       | multi-user.target.wants
mariadb.service                          | multi-user.target.wants
p11-kit-server.socket                    | sockets.target.wants
pulseaudio.socket                        | sockets.target.wants
remote-fs.target                         | multi-user.target.wants

But by "No other networking is enabled" I meant that I don't have a wireless connection, or something that would use DHCP under some circumstances, etc.; i.e. that there's no reason why a lease would be getting renewed or anything like that.

From my journal, I'm not sure exactly what would help; the entire thing even since a recent boot is gigabytes. The output for dhcpcd from the most recent incident (this morning) is:

Feb 11 10:01:18 desktop dhcpcd[2532980]: eth0: carrier lost
Feb 11 10:01:18 desktop dhcpcd[2532980]: eth0: deleting address fe80::1b13:[...]
Feb 11 10:01:18 desktop dhcpcd[2532980]: eth0: deleting route to 192.168[...]
Feb 11 10:01:18 desktop dhcpcd[2532980]: eth0: deleting default route via 192.168[...]
Feb 11 11:05:42 desktop dhcpcd[2532980]: eth0: carrier acquired
Feb 11 11:05:42 desktop dhcpcd[2532980]: eth0: IAID c2:a1:46:2a
Feb 11 11:05:42 desktop dhcpcd[2532980]: eth0: adding address fe80::1b13[...]
Feb 11 11:05:42 desktop dhcpcd[2532980]: eth0: soliciting an IPv6 router
[etc.]

There was nothing for many hours before the "carrier lost" line. But I don't know if a different journal entry would show something more relevant, something that might show why the carrier is being dropped. Happy to post it, if so.

seth · 2022-02-12 00:02:18

Carrier lost means that the other side doesn#t respond on a low level what could mean
1. cable
2. plugs are part of the cable
3. on both sides
4. temporary misbehavior of the link partner (powered down and no termination)
5. cable
6. it's probably the cable

the_jest · 2022-02-12 00:08:01

It would be exceptionally bad if it were the cable; is there any way to test this?

It would also be somewhat strange to me, as the cable has been in place for many years with no problems whatsoever, and this problem started only and immediately after I installed Arch on this machine. I guess it could be a coincidence, but I was hoping it's rather some kind of driver issue that could be resolved....

seth · 2022-02-12 00:19:16

I assume that means the cable isn't easily accessible (and the simple test would be to switch it)?
Try some live distro or at least the lts kernel - I assume a bug in the kernel module could cause this.

ewaller · 2022-02-12 00:31:45

Of course it can be tested, but it generally involves test equipment I assume you don't have. Have you access to the other end of the cable?
Is this 1000 base-T or 100 base-T ?

When it is working, check the output of ifconfig For a wired point to point connection with a rational length cable, the Tx and Rx values for your NIC should be zero. If the cable is not great, or it runs through a electrically noisy environment, those numbers might be non-zero; but not in the hundreds or thousands.

the_jest · 2022-02-12 01:03:12

I do have access to both ends of the cable, but sadly not to the middle. 35 feet, Cat6, installed underneath the floorboards. And yes, there was a pair of cables installed at the same time for redundancy, but one of them died almost immediately. So if the cable needs to be replaced, it would be very bad indeed.

ewaller wrote:

When it is working, check the output of ifconfig For a wired point to point connection with a rational length cable, the Tx and Rx values for your NIC should be zero. If the cable is not great, or it runs through a electrically noisy environment, those numbers might be non-zero; but not in the hundreds or thousands.

I don't understand which values you mean--the output of ip -s link shows Tx and Rx values in the dozens of gigabytes. The "errors" and "dropped" values for Tx and Rx are mostly zero (Rx dropped is 8, the others are all 0), if that's what you're referring to.

ewaller · 2022-02-12 01:07:03

Sorry. Yes, the error counts.
That sounds like the cable is working.

seth · 2022-02-12 06:44:49

There was a thread where a cat caused carrier losses by chewing on the cable - there might be a chance that the conditions on or below the floor (tension, moisture, rodents or a mardent ...) are causing this.
If this is an environmental thing and frequent enough, running some live distro with an older kernel will exhibit the same behavior. Otherwise rebooting the system should clear all kernel related problems immediately.

the_jest · 2022-04-22 15:25:01

I've posted about this before, but the problem continues. I'm not sure if this is a networking issue or a hardware/driver issue, but I'm trying in this subforum now.

tl;dr: My ethernet connection will go to NO-CARRIER, with no apparent cause, and will remain down for some seemingly arbitrary amount of time, before coming back up. This does not seem to be a cable problem. I wouldn't imagine it's a hardware issue, as it exactly coincided with my switching the same machine from Debian to Arch.

Since my original post, I've updated the kernel a few times; I'm now on 5.17.4-arch1-1. The motherboard has a Intell I211 network controller, and lspci shows that it's using the igb controller, which I'd expect to be very stable. Also, the problem is not resolved by a reboot.

I'm at a loss for what to try. It's obviously untenable for my network to regularly go down, and while it's typically for only a few minutes, it's currently been over 12 hours. If it is a hardware issue, I'd be happy to fix it, as long as I know what to fix. I'd be grateful for any suggestions.

ewaller · 2022-04-22 15:40:14

Merging threads.

ewaller · 2022-04-22 15:48:37

My money remains on the cable.
Is there anything in the logs when the disconnect occurs?

Does the cable run past anything like a florescent lamp ballast, or a motor, or a any other form of EMI?

I have asked about this before, is it 100MB or 1000MB? They encode data differently and the later uses more twisted pairs in the cable.
What (specifically) is at the other end of the cable?

Can you post the output of ifconfig

the_jest · 2022-04-22 16:01:54

It's 1000MB. The cable runs near an HVAC unit, and near a subwoofer; neither of these regularly goes on and off in a way that jibes with the network incidents, and when this last came up, the error counts did not suggest that there was any significant interference.

There's a short length of cable coming out of the computer, which enters a cat 5E cable extender, which is connected to a 35' cat 6 cable, which is plugged into a Ubiquiti switch.

I have ip rather than ifconfig--what info are you looking for? (At the moment I'm offline again, and would have to retype it, but I'm happy to do so.)

Thanks for sticking with this.

seth · 2022-04-22 16:16:04

Roughly "ip a" but if the carrier randomly drops out intermittenlty that could, on a stretch, be a power saving thing or, what is exceptionally likely, the cable.
For anything related to the local SW stack, I'd expect it to be reflected in dmesg. But it's the cable.

ewaller · 2022-04-22 16:26:12

1000 Mb uses all 4 pair of the cable. And it uses a different line encoding than does 100MB.

I would be interested in using a tool such as ethtool to force the line to 100MB rather than allowing auto negotiation. This might be useful as both a diagnostic and as a temporary work around.

Tell us more about the cable extender. Can it be omitted?

Last edited by ewaller (2022-04-23 16:45:40)

the_jest · 2022-04-22 16:48:21

Unfortunately, at the moment I can't install ethtool or anything else.

The cable extender is a cheap thing; it can't be permanently omitted, but for testing purposes right now I can move things around, and I can report that with the cable itself plugged directly into the desktop, there is no difference; I'm still getting NO-CARRIER with no lights flashing.

Not to be obstructionist, but I remain confused about how everyone can be so convinced it's the cable, when this problem only started after I switched distros. Nonetheless, it's worth $20 for me to be proved wrong, so unless there's another suggestion I'll order up a new cat 7 cable for next-day delivery to try again, and while it will be a mess in terms of home decor, I can probably find a way to make it work.

Oh, the output of ip a:

$ ip a
[...]
2: eth0: <NO-CARRIER, BROADCAST, MULTICAST, UP> MTU 1500 qdisc mq state DOWN group default qlen 1000
    link/ether [not shown] brd ff:ff:ff:ff:ff:ff

seth · 2022-04-22 16:59:46

Why can't you install ethtool?
Symptoms and exerience convince us that it's the cable (or the plugs on either side or, in this case, the extender - though it's usually the cable itself) but you could try whether you get a stable carrier w/ a different software stack (eg. grml or anoth live distro)

ewaller · 2022-04-22 17:21:28

seth wrote:

... exerience convince us that it's the cable (or the plugs on either side or, in this case, the extender - though it's usually the cable itself)

Lot and lots of experience. I've said it before, cables are the bane of the electrical engineer's existence.

But there are the rare exceptions where it is not the cable It could be the NIC card or the switch. Forcing the mode to 100 MB would be interesting to see if things change because of the different signal encoding. It could be a cable equalization problem (a function of the NIC and Switch receivers), it might be firmware. It could be software (whichever service is controlling the NIC), it could be the switch going stupid. We need to isolate what the bad actor is.

Any way you can isolate this by connecting to another computer at the switch end? Or using a different computer to try to talk to the switch. Or put another computer on the desk next to the one that is not working and connect them with a cable and see if that works.

dakota · 2022-04-23 01:40:04

seth wrote:

...exerience convince us that it's the cable (or the plugs on either side or, in this case, the extender - though it's usually the cable itself)

Interesting you should say that, because in my experience it is usually the connectors.

On the other hand, most of the cables I deal with do not have factory-installed connectors, so maybe that's the difference?

seth · 2022-04-23 05:51:25

seth wrote:

Carrier lost means that the other side doesn#t respond on a low level what could mean
1. cable
2. plugs are part of the cable
3. on both sides
4. temporary misbehavior of the link partner (powered down and no termination)
5. cable
6. it's probably the cable

the_jest · 2022-04-23 21:01:37

Well, I didn't expect it, but you guys were all right: It was the cable.

I didn't have another computer I could easily drag to the right place to test, but as threatened, I ordered a new cat 7 cable, with a heavy-looking plug, and it worked immediately. So now I have two dead cables under my floorboards, and I have to figure out how to run this one straight through my living room, but that's not a problem for this forum....

I remain bewildered why this worked fine for years and only started to act up when I switched to Arch. But I'm willing to accept that it's just a wild coincidence.

Thank you for sticking with this for so long!

Arch Linux

#1 2022-02-11 17:08:31

[SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#2 2022-02-11 17:14:58

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#3 2022-02-11 18:56:54

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#4 2022-02-12 00:02:18

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#5 2022-02-12 00:08:01

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#6 2022-02-12 00:19:16

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#7 2022-02-12 00:31:45

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#8 2022-02-12 01:03:12

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#9 2022-02-12 01:07:03

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#10 2022-02-12 06:44:49

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#11 2022-04-22 15:25:01

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#12 2022-04-22 15:40:14

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#13 2022-04-22 15:48:37

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#14 2022-04-22 16:01:54

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#15 2022-04-22 16:16:04

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#16 2022-04-22 16:26:12

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#17 2022-04-22 16:48:21

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#18 2022-04-22 16:59:46

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#19 2022-04-22 17:21:28

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#20 2022-04-23 01:40:04

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#21 2022-04-23 05:51:25

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

#22 2022-04-23 21:01:37

Re: [SOLVED] Ethernet connection randomly goes to "NO-CARRIER"

Board footer