Debian legt Netzwerk lahm

[sec-fox]

Folgendes Problem: Wenn ich meinen Debian-Rechner ins Netzwerk hänge, legt das fast den gesamten Netzwerkbetrieb lahm. "FAST" heißt, dass das Netzwerk scheinbar noch geht, wenn auch nur ab und zu (ich habe den Eindruck, denn manchmal klappt noch irgendwas) einzelne Pakete durchkommen. Die Transfer-LED am Switch blinkt in kurzen Abständen kontinuierlich. Sobald ich das RJ-45 aus dem Swtich oder dem Linuxrechner ziehe, geht wieder alles. Das wechseln der Netzwerkkarte brachte keinen Erfolgt. (Ich kann mir nicht vorstellen, dass alle 3 defekt sind.) Das einzige auffällige ist meiner Ansicht nach die permanente Sendewarteschlangenlänge:1000, oder ist das normal? Hat das Problem schonmal jemand gehabt? Sollte es an einer anderen Hardwarekomponente des Rechner liegen? (Der Rechner ist nicht mehr der neuste ... 800 mhz Duron auf nem K7SEM Board mit 384 mb sd ... hab leider nix anderes. ^^)

Danke für schnelle Antwort. Bis morgen muss das Problem gelöst sein!

[herrchen]

Wenn ich meinen Debian-Rechner ins Netzwerk hänge, legt das fast den gesamten Netzwerkbetrieb lahm.

du könntest damit anfangen, rauszufinden, was er machen will.
was für prozesse laufen (ps aux)?
mit "tcpdump" kannst du schauen, was er ins netzwerk loswerden will ...

herrchen

[rendegast]

Hallo,

Ist das Kabel auch in Ordnung?
CrossLink? Normales Ethernet? wie bei den anderen Rechnern?
(-> Kabeltausch gegen ein sicher funktionierendes)

Benutzt Du eine Uplink-Buchse? (diese sind oft schaltbar)
Hast Du mal eine andere Buchse am Switch ausprobiert?

Bis hierher wäre es noch ein HardwareProblem
--------------------------

Soll der Debian-Rechner eine ganz normale Client-Maschine sein?
Oder hat er eine Sonderfunktion? (als PDC zum Beispiel, wobei aber noch ein PDC im Netzwerk existiert)

[sec-fox]

Diesen Command gibt es bei mir leider nicht...
-bash: tcpdump: command not found
Ich probier mal sowas zu installn, ...

Debian 3.1 vorgestern frisch Netinsall gedownloaded übrigens

[rendegast]

Code: Alles auswählen

apt-cache search tcpdump

[sec-fox]

Schon klar - und ihr wollt jetzt nen Auszug von dem, was da passiert, wenn ich tcpdump starte? Ohje... na da... mom...

Frage: Ist die Sendewarteschlangenlänge: 1000 normal oder doch ungewöhnlich?

23:36:21.521526 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
23:36:21.523850 arp who-has 10.97.99.253 tell wgwserver1
23:36:22.521252 arp who-has 10.97.99.253 tell wgwserver1
23:36:23.521251 arp who-has 10.97.99.253 tell wgwserver1
23:36:23.521460 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
23:36:23.521558 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
23:36:25.521420 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
23:36:26.531337 arp who-has 10.97.99.253 tell wgwserver1
23:36:27.531253 arp who-has 10.97.99.253 tell wgwserver1
23:36:28.531246 arp who-has 10.97.99.253 tell wgwserver1
23:36:31.542021 arp who-has 10.97.99.253 tell wgwserver1
23:36:32.541250 arp who-has 10.97.99.253 tell wgwserver1
23:36:33.541246 arp who-has 10.97.99.253 tell wgwserver1
23:36:36.521421 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:36.551288 arp who-has 10.97.99.253 tell wgwserver1
23:36:37.551250 arp who-has 10.97.99.253 tell wgwserver1
23:36:38.521437 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:38.551241 arp who-has 10.97.99.253 tell wgwserver1
23:36:40.521440 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:42.521471 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:44.521442 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:44.521558 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:46.522060 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:46.522257 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:48.521414 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:48.521628 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:50.521415 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:50.521554 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:52.521417 IP wgwserver1.netbios-ns > 10.97.99.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
23:36:52.522140 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:52.522570 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)
23:36:52.522604 IP wgwserver1.netbios-dgm > 10.97.99.255.netbios-dgm: NBT UDP PACKET(138)

Ich seh da nix böses... oder?

Übrigens2: Wenn ich ne 10 mbit Karte (da is neben dem RJ-45 noch nen Coax ^^) in dem Rechner hab, geht das Netzwerk. Mit 100 mbit-Karten hab ich die beschriebenen Probleme. Hat einer ne Erklärung?

