Netzwerkkarten defekt feststellen?

_alex_ · Beitrag von **_alex_** » 18.09.2006 13:46:29

Danke, das hab ich jetzt gefunden.
Welches Paket muss denn für [cod] make-kpkg[/code] noch installiert weden, damit er das kennt?
laut http://www.debiananwenderhandbuch.de soll ich das so machen

Code: Alles auswählen

make-kpkg --config=menuconfig

Das hab ich bereits installiert:

debiananwenderhandbuch.de hat geschrieben:Weiter benötigen Sie einige zusätzliche Pakete, um einen neuen Kernel zu übersetzen, dies sind: gcc, libc5-dev oder besser (weil aktueller) libc6-dev, binutils, make, gawk oder mawk, gzip, shellutils, grep sowie bin86 auf der i386-Plattform. Wenn Sie das Kommando make menuconfig zur Kernel-Konfiguration benutzen möchten, muss das Paket libncurses5-dev installiert sein. Aber sicher haben Sie einige davon bereits installiert.

Edit: sorry für die vielen Fragen, ich bin mit Debian bzw Linux im Allgemeinen nicht so sehr vertraut.

nepos · Beitrag von **nepos** » 18.09.2006 14:42:52

Code: Alles auswählen

aptitude install kernel-package

sollte reichen, damit du make-kpkg nutzen kannst.

_alex_ · Beitrag von **_alex_** » 18.09.2006 15:07:33

danke nepos

aber das

Code: Alles auswählen

RealTek RTL-8139 C+ PCI Fast Ethernet Adapter support (EXPERIMENTAL) --> M

hab ich schon so, soll ich den Kernel trotzdem neu kompilieren?

Edit: Ich will ja nix falsch machen

Reicht es denn dann, die config zu speichern nach make-kpkg --config=menuconfig?

nepos · Beitrag von **nepos** » 18.09.2006 15:47:10

Lies dir bitte mal das Kapitel dazu im Debiananwenderhandbuch durch. Da ist das recht gut erklaert, wie man einen Kernel auf Debian-Way baut.

_alex_ · Beitrag von **_alex_** » 18.09.2006 16:06:56

nepos hat geschrieben:Lies dir bitte mal das Kapitel dazu im Debiananwenderhandbuch durch. Da ist das recht gut erklaert, wie man einen Kernel auf Debian-Way baut.

Ok, werd ich machen. Ist dies denn überhaupt notwendig, wenn der Eintrag oben so schon in meiner config steht?

nepos · Beitrag von **nepos** » 18.09.2006 16:43:12

Wenn in der Konfig zu deinem laufenden Kernel der Schalter drin ist, musst du normal keinen Kernel neu kompilieren. Dann sollte das schon out-of-the-box klappen.

_alex_ · Beitrag von **_alex_** » 18.09.2006 20:35:47

Dann is gut, da steht das [M] nämlich schon drin, wenn ich die config anschaue

Trotzdem weiß ch ned woran es liegt

feldmaus · Beitrag von **feldmaus** » 19.09.2006 01:21:29

Versuch es mal mit tethereal.

du musst die Vorgänge auf dem Interface protokolieren.

Wenn du keinen Fehler findest auf dem Linux Server dann ist da auch keiner,
sprich ich würde darauf tippen das es am Windows XP Client liegt.

Vielleicht schalltet er die Netzwerkkarte ab und zu aus, aus Energiespar gründen.

Wie siehts denn nun mit den log dateien aus?

_alex_ · Beitrag von **_alex_** » 19.09.2006 08:21:54

feldmann_markus hat geschrieben:Versuch es mal mit tethereal.

du musst die Vorgänge auf dem Interface protokolieren.

Wenn du keinen Fehler findest auf dem Linux Server dann ist da auch keiner,
sprich ich würde darauf tippen das es am Windows XP Client liegt.

