Ich verwende einen alten Computer als Heimserver/Firewall mit einer Linux-basierten Distribution (Mandriva). Ursprünglich hatte er zwei Netzwerkkarten, wobei es eth0sich um den Motherboard-Adapter handelte, während es eth1sich um eine 10/100 PCI-Netzwerkkarte handelte. Er
eth0war mit dem internen Switch verbunden, an den andere Geräte angeschlossen sind, und eth1war mit dem Internet-Set-Top-Box-Router verbunden.
Mit der Zeit und dem Aufkommen neuer Einsatzmöglichkeiten habe ich zwei Gigabit-PCI-Netzwerkkarten (DLink DGE-528T) hinzugefügt, die somit eth2dieselben eth3Funktionen haben wie die Karten, die sie ersetzen. Das heißt, eth2sie sind mit dem internen Switch verbunden und eth3mit dem Router.
Alles funktionierte einwandfrei, bis ich vor ein paar Wochen bemerkte, dass die Verbindung zur Karte abbrach eth3und das Kabel beim Einstecken in den Stecker nicht mehr klickte. Wie sich herausstellte, waren die Kabel beschädigt worden, wodurch der RJ45-Stecker verbogen und unzuverlässig wurde.
Daher habe ich beschlossen, sie eth3durch eine neue Gigabit-Karte (TP-LINK TG-3269) zu ersetzen, die anscheinend keinen so fragilen Anschluss hat. Diese Karte heißt so eth4und eth3wurde vollständig vom Server entfernt.
Allerdings kriege ich die neue Karte nicht mit dem Router zum Laufen, die LEDs auf der Rückseite leuchten nie auf, wenn ich sie anschließe. Und ifplugdbeide ethtoolzeigen an, dass keine Verbindung hergestellt wurde. Als vorübergehende Problemumgehung verwende ich wieder, eth1damit der Server weiterhin seinen Zweck erfüllt, wenn auch im Downgrade-Modus.
Ich dachte, die Karte wäre hinüber, aber ich habe ein paar Dinge ausprobiert und bin zu einigen merkwürdigen Ergebnissen gekommen, die ich hier zusammengefasst habe:
- Mit dem internen Switch verbinden
eth4: LEDs leuchten, Verbindung mit 1000 MB hergestellt - Verbinden
eth4miteth0: LEDs leuchten, Verbindung mit 100 MB hergestellt - Mit dem Router verbinden
eth2: LEDs leuchten, Verbindung mit 1000 MB hergestellt
eth4Es scheint also, dass der Router aus einem für mich unerklärlichen Grund nicht mit meiner Karte kommunizieren möchte .
Ich habe mir verschiedene Threads angeschaut, die meinem Problem ähnlich waren, und bin auf das mii-diagTool gestoßen. Ich habe es zuerst ohne Kabel und dann mit eingestecktem Routerkabel ausgeführt. Hier sind die Ergebnisse:
[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.
Ich weiß, dass es mii-diagnicht gigabitfähig ist, finde es aber interessant, dass es im zweiten Fall erkennt, dass ein Verbindungspartner vorhanden ist, die Verbindung jedoch nicht hergestellt wird.
Was könnte der Grund dafür sein? Was sollte ich als nächstes versuchen?
Bei Bedarf hier noch ein paar zusätzliche Angaben.
Der Router ist definitiv gigabitfähig und hat bei dieser Geschwindigkeit einwandfrei funktioniert, eth3bevor der Anschluss ausgefallen ist. Bei Verbindung mit eth2hat er auch bei Gigabitgeschwindigkeit funktioniert.
dmesg -T | grep eth4gibt nichts aus
Hier ist die Ausgabe von 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)
Und das von 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
Glauben Sie, dass das Erzwingen einer eth4Gigabit-Karte ohne Autonegociation das Problem löst? Wenn ich richtig liege, wäre der Befehl dieser:
ethtool -s eth4 duplex full speed 1000 autoneg off
Ich werde es heute Abend versuchen, aber warum funktioniert es zunächst nicht?
Antwort1
Nun, ich weiß jetzt, warum eth4keine Verbindung hergestellt werden kann, und es ist mir eingefallen, nachdem ich noch ein bisschen mit den Kabeln herumgespielt hatte. Was man wissen sollte, ist, dass ich, auch wenn es zu Hause ist, ein Patchfeld verwende, um die verschiedenen Verbindungen zu verteilen. Das bedeutet, dass der Server über diese Art von Anordnung mit dem Router verbunden ist:
server <--> cable <--> plug <--> wall <--> plug <--> patch bay <--> plug <--> router
In meiner ersten Nachricht sagte ich, dass die eth2Verbindung zum Router mit 1G hergestellt würde, und das war zu diesem Zeitpunkt korrekt.
Aber ich habe es diese Woche noch einmal versucht und es passierte nicht mehr, was mir sofort klar machte, dass die ursprünglichen Probleme, die ich hatte, eth3auf Kabelmissbrauch zurückzuführen waren. Und tatsächlich ermöglichte die Verwendung eines weiteren Steckers an der Wand zum Anschließen an die Patchbay eth4eine ordnungsgemäße Verbindung mit 1G zum Router.
Letzten Endes hängt es also mit der Hardware zusammen, aber nicht mit der Art von Hardware, die ich erwartet hatte.
Vielen Dank an alle, die zu meinem Problem Stellung genommen haben. Ich habe bei euch so einige Tricks gelernt und es tut mir leid, dass ich eure Zeit verschwendet habe, obwohl ich die Kabel gründlicher hätte überprüfen sollen.