[sec-fox]

Hallo,

Ist das Kabel auch in Ordnung?
CrossLink? Normales Ethernet? wie bei den anderen Rechnern?
(-> Kabeltausch gegen ein sicher funktionierendes)

Benutzt Du eine Uplink-Buchse? (diese sind oft schaltbar)
Hast Du mal eine andere Buchse am Switch ausprobiert?

Bis hierher wäre es noch ein HardwareProblem
--------------------------

Soll der Debian-Rechner eine ganz normale Client-Maschine sein?
Oder hat er eine Sonderfunktion? (als PDC zum Beispiel, wobei aber noch ein PDC im Netzwerk existiert)

Das einzige, das ich noch nicht probiert habe, ist, ob dieses komische blaue Netzwerkkabel jetzt alle Netzwerkkarten kaputt gemacht hat (inklusive der onboard-NW-Karte meiner Freundin in deren Rechner). Nach Kabelwechsel bestand das Problem noch immer. Ich hab so ziemlich alles probiert. Der Switch is i.o. Am Uplink (nicht umschaltbar, man kann nur wählen zwischen Uplink ODER Port1) hängt mein DSL Modem. Der Rest sind normale Ports.

tcpdump würde sich mit der 10 mbit-Karte, mit der alles inklusive der GW über meinen Windows-Rechner geht, eher lohnen. Ist doch bemerkenswert, was hier so ankommt, kreuz und quer aus dem Internet. ^^

[rendegast]

Übrigens2: Wenn ich ne 10 mbit Karte (da is neben dem RJ-45 noch nen Coax ^^) in dem Rechner hab, geht das Netzwerk. Mit 100 mbit-Karten hab ich die beschriebenen Probleme. Hat einer ne Erklärung?

vielleicht Probleme mit der Auto-Negotiation?
Kannst Du den Modus vielleicht festlegen? (mit zBsp ethtool oder beim Laden des Kartenmoduls als Option?)
Können Switch/Hub(?) und Karte denn beide 100mbit/Fullduplex?
K7SEM:
v1.0/v1.0+B1: RealTek 81XX Gigabit and Fast Ethernet Driver
v3.0A: SiS 900 LAN driver

[sec-fox]

Übrigens2: Wenn ich ne 10 mbit Karte (da is neben dem RJ-45 noch nen Coax ^^) in dem Rechner hab, geht das Netzwerk. Mit 100 mbit-Karten hab ich die beschriebenen Probleme. Hat einer ne Erklärung?

vielleicht Probleme mit der Auto-Negotiation?
Kannst Du den Modus vielleicht festlegen? (mit zBsp ethtool oder beim Laden des Kartenmoduls als Option?)
Können Switch/Hub(?) und Karte denn beide 100mbit/Fullduplex?
K7SEM:
v1.0/v1.0+B1: RealTek 81XX Gigabit and Fast Ethernet Driver
v3.0A: SiS 900 LAN driver

Swtich und Netzwerkkarte sind beide 100 mbit fullduplex-fähig. Hab meine Windows-Rechner auch mit Fullduplex laufen...

Den Modus festlegen, wäre ne Idee. Kann man ja mal probieren. Wie genau mach ich das?

[nepos]

Den Modus festlegen, wäre ne Idee. Kann man ja mal probieren. Wie genau mach ich das?

Code: Alles auswählen

ethtool -s eth0 speed 100 duplex full autoneg off

sollte das gewuenschte erledigen.
Alternativ gehts sicher auch irgendwie beim Laden des Moduls, aber dazu muesste man in dessen Doku mal nachsehen.

[sec-fox]

Mal so ne Frage nebenbei: Könnte es sein, dass man für 100/1000 mbit NW-Karten eventuell Treiber braucht? Ich meine, warum sollte der das sonst mit jeder 100-er machen, aber mit den vielen 10-ern, die ich jetzt getestet habe, geht alles einwandfrei?

[rom]

aber deine nic wird doch in dmesg angezeigt?

aus deinem auszug aus tcpdump seh ich das kein rechner auf die arp anfrage antwortet.

vielleicht solltest du mal den verkehr sniffen ohne den linux client *denk*

was hast du denn nun fürn kabel zwischen port1 des switches und deinem linux client?

normal wär ja patchkabel

welcher pc hat bei dir die ip adresse 10.97.99.253?

[sec-fox]

aber deine nic wird doch in dmesg angezeigt?

aus deinem auszug aus tcpdump seh ich das kein rechner auf die arp anfrage antwortet.

vielleicht solltest du mal den verkehr sniffen ohne den linux client *denk*

was hast du denn nun fürn kabel zwischen port1 des switches und deinem linux client?
normal wär ja patchkabel

