[gelöst] eth0 zeitweise tot

[mR. bluE]

Hi,
ich habe bei meinem Fileserver das merkwürdige Phänomen das ab und an die Netzwerkverbindung aussetzt, also ich kann weder zum Server verbinden (ssh, nfs, smb) noch anpingen. In den Logs habe ich keinerlei hinweise gefunden.
Lokal am Server einloggen funktioniert, aber mittels

Code: Alles auswählen

/etc/init.d/networking restart 

läst sich die Netzwerkkarte auch nicht überreden wieder zu erwachen. Vom Server ins LAN oder ins WAN zu pingen funktioniert auch nicht.
Das ein Kabel einen Wackelkontakt hat denke ich nicht, die Signal Led´s an der Netzwerkkarte und am Switch leuchten, abgesehen davon müsste ich ja dann etwas in den Logs finden das die Verbindung unterbrochen wird, oder?
Kurioserweise funktioniert es dann meist nach ner halben Stunde wieder wie von selbst.

Irgend jemand eine Idee wie ich beim nächsten Aussetzer der Sache auf den Grund gehen kann?

Achja eine Firewall läuft nicht, installiert ist Lenny in der aktuellsten Version

[jeff84]

Hänge doch mal einen Rechner direkt per Netzwerkkabel an den Server und pinge mal die ganze Zeit. Wenns dann noch auftritt, könntest du ausschließen, dass es am Switch oder weiter hinten liegt...

[mR. bluE]

hi jeff84,
nachdem heute morgen wieder die Netzwerkverbindung wie tot war, hab ich mein PC direkt angeschlossen, leider ohne Erfolg.
Also ein Problem mit der Verkabelung kann ich jetzt definitiv ausschließen.
Komisch ist halt das es so ausschaut als würde irgendwas die Netzwerkkarte blocken, nix kommt rein nix geht raus.
Es laufen eigentlich nur sshd, nfsd und smbd. Ansonsten hab ich nix zusätzlich installiert.
Der Server lief auch über nen Jahr durch ohne irgendwelche macken, dann habe ich nur in der ssh config sowie bei den exports für nfs einen weiteren client eingetragen, und seit dem hab ich die aussetzer. Glaub zwar kaum das es damit was zu tun hat aber vielleicht hat ja noch jemand nen tip für mich. Gibts ne möglichkeit eth0 mit einfachen mitteln irgendwie mitzuloggen? Irgend ein daemon muss den doch blockieren, zumindest stell ich mir das so vor.

[mR. bluE]

achja hier noch mal die kerlen log einträge

lenny:~# dmesg | grep eth0
[ 3.852780] eth0: RTL8168c/8111c at 0xf8830000, 00:30:18:a0:68:96, XID 3c4000c0 IRQ 220
[ 6.276056] r8169: eth0: link down
[ 6.276075] r8169: eth0: link down
[ 6.856486] r8169: eth0: link up
[ 183.228023] eth0: no IPv6 routers present
[193897.000009] NETDEV WATCHDOG: eth0: transmit timed out
[193897.017077] r8169: eth0: link up
[203617.000017] NETDEV WATCHDOG: eth0: transmit timed out
[203617.017079] r8169: eth0: link up
[504223.000017] NETDEV WATCHDOG: eth0: transmit timed out
[504223.016968] r8169: eth0: link up

[mindX]

Das r8169-Modul scheint buggy zu sein. Auf meinem Rechner hatte ich ein massives dropped-packages-Problem und hab deswegen den Treiber r8168 von der Realtek-Webseite installiert. Seitdem läuft alles wunschgemäss.

Siehe auch hier: http://wiki.hetzner.de/index.php/Instal ... 8-Treibers

[mR. bluE]

Interesannterweise habe ich aber den Netzwerkchip RTL8111C.
Merkwürdig ist auch, dass in der ersten Zeile RTL8168c/8111c steht und danach von r8169 "gesprochen" wird.
Bedeutet das, dass zwar der richtige Chip erkannt wird aber aus Mangel eines passenden Treibers einfach der Treiber für die r8169 genommen wird?
OK wie ich in der /var/log/installer/hardware-summary lesen kann war das aber offensichtlich von Anfang an schon so, fast ein Jahr lief also alles ohne Probleme, eher unwahrscheinlich das jetzt aufeinmal der Treiber schuld sein kann.

lspci -knn: 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
lspci -knn: Kernel driver in use: r8169
lspci -knn: Kernel modules: r8169

