Linux eth0 no carrier

How to check the physical status of an ethernet port in Linux?

I want to check if a specified ethX is physically up or down. How do I do that with the command line?

10 Answers 10

Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000001 (1) Link detected: yes 

Check /sys/class/net/eth0/operstate and other files in this directory.

As far as I know this is specific to Linux 2.6+, but it provides a clean interface to the kernel driver.

Full documentation for this part of the sys file system can be found here:

last line shows what you want:

# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Current message level: 0x00000037 (55) Link detected: yes

If you check this: en.wikipedia.org/wiki/OSI_model . You will see that the last line is about another layer: the link layer. I just tested this. With a bad cable the physical layer was up, but not the link layer. Then I switched to another cable and all layers came up.

will also tell you if the interface is up. NOTE: Use caution with these methods since they can show out of date information regarding the link’s state.

I think this was the best answer — ethtool isn’t standard in my Ubuntu distibution, so it doesn’t help if on a box not connected to the net.

I believe ifconfig will sometimes show out of date data. It can show UP when the link is down, but ethtool interface will always show the right info AFAIK.

I think @sed_and_done is right. On a Red Hat VM, if I disconnect the NIC, ethtool immediately shows Link detected: no instead of Link detected: yes , and ip link show shows instead of , but ifconfig -a shows UP BROADCAST MULTICAST MTU:1500 Metric:1 , which is the same as when the NIC is connected.

you should see all statuschanges

No, it doesn’t. I just checked — while it works for me on eth0 device, but it doesn’t on eth2 device.

You can also use mii-tool to see if the link is up and check the negotiated speed.

# mii-tool
eth0: negotiated 100baseTx-FD, link ok

The man page for mii-tool suggests using ethtool. However, mii-tool keeps doing its job, more useful if given the -v (verbose) option.

To quickly add to @goo’s answer, you would interpret the ip link or ip link show INTERFACE as follows.

This is a port which is administratively up, but physically down:

2: eth0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000

In other words, the UP you can see indicates the system is configured to try and use the NIC for networking. The NO-CARRIER here tells you what the issue preventing networking from working is.

This is a port that is administratively down (its physical layer is ‘up’, technically — it is a VM):

3: eth1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

Finally, this port is working normally:

2: eth0: mtu 1500 qdisc fq state UP mode DEFAULT group default qlen 1000

It is administratively UP , the LOWER_UP indicates the physical layer is working (i.e. there is a carrier), and the second UP confirms (in effect) the IP layer is up.

Источник

Arch Linux

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)

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

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

Check your journal, in doubt post the entire

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

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

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

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.

Источник

Arch Linux

I’m trying to get on the wired network of my place of work (volunteering, so this isn’t a total catastrophe), but no matter what I do, I can’t seem to get eth0 to see that there’s anything to connect to. The setup is a crossover cable running to a switch, which in turn is running to the main switch which is connected to our router. All the Windows machines connected to this switch work fine; they’re just plug and play, and get their IP addresses via DHCP. I would like to do the same thing on my laptop (wireless works fine, but it’s not always reliable here…the connection occasionally hangs), but neither Wicd nor iputils can seem to detect that there’s any kind of network on eth0.

The module for the device is loaded:

lappy486 ~ $ inxi -N Network: Card-1: Intel Centrino Advanced-N 6200 driver: iwlwifi Card-2: Marvell Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB] driver: sky2 lappy486 ~ $ lsmod | grep "sky2" sky2 49411 0

The interface shows up in ip link:

lappy486 ~ $ ip link 1: lo: mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000 link/ether 00:24:54:87:43:50 brd ff:ff:ff:ff:ff:ff 3: wlan0: mtu 1500 qdisc mq state UP mode DORMANT qlen 1000 link/ether 18:3d:a2:5c:b6:90 brd ff:ff:ff:ff:ff:ff

…but no matter what way I plug this cable in and mess around with the interface configuration (I’ve tried manually assigning an IP address, default route, DNS servers, etc.), it’s as if there’s nothing there; not even ifplugd does anything. I’ve even tried plugging directly into the main switch with the same results. Could this be a hardware issue? Something as simple as a dirty ethernet port? It seems pretty clean to me, and I’ve blown it out to make sure there wasn’t any dust (though I suppose I could try a compressed air can if that’s really the issue ).

Any help on this would be appreciated, even if this just turns out to be a PEBKAC.

Last edited by MrCode (2012-11-23 19:29:05)

Источник

eth NO-CARRIER при подключённом проводе и что с ним делать

В одной организации начались проблемы с интернетом, а именно, он начал пропадать по несколько раз в день, и появлялся снова только после перезагрузки «Роутера» — машины с установленной в давние времена Fedora Core 5. Однако появлялся интернет снова не очень надолго.

В ходе экспериментов было попробовано: смена сетевых карт роутера, использование в качестве роутера Wifi-коробочки Asus RT-N66U (так как все машины в организации подключаются к сети по Wi-fi, это было самым простым решением), однако это не привело к изменению ситуации. Интернет также мог время от времени отваливаться, при этом помогало только «передёргивание» провода в разъеме роутера.

Вызывали даже мастера из тех-поддержки провайдера, который прозвонил провод тестером, и сказал что всё отлично.

Поскольку, как я решил, данный wi-fi-роутер (Asus) всё равно не смог бы вытянуть интернет, пользуемый 20-ю машинами (он люто грелся, и на яндекс-маркете про него был срач на 10 страниц о том что «эта шляпа умеет только греться как утюг и лампочками мигать), а в федоре я не особо разбираюсь (и предшественником было оставлено море хитрых правил iptables и ip route, которые уже давно не использовались но понимание затрудняли), решил поставить на роутер Debian чтобы по крайней мере быть как рыба в воде.

Поставив Debian Wheezy со всеми необходимыми firmware для сетевых карт, и сделав настройки для простейшего интернет-шлюза я, успев долго просидеть за настройкой, обнаружил основной симптом болезни:

В моменты, когда пропадает интернет, ip link show показывает что на устройстве eth8 (интернет-карте) нет сигнала (NO-CARRIER). Факты:

1) Выдёргивание и вставление провода назад помогает, сигнал сразу же появляется.

2) Отключение и включение сетевого интерфейса (ip link set dev eth8 down/up) не помогает.

3) Служба поддержки провайдера, в тот момент когда у нас NO-CARRIER тоже наблюдает в своём админском интерфейсе (не знаю что у них там, наверное cisco какое-нибудь) отсутствие устройств подключённых к порту.

4) Смена сетевой карты никак не влияет на результат.

5) Большая часть NO-CARRIER’ов приходится на утро, возможно потому что все приходят на работу и начинают проверять почту, заходить вконтактики и включать ютюбы.

6) Ни в каких логах, в том числе в dmesg ничего кроме сообщений о том что „провод отключён“/„провод подключён“ нету.
Выглядит это примерно так:

[ 3245.159773] r8169 0000:03:00.0: eth8: link down 

[ 3239.600327] r8169 0000:03:00.0: eth8: link up [ 3239.603487] ADDRCONF(NETDEV_CHANGE): eth8: link becomes ready 

7) После долгих уговоров, провайдер согласился в течении 3-х дней поменять порт к которому подключён наш провод на какой-нибудь другой. Но это в течении 3-х дней, а работать как-то надо. Организация торговая, и интернет для неё жизненно необходим.

Сейчас я просто вывел интернет-кабель, соединённый переходником „на стол“ и дал инструкцию по „починке интернета“ персоналу. Однако это решение, разумеется, никому не нравится, в том числе и мне. Что можно сделать в этой ситуации?

Можно ли как-то программно „отключить“ сетевую карту так, чтобы процесс „обнаружения провода“ начался в ней по новой? Чем может быть вызвано такое поведение? Я, к сожалению, недостаточно хорошо представляю себе физический уровень организации связи по витой паре, чтобы понять причины.

Заранее признателен за ваши ответы.

Источник