welcher pc hat bei dir die ip adresse 10.97.99.253?

10.97.99.253 ist mein Hauptrechner (Windows) an dem ich gewöhnlich arbeite. Der Linux 10.97.99.254 stellt nur den HTTP-DHCP-DNS-Server dar. Zwischen 10.97.99.254 und dem Swich hängt richtigerweise ein Patch-Kabel (nicht gekreuzt), was aber auch egal wäre, weil Auto-MDI-X.

Was ist dmesg? Wieso sollte dieses Problem durch ARP entstehen. Ich sehe keinen Grund für ARP-Anfragen. Eventuell denke ich da falsch?

Code: Alles auswählen

ethtool -s eth0 speed 100 duplex full autoneg off

Kann man das auch irgendwie über die Datei network/interfaces regeln?

[rom]

ich habe ja nicht gesagt das arp das problem auslöst.

ich wollte nur sagen das er die mac von deinem windows pc nicht herausfindet.

dmesg listet die ausgabe vom kernel auf die vor dem starten der log-deamons ausgegeben werden.

kannst ja mal

Code: Alles auswählen

dmesg | grep eth 

ausprobieren

du weißt ja ungefähr was du fürn nic hersteller hast bzw wie deine nic heißt.
kannst es ja auch mit "lspci" prüfen.

[sec-fox]

eth0: RealTek RTL-8029 found at 0xe000, IRQ 11, 00:02:44:20:75:93.

Mehr nicht. Das ist jetzt allerdings mit der 10 mbit Karte.

0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
0000:00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
0000:00:01.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)
0000:00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
0000:00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07)
0000:00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter (rev 31)

Für die 100-er Karte muss ich erst Monitor umbauen... mom.


... Hab mir das einfacher gemacht: Hab jetzt die 100-er, die ich eben im meinem Windowsrechner für voll funktionstüchtig erklärt habe, in den Linuxrechner eingebaut (zusätzlich zu der 10-er). Im Moment ist das Kabel noch an der 10-er.

eth0: RealTek RTL-8029 found at 0xe000, IRQ 12, 00:02:44:20:75:93.
eth1: RealTek RTL8139 at 0xe400, 00:50:fc:70:cb:ed, IRQ 11
eth1: Identified 8139 chip type 'RTL-8100B/8139D'

Ich test jetzt, was passiert, wenn ich das Kabel an die 100-er Stecke...

[rom]

an dmesg siehtst du ja das deine 10er karte erkannt wird und auch die richtigen treiber geladen hat.
mit der 10er karte funktioniert wol das netzwerk?

[sec-fox]

Okay. Langsam finde ich den Mist nicht mehr lustig. Ich erzähl euch jetzt erstmal, was ich alles so für tolle Tests gemacht habe:
1. Netzwerkkabel (4 Stück) auf Funktion überprüft und ALLE gehen.
2. Netzwerkkarten (3 x 100 mbit, 2 x 10 mbit) auf Funktion überprüft und ALLE tun ihren Job, zumindest im Windowsrechner.
3. Das gleiche Debian Netinstall 3.1r2 auf dem Rechner meiner Freundin (spezifikationen nicht bekannt, aber der Rechner ist nicht alt mit 100 mbit-Karte onboard). Das Phänomen war das gleiche. 100 mbit ins Netzwerk gehangen und alles war tot. Der Rechner hat mit Windows auch noch nie Probleme gemacht.
4. Eure Lösungswege habe ich versucht, aber die waren ja bisher auch nicht weiter erfolgreich. Kann es sein, dass in dieser Deb-Version irgendwas mit den Netzwerktreibern nicht stimmt?

wgwserver1:~# kernelversion
2.4
wgwserver1:~# dmesg | grep eth
eth0: RealTek RTL-8029 found at 0xe000, IRQ 12, 00:02:44:20:75:93.
eth1: RealTek RTL8139 at 0xe400, 00:50:fc:70:cb:ed, IRQ 11
eth1: Identified 8139 chip type 'RTL-8100B/8139D'
eth1: link down
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
Hier war dann wieder das ganze Netzwerk hinüber...
eth1: link down
wgwserver1:~# lspci
0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
0000:00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
0000:00:01.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Br
idge)
0000:00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 07)
0000:00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 07)
0000:00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bri
dge (AGP)
0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C
/8139C+ (rev 10)
0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 630/730
PCI/AGP VGA Display Adapter (rev 31)

an dmesg siehtst du ja das deine 10er karte erkannt wird und auch die richtigen treiber geladen hat.
mit der 10er karte funktioniert wol das netzwerk?

Ja.

Irgendwer noch irgendwelche Ideen?