[mindX]

Gab es womöglich kürzlich ein Kernelupdate? Die Fehlerbeschreibung bei Hetzner erinnert mich an Deine Fehlermeldung:

"Bei starker Netzwerkauslastung können Timeouts entstehen und die Netzwerkkarte in den Zustand link down wechseln."

Laut Readme aus dem r8168-Modul sollte Deine Karte damit funktionieren:

<Linux device driver for Realtek Ethernet controllers>
This is the Linux device driver released for RealTek RTL8168B/8111B, RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, RTL8168DP/8111DP, and RTL8168E/8111E Gigabit Ethernet controllers with PCI-Express interface.

[mR. bluE]

hallo mindX,
entschuldige aber wer ist Hetzner? Meinst du damit den Hoster? Steht da auch was explizit zu meinem Netzwerkchip/Treiber?

Ja der treiber r8168 wurde wie gesagt auch schon von Anfang an genutzt. Aber für die Zukunft, wo kann ich denn die Dokumentationen für die Treiber/Module einsehen?

[mindX]

Ja, in meinem ersten Beitrag hab ich einen Link zu einer Wiki-Seite des Hosters gepostet. Dort steht eine Problembeschreibung, eine Symptombeschreibung und die Schritt-für-Schritt-Lösung.
Laut Deinem dmesg wird r8169 benutzt und die Lösung schlägt die Nutzung des r8168 vor.

Die Dokumentation befindet sich in der Datei README in diesem Download:
http://download.hetzner.de/drivers/r816 ... 00.tar.bz2

Viel Erfolg!

[mR. bluE]

hi,
sorry habe den LINK irgendwie übersehen.
Ich hatte einen Fehler in /etc/exports, und zwar hatte ich mehrfach den selben share geadded. Das habe ich jetzt bereinigt und die client IP´s hintereinander mit einem Leerzeichen aufgeführt. Ich hab die Hoffnung das es daran lag, erklären warum dann aber das ganze Netzwerk zusammenbricht kann ich mir allerdings nicht.
Sollte es nocheinmal zu einem Ausfall kommen werde ich versuchen die Treiber von der Realtek Homepage für den 8111c Chip zu compilieren. Wenn das auch nix bringt werde ich nach der Hetzer Methode probieren.
Danke für deine Hilfe

[mR. bluE]

Hi,
also die exports waren es nicht.
Habe dann versucht nach der Anleitung von Hetzer vorzugehen nach

make all

hat er erstmal gemeckert das in /lib/modules/2.6.26-2-486/ kein build ordner liegt, also hab ich den erstellt.
Danach kam die Fehlermeldung:

keine rechte modules zu laden

Tja also ich steh irgendwie aufm schlauch, selbstverständlich hab ich alles unter root gemacht.
Irgend jemand mit nem Tipp?

[jeff84]

keine rechte modules zu laden

Tja also ich steh irgendwie aufm schlauch, selbstverständlich hab ich alles unter root gemacht.
Irgend jemand mit nem Tipp?

Wenn der Kernel ein Nachladen von Modulen verbietet, was auf Servern auch sinnvoll ist, haste schlechte Karten...

[mR. bluE]

das glaub ich nicht mit rmod wurde der alte Treiber automatisch entfernt, nachdem ich aber nicht weiterkam hab ich die mit

Code: Alles auswählen

modprobe -a r8169

wieder nachladen können, sie wurden mir mit lsmod auch angezeigt, allerdings konnte ich erst wieder nach einem reboot nach draußen pingen.

[mR. bluE]

hab das ganze nochmal versucht, ich glaub ich hatte ne leicht andere Fehlermeldung

Keine Regel, um »modules« zu erstellen

vorher hatte ich

Code: Alles auswählen

aptitude install build-essential linux-headers-`uname -r`

ausgeführt

[mindX]

Ich fass die Anleitung von Hetzner nochmal zusammen:

Code: Alles auswählen

aptitude install build-essential linux-headers-`uname -r`
cd /tmp
wget http://download.hetzner.de/drivers/r8168-8.015.00.tar.bz2
tar xjf r8168-8.015.00.tar.bz2
cd r8168-8.015.00
make all
depmod -a
echo "blacklist r8169" >> /etc/modprobe.d/blacklist
echo "r8168" >> /etc/initramfs-tools/modules
update-initramfs -v -u -k `uname -r`
reboot

An welcher Stelle hängts?
Ich hab unter Lenny übrigens nicht den Treiber von Hetzner genommen, sondern den Original-Download von Realtek und entsprechend dem enthaltenen Readme installiert.

[mR. bluE]

ich hab auch versucht die Realtek Treiber zu installieren, allerdings komm ich da auch nicht weiter.
Nach der Eingabe von

Code: Alles auswählen

make all

bekomme ich die Fehlermeldung

Keine Regel, um »modules« zu erstellen

leider zeigt mir der log keine Rückmeldungen an

-------------------------------
So 28. Feb 15:08:24 CET 2010
make -C src/ clean
make[1]: Entering directory `/tmp/r8168-8.016.00/src'
rm -rf *.o *.ko *~ core* .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags .tmp_versions Module.symvers Modules.symvers Module.markers *.order
make[1]: Leaving directory `/tmp/r8168-8.016.00/src'
make -C src/ modules
make[1]: Entering directory `/tmp/r8168-8.016.00/src'
make -C /lib/modules/2.6.26-2-486/build SUBDIRS=/tmp/r8168-8.016.00/src modules
make[2]: Entering directory `/lib/modules/2.6.26-2-486/build'
make[2]: Leaving directory `/lib/modules/2.6.26-2-486/build'
make[1]: Leaving directory `/tmp/r8168-8.016.00/src'

auch mit

Code: Alles auswählen

./autorun.sh

wie es in der realtek readme steht komme ich zur selben Fehlermeldung
komisch ist auch das ich die build in /lib/modules/2.6.26-2-486/ per Hand anlegen muss

[mindX]

Sehr merkwürdig... ich hab das Modul testweise bei mir gerade nochmal kompiliert und nach "make" (ohne "make all") läuft es tadellos durch. Die aktuelle Version (8.016.00) des Treibers soll sich laut Readme per autorun.sh installieren lassen, aber das klappt ja auch nicht. Offen gesagt bin ich mit meinem Latein am Ende.

[mR. bluE]

bei mir hat der link zu den header dateien gefehlt, hätte man gleich drauf kommen können nachdem build nicht existiert hat.
Hab den dann per Hand angelegt:

Code: Alles auswählen

ln -s /usr/src/linux-headers-2.6.26-2-486 /lib/modules/2.6.26-2-486/build

na dann bin ich mal gespannt ob meine timeouts damit behoben sind

[mR. bluE]

so 3 wochen sind rum und keinerlei Probleme, ergo muss es am Treiber Modul gelegen haben.
Jetzt stellt sich mir aber zwangsläufig die Frage ob die Treiber Module ebenfalls bei einem

Code: Alles auswählen

aptitude upgrade

ausgetauscht werden? Und wenn ja, kann sein das beim nächsten upgrade die anderen Treiber wieder installiert werden? Sollte es für so etwas essentielles wie Treiber nicht wenigstens ne Rückfrage geben, und vorallem ein backup angelegt werden?

[DAS-ICH]

Hi

ich habe ein ähnliches Problem.

Bei mir ist es so, das sobald ich das Haus verlasse, um arbeiten zu gehen, ist eth0 nach ca einer Halben Stunde down. Das bleibt dann die ganze Zeit so, bis kurz vor Feierabend. Dann geht es wie von Geisterhand wieder auf up. Das kuriose dabei, es ist egal welche Schicht ich habe, ob Nacht Spät oder Früh, es ist immer in der Zeit in der ich nicht zu Hause bin.

Ich dachte schon, ich hätte irgendwann mal irgendwas konfiguriert und finde es nicht, und habe daraufhin mein System komplett neu installiert und eingerichtet. Aber was soll ich sagen das gleiche Problem wie vorher.

Der Treiber von Realtek ist auch installiert.

Vielleicht hat einer von euch ja ne Idee, da dieser Rechner bei dem das Problem auftritt der Firewall-Router meines Hauses ist.


MfG

[mindX]

Woher kennt deine Netzwerkkarte deinen Schichtplan.... ? Mystery-Channel bei Debian


Nee, mal im ernst: Du sagst, du hättest das System komplett neu aufgesetzt... incl. /etc und /home?
Gibts ne Zeitschaltur? Stromspar-BIOS? Mitbewohner?

/e: Mach lieber einen neuen Thread auf... du hast - scheint mir - eher ein Problem mit automatischem hoch-/runterfahren, während es hier ursprünglich um einen buggy-Treiber ging.