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!
]]>]]>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
...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?
]]>... 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.
]]>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
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?
]]>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.
]]>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
]]>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.
]]>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.
]]>