Vielleicht schalltet er die Netzwerkkarte ab und zu aus, aus Energiespar gründen.

Wie siehts denn nun mit den log dateien aus?

Naja dann verstehe ich aber nicht, dass zwei Windows XP Rechner exakt zur selben Zeit den Ping ins Netz verlieren

In den Logs hab ich bisher nix gefunden (könnte auch daran liegen dass die ganzen Firewall Ausgaben auf einmal da drin sind)
Gestern trat der Fehler nicht auf, da ich kaum am PC war.

Hab hier mal mein syslog vom Bootvorgang, vllt. findet sich ja dort ein Fehler
http://nopaste.debianforum.de/4139

Eine andere Möglichkeit wäre vielleicht, dass ich den Zweit-PC mit einer Knoppix Live CD boote und schaue ob der dann auch Verbindungsprobleme hat.

feldmaus · Beitrag von **feldmaus** » 19.09.2006 11:41:31

Poste mal

Code: Alles auswählen

route -n

Code: Alles auswählen

ifconfig

Code: Alles auswählen

plog

Code: Alles auswählen

cat /var/log/daemon.log | grep pppd

Code: Alles auswählen

cat /var/log/daemon.log | grep eth[0-9]

Code: Alles auswählen

cat /var/log/daemon.log | grep "udev*"

und zwar wenn alles noch in Ordnung ist und wenn das Problem auftritt, zu vergleichen.

Weiterhin muss gesagt werden, dass alle Provider die Verbindung einmal am Tag trennen.
Vielleicht kann dir dein Provider mehr dazu sagen über Uhrzeit und Häufigkeit der Trennung.

Und Ändere mal dein mtu in auf 1452. Die mru kannst du lassen, frage am besten nochmal nach wegen der mru. Notfalls änderst du die auch noch auf 1452.
shau am besten in man pppd oder bei google nach wegen mru und mtu oder frag bei deinem Provider nach.

Edit by Snoopy:
Code-Tags für die Leserlichkeit eingefügt.

_alex_ · Beitrag von **_alex_** » 19.09.2006 13:05:14

Einen Provider Disconnect kann ich ausschließen, da ich ja keine neue IP bekomme.
Der Reconnect wird jeden morgen um 6.30 Uhr per Cron Job gemacht

feldmaus · Beitrag von **feldmaus** » 19.09.2006 20:03:53

_alex_ hat geschrieben:Einen Provider Disconnect kann ich ausschließen, da ich ja keine neue IP bekomme.
Der Reconnect wird jeden morgen um 6.30 Uhr per Cron Job gemacht

Ich bin da glaube ich immer noch nicht ganz im Bilde.
Auf deinem Router läuft doch pppd?

Und der bekommt doch ne IP vom Provider?

Wenn dem so ist dann kann es sein das mit der routing Tabelle auf deinem Server was schief läuft.
Daher meinte ich mache das was oben steht.

_alex_ · Beitrag von **_alex_** » 19.09.2006 20:13:47

Jo genau, auf dem läuft pppd.
Der bekommt die IP beim Einwählen.
(in messages, syslog und kern.log seh ich nur Firewall Nachrichten)
Hab die Befehle einmal während dem Problem und dann danach per Script durchgeführt:
http://nopaste.debianforum.de/4147

feldmaus · Beitrag von **feldmaus** » 19.09.2006 20:23:49

Ach so ich meinte

Code: Alles auswählen

cat /var/log/daemon.log | grep ppp

sonst zeigt er natürlich nix an.

Wenn also dieses Problem auftaucht dann acht ganz doll darauf das diese Routing Tabelle so aussieht wie du es gepostet hattest.

Wenns nicht so ist sofort bescheid sagen.

Edit by Snoopy:
Code-Tags für die Leserlichkeit eingefügt.

_alex_ · Beitrag von **_alex_** » 20.09.2006 20:46:22

So, neuer Tag, neuer Fehler

http://nopaste.debianforum.de/4165

Diesmal is es 2 mal hintereinander aufgetreten konnte aber nur beim zweiten mal mein debug Script laufen lassen

Edit: werd vllt. am WE n 2.6er Kernel installieren

Edit: komischerweise steht MTU immernoch bei 1500 obwohl ich es in der /etc/ppp/peers/dsl-provider eingestellt hab....

feldmaus · Beitrag von **feldmaus** » 21.09.2006 10:31:19

Leider kenne ich mich mit ppp nicht genügend aus.
In /etc/ppp gibt es noch andere Dateien wo man mtu und mru einstellen kann, ich würde vermuten das dort irgendwo der Wert voreingestellt werden kann.
Finde und vernichte ihn.

_alex_ · Beitrag von **_alex_** » 21.09.2006 10:57:32

Ich hab jetzt mal in meinem Firewall Script das hier eingetragen, jetz stimmt der MTU

nepos hat geschrieben:Es gibt eine Regel fuer iptables, mit der das ganze MTU-Geschraube nicht noetig ist:
Code: Alles auswählen
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
Das ist das einzige, was auf meinem Router eingestellt ist und es klappt.

Aber soweit ich gesehen hab, unterscheiden sich die Logs kaum

feldmaus · Beitrag von **feldmaus** » 21.09.2006 11:08:21

stell mal die mru auch auf 1452.

Ich meine das sowohl mtu und mru auf 1452 eingestellt werden müssen.

Schau mal ob du eine Datei,
/var/log/ppp-connect-errors
besitzt.

Wenn dann poste es mal.

Und schau mal in /etc/ppp/options, ob dort was mit mtu und mru steht.

Ach so und mach das mal lieber nicht mit Gewalt über die Firewall.
Dann ist es mit dem Nachprüfen der logs so schlecht.

mtu und mru Optionen erst über all raussnehmen, und dann in deiner /etc/ppp/dsl-provider
Datei(oder wie auch immer bei dir heisst)
mtu 1452
mru 1452
eintragen.

feldmaus · Beitrag von **feldmaus** » 21.09.2006 11:23:25

Ein Auszug aus der
man pppoe,

Code: Alles auswählen

NOTES
       For  best  results,  you  must give pppd an mtu option of 1492.  I have
       observed problems with  excessively-large  frames  unless  I  set  this
       option.   Also, if pppoe is running on a firewall machine, all machines
       behind the firewall should have MTU's of 1412.

       If you have problems, check your system logs.  pppoe  logs  interesting
       things  to syslog.  You may have to turn on logging of debug-level mes-
       sages for complete diagnosis.

Habe weiterhin noch was informatives zu mru und mtu gefunden,
http://www.linux-magazin.de/Service/Boo ... htm#idx987

Setz den mtu und mru Wert trotzdem so wie ich ober geschrieben habe.

_alex_ · Beitrag von **_alex_** » 21.09.2006 12:30:40

feldmann_markus hat geschrieben:stell mal die mru auch auf 1452.

Ich meine das sowohl mtu und mru auf 1452 eingestellt werden müssen.

Schau mal ob du eine Datei,
/var/log/ppp-connect-errors
besitzt.

Wenn dann poste es mal.

Und schau mal in /etc/ppp/options, ob dort was mit mtu und mru steht.

Ach so und mach das mal lieber nicht mit Gewalt über die Firewall.
Dann ist es mit dem Nachprüfen der logs so schlecht.

mtu und mru Optionen erst über all raussnehmen, und dann in deiner /etc/ppp/dsl-provider
Datei(oder wie auch immer bei dir heisst)
mtu 1452
mru 1452
eintragen.

So, hab die MTU in der dsl-provider umgestellt und den Teil im Firewall Script auskommentiert.
Leider sagt mir ifconfig bei ppp0 wäre die MTU immernoch 1492.
In der ppp-connect-errors steht leider nix