Estoy usando una computadora vieja como servidor/firewall doméstico usando una distribución basada en Linux (Mandriva). Inicialmente tenía dos NIC, eth0siendo el adaptador de la placa base y eth1una tarjeta de red PCI 10/100.
eth0estaba conectado al interruptor interno al que están conectados otros dispositivos y eth1estaba conectado al enrutador del decodificador de Internet.
Con el paso del tiempo y surgieron nuevos usos, agregué dos tarjetas de red PCI gigabit (DLink DGE-528T) que así se convirtieron eth2y eth3se utilizan para la misma funcionalidad que la tarjeta a la que reemplazan. Es decir, eth2está conectado al switch interno y eth3está conectado al enrutador.
Todo funcionaba bien hasta hace unas semanas cuando noté que había perdido la conectividad eth3y, al mirar la tarjeta, el cable ya no hacía "clic" cuando lo conectaba al enchufe. Resulta que hubo algunos abusos en los cables que doblaron el conector RJ45 y lo hicieron poco confiable.
Entonces, decidí reemplazarla eth3con una nueva tarjeta gigabit (TP-LINK TG-3269) que no parece tener un conector tan frágil. Esta tarjeta se llama así eth4y eth3ha sido eliminada por completo del servidor.
Sin embargo, parece que no puedo hacer que esa nueva tarjeta funcione con el enrutador, los LED en la parte posterior nunca se encienden cuando están conectados a ella. Y efectivamente, ifplugdy ethtoolambos indican que no se establece ningún vínculo. Como solución temporal, lo vuelvo a usar eth1para que el servidor siga cumpliendo su propósito, aunque en modo degradado.
Pensé que la tarjeta estaba "tostada", pero probé algunas cosas y obtuve algunos resultados extraños, que se resumen aquí:
- Conectar
eth4al interruptor interno: los LED están encendidos, conexión establecida a 1000 Mb - Conectar
eth4aeth0: los LED están encendidos, conexión establecida a 100 Mb - Conéctese
eth2al enrutador: los LED están encendidos, la conexión se estableció a 1000 Mb
Parece que el enrutador no quiere hablar con mi eth4tarjeta por una razón que no puedo explicar.
Mirando varios hilos algo similares a mi problema, descubrí la mii-diagherramienta y la ejecuté primero sin cable y luego con el cable del enrutador enchufado. Aquí están los 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.
Sé que mii-diagno es consciente de gigabit, pero lo que me parece interesante es que en el segundo caso detecta que hay un socio de enlace y, aún así, el enlace no se establece.
¿Cuál podría ser la razón de ésto? ¿Qué debo probar a continuación?
Según sea necesario, aquí hay algunos detalles adicionales.
El enrutador definitivamente tiene capacidad gigabit y funcionaba bien a esa velocidad eth3antes de que fallara el conector. Cuando se conectó a eth2, funcionó también a velocidad gigabit.
dmesg -T | grep eth4no produce nada
Aquí está el resultado de 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)
Y el 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
¿Crees que forzar la eth4tarjeta a gigabit sin negociación automática resolverá esto? Si estoy en lo cierto, el comando sería este:
ethtool -s eth4 duplex full speed 1000 autoneg off
Lo intentaré esta noche, pero ¿por qué no funciona para empezar?
Respuesta1
Bueno, ahora sé por qué eth4no se establece el enlace y me llegó después de trastear un poco más con los cables. Lo que hay que saber es que aunque sea en casa, estoy usando un patch bay para despachar las distintas conexiones. Esto significa que el servidor se conecta al enrutador mediante este tipo de disposición:
server <--> cable <--> plug <--> wall <--> plug <--> patch bay <--> plug <--> router
En mi mensaje inicial, dije que eth2se conectaría al enrutador en 1G y eso era correcto en ese momento.
Pero lo intenté nuevamente esta semana y ya no sucedió, lo que inmediatamente me hizo darme cuenta de que los problemas originales que tuve eth3se debían a un abuso del cable. Y efectivamente, usar otro enchufe en la pared para conectarse al patch bay permitió eth4conectarse correctamente a 1G al enrutador.
Entonces, al final, está relacionado con el hardware, pero no el tipo de hardware que esperaba que fuera.
Muchas gracias a todos los que comentaron sobre mi problema, aprendí bastantes trucos con ustedes y perdón por hacerles perder el tiempo cuando debería haber revisado los cables más a fondo.