Link não estabelece em uma interface

Question

Estou usando um computador antigo como servidor doméstico / firewall usando uma distribuição baseada em Linux (Mandriva). Inicialmente, ele tinha dois NICs, sendo eth0 o adaptador da placa-mãe, enquanto eth1 é uma placa de rede PCI 10/100. eth0 foi conectado ao comutador interno ao qual outros dispositivos estão conectados e eth1 foi conectado ao roteador do conversor de Internet.

À medida que o tempo foi passando e novos usos surgiram, adicionei duas placas de rede PCI de gigabit (DLink DGE-528T) que se tornaram eth2 e eth3 , usadas para a mesma funcionalidade da placa que elas substituem. Ou seja, eth2 está conectado ao comutador interno e eth3 está conectado ao roteador.

Tudo estava funcionando bem até algumas semanas atrás, quando percebi que havia perdido a conectividade em eth3 e, olhando para o próprio cartão, o cabo não mais "clicaria" quando colocado no plugue. Acontece que houve alguns abusos nos cabos que dobraram o conector RJ45 e o tornaram pouco confiável.

Então, decidi substituir eth3 por um novo cartão gigabit (TP-LINK TG-3269) que não parece ter um conector tão frágil. Este cartão é assim chamado eth4 e eth3 foi removido do servidor.

No entanto, não consigo fazer com que o novo cartão funcione com o roteador, os leds na parte de trás nunca ligam quando conectado a ele. E com certeza, ifplugd e ethtool indicam que nenhum link foi estabelecido. Como uma solução temporária, estou de volta usando eth1 para que o servidor continue a servir a sua finalidade, ainda que no modo de downgrade.

Eu pensei que o cartão era "torrada", mas eu tentei algumas coisas e tive alguns resultados estranhos, resumidos aqui:

• Conecte eth4 ao switch interno: leds estão ligados, conexão estabelecida em 1000Mb
• Conecte eth4 a eth0 : leds estão ativados, conexão estabelecida em 100Mb
• Conecte eth2 ao roteador: leds estão ligados, conexão estabelecida em 1000Mb

Parece que o roteador não quer falar com meu cartão eth4 por um motivo que não consigo explicar.

Olhando em vários segmentos de maneira semelhante ao meu problema, descobri a ferramenta mii-diag e a executei sem um cabo primeiro, depois com o cabo do roteador conectado. Aqui estão os resultados:

[obones@server ~]$ sudo mii-diag eth4
Basic registers of MII PHY #32:  1000 7949 001c c913 0de1 0000 0004 2001.
 Basic mode control register 0x1000: Auto-negotiation enabled.
 Basic mode status register 0x7949 ... 7949.
   Link status: not established.
   End of basic transceiver information.

[obones@server ~]$ sudo mii-diag eth4
Basic registers of MII PHY #32:  1000 7949 001c c913 0de1 c5e1 000f 2001.
 The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0x1000: Auto-negotiation enabled.
 Basic mode status register 0x7949 ... 7949.
   Link status: not established.
 Your link partner advertised c5e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
   End of basic transceiver information.

Eu sei que mii-diag não tem conhecimento de gigabit, mas o que eu acho interessante é que, no segundo caso, ele detecta que existe um parceiro de link e, no entanto, o link não está estabelecido.

Qual poderia ser o motivo disso? O que devo tentar em seguida?

Conforme necessário, aqui estão alguns detalhes adicionais.

O roteador definitivamente é capaz de gigabit e estava funcionando bem nessa velocidade com eth3 antes do conector falhar. Quando conectado a eth2 , funcionou bem em velocidade de gigabit.

dmesg -T | grep eth4 não produz nada

Aqui está a saída do lspci:

00:0a.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)
    Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169]
00:0b.0 Ethernet controller [0200]: D-Link System Inc DGE-528T Gigabit Ethernet Adapter [1186:4300] (rev 10)
    Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter [1186:4300]
00:0d.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 [8086:1229] (rev 08)
00:13.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)

E o de lshw:

  *-network:0
       description: Ethernet interface
       product: RTL-8169 Gigabit Ethernet
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: a
       bus info: pci@0000:00:0a.0
       logical name: eth4
       version: 10
       serial: 14:cc:20:05:38:22
       size: 10MB/s
       capacity: 1GB/s
       width: 32 bits
       clock: 66MHz
       capabilities: pm bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half latency=64 link=no maxlatency=64 mingnt=32 multicast=yes port=MII speed=10MB/s
       resources: irq:18 ioport:a000(size=256) memory:f7109000-f71090ff memory:c0180000-c019ffff(prefetchable)
  *-network:1
       description: Ethernet interface
       product: DGE-528T Gigabit Ethernet Adapter
       vendor: D-Link System Inc
       physical id: b
       bus info: pci@0000:00:0b.0
       logical name: eth2
       version: 10
       serial: 1c:7e:e5:26:54:a0
       size: 1GB/s
       capacity: 1GB/s
       width: 32 bits
       clock: 66MHz
       capabilities: pm bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=10.10.10.254 latency=64 link=yes maxlatency=64 mingnt=32 multicast=yes port=MII speed=1GB/s
       resources: irq:19 ioport:a400(size=256) memory:f710b000-f710b0ff memory:c01a0000-c01bffff(prefetchable)
  *-network:2
       description: Ethernet interface
       product: 82557/8/9/0/1 Ethernet Pro 100
       vendor: Intel Corporation
       physical id: d
       bus info: pci@0000:00:0d.0
       logical name: eth1
       version: 08
       serial: 00:90:27:ca:ba:e8
       size: 100MB/s
       capacity: 100MB/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e100 driverversion=3.5.24-k2-NAPI duplex=full firmware=N/A ip=192.168.1.253 latency=64 link=yes maxlatency=56 mingnt=8 multicast=yes port=MII speed=100MB/s
       resources: irq:17 memory:f710a000-f710afff ioport:ac00(size=64) memory:f7000000-f70fffff memory:c0000000-c00fffff(prefetchable)
  *-network:3
       description: Ethernet interface
       product: RTL-8139/8139C/8139C+
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 13
       bus info: pci@0000:00:13.0
       logical name: eth0
       version: 10
       serial: 00:14:85:c0:ea:2b
       size: 10MB/s
       capacity: 100MB/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=8139too driverversion=0.9.28 duplex=half ip=10.10.10.250 latency=64 link=no maxlatency=64 mingnt=32 multicast=yes port=MII speed=10MB/s
       resources: irq:18 ioport:e000(size=256) memory:f710d000-f710d0ff

Você acha que forçar o cartão eth4 em gigabit sem autonegocation resolve isso? Se eu estiver correto, o comando seria este:

ethtool -s eth4 duplex full speed 1000 autoneg off

Vou tentar hoje à noite, mas por que não funciona para começar?

    

Answer 1

Bem, agora sei porque eth4 não estabelecerá o link e ele veio depois de mexer nos cabos um pouco mais. O que deve ser conhecido é que, mesmo que seja em casa, estou usando um patch bay para despachar as várias conexões. Isso significa que o servidor está se conectando ao roteador por meio desse tipo de organização:

server <--> cable <--> plug <--> wall <--> plug <--> patch bay <--> plug <--> router

Na minha mensagem inicial, eu disse que eth2 se conectaria ao roteador em 1G e isso estava correto no momento.

Mas eu tentei novamente esta semana e isso não aconteceu mais, o que imediatamente me fez perceber que os problemas originais que eu tive com eth3 foram depois de algum abuso no cabo. E, com certeza, usar outro plugue na parede para se conectar ao patch bay permitiu que eth4 se conectasse corretamente ao roteador 1G.

Então, no final, é relacionado a hardware, mas não é o tipo de hardware que eu esperava que fosse.

Muitos agradecimentos a todos que comentaram sobre o meu problema, eu aprendi alguns truques com vocês e desculpe por desperdiçar seu tempo quando eu deveria ter mais cuidado com os cabos.