[solved] Ethernet Verbindung hängt

[mutetella]

Hallo,

ich habe meinen Laptop (Client, 192.168.1.7) über einen Switch mit einem anderen Laptop (Samba-Server, 192.168.1.5) verbunden. Wenn ich zuerst die Schnittstelle des Servers aktiviere und danach die des Clients, funktioniert erstmal alles ganz gut, wobei nach einer gewissen, unbestimmten Zeit die Verbindung "hängt". Aktiviere ich dagegen zuerst die Schnittstelle des Clients und danach die des Servers, erhalte ich eine dauerhaft stabile Verbindung.

Was kann das sein?

mutetella

[mat6937]

..., wobei nach einer gewissen, unbestimmten Zeit die Verbindung "hängt". Aktiviere ich dagegen zuerst die Schnittstelle des Clients und danach die des Servers, erhalte ich eine dauerhaft stabile Verbindung.

Wie sind auf dem Laptop-Client und auf dem Laptop-Server, in beiden Fällen (d. h. wenn die Verbindung "hängt" und wenn die Verbindung dauerhaft stabil ist), die Ausgaben von:

Code: Alles auswählen

arp -av
route -n
sudo tcpdump -c 200 -vvveni any arp

?

[mutetella]

Hab' die Ausgaben mal ins NoPaste gelegt: http://nopaste.debianforum.de/38177

Danke schon mal für's drüberschauen, mir sagt das jetzt leider nicht wirklich was...

mutetella

[mat6937]

..., mir sagt das jetzt leider nicht wirklich was...

Bei hängender Verbindung ist auf dem Server der arp-cache-Eintrag für den Laptop-Client nicht vollständig (keine MAC-Adresse):

Server bei hängender Verbindung:

root@server:/home/mutetella# arp -av
? (192.168.0.100) auf 00:13:33:aa:64:dd [ether] auf wlan0
? (192.168.1.7) auf <unvollständig> auf eth0
? (192.168.0.1) auf f8:1a:67:5a:a5:d9 [ether] auf wlan0
Einträge: 3 Ignoriert: 0 Gefunden: 3

Auf die arp-requests beider Seiten, kommt von keiner Seite ein arp-reply an (siehe tcpdump-Ausgabe bei hängender Verbindung):
Client:(192.168.1.7)

Code: Alles auswählen

18:05:43.886038 Out 00:23:56:9c:13:58 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.5 tell 192.168.1.7, length 28
18:05:44.886056 Out 00:23:56:9c:13:58 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.5 tell 192.168.1.7, length 28
18:05:45.890049 Out 00:23:56:9c:13:58 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.5 tell 192.168.1.7, length 28

Server:(192.168.1.5)

Code: Alles auswählen

18:05:43.486655 Out 00:26:9e:c6:92:08 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.7 tell 192.168.1.5, length 28
18:05:44.486570 Out 00:26:9e:c6:92:08 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.7 tell 192.168.1.5, length 28
18:05:45.486571 Out 00:26:9e:c6:92:08 ethertype ARP (0x0806), length 44: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.7 tell 192.168.1.5, length 28

Versuch mal auf dem Server, mit einem statischen arp-cache-Eintrag für den Laptop-Client.

[mutetella]

@mat6937
Erstmal Danke! für Deine Hilfe...

Wenn die Verbindung hängt, hilft momentan nur, wenn ich zeitnah am Server die Schnittstelle neu starte. Wenn ich zu lange warte, muss ich die Schnittstelle auch beim Client neu initialisieren.

Ein statischer arp-Eintrag beim Server bringt keine Änderung. Wobei ich meine ursprüngliche Beobachtung revidieren muss. Es ist egal, wer als erstes startet. Ich habe solange eine stabile Verbindung, so lange beim Server (ein Laptop X100e) der Bildschirm an ist. Sobald der abschaltet ist auch die Verbindung weg, selbst wenn währenddessen ein Zugriff stattfindet...

Vielleicht 'ne doofe Stromspareinstellung? Aber warum verliert er den arp-Eintrag?

mutetella

[mat6937]

Ich habe solange eine stabile Verbindung, so lange beim Server (ein Laptop X100e) der Bildschirm an ist. Sobald der abschaltet ist auch die Verbindung weg, selbst wenn währenddessen ein Zugriff stattfindet...

Ich denke, dass wird eine Frage der Konfiguration sein.

[mutetella]

Ich denke, dass wird eine Frage der Konfiguration sein.

Hmm, nur welcher Konfiguration? Hab' powersave Einstellungen gesucht und außer ``/sys/class/net/eth0/power/control`` nix gefunden. Und den Parameter von "auto" auf "0" oder "off" zu setzen geht nicht. Und einfach nur blind herumstochern möcht' ich auch nicht...

Bin tatsächlich ziemlich ratlos... Wenn der Server (Laptop) seinen Bildschirm abschaltet, geschieht eben auch irgendetwas auf der ``eth0``. Nur was?

mutetella

[mat6937]

Bin tatsächlich ziemlich ratlos...

Versuch mal nur als Test, mit statischen arp-cache-Eintragungen für Server und Client, mit je einem ausführbaren Script im Verzeichnis "/etc/network/ip-up.d" von Server und Client.

[mutetella]

Ob mit ``/etc/network/if-up.d/static_arp_cache`` script

Code: Alles auswählen

#!/bin/sh

arp -s 192.168.1.5 m:a:c:a:d:r

oder ohne macht keinen Unterschied.

Wobei mir jetzt folgendes aufgefallen ist: Wenn der Server-Laptop seinen Zustand wechselt (Bildschirm wird weiß, wahrscheinlich irgendein powersave-mode) kann ich ihn trotzdem weiterhin anpingen und auch eine ssh-Sitzung aufbauen. Die ethernet-Verbindung hängt erst, wenn ich auf ein gemountetes Sambashare stärker zugreife:

Code: Alles auswählen

$ ls -laR /mnt/srv/Dokumente

Die ersten paar Verzeichnisse werden noch gelistet, immer genau an derselben Stelle hängt er dann. Danach geht nix mehr, kein ``ping``, kein ``ssh``. Erst wenn ich auf dem Server-Laptop das eth0-Interface wieder neu starte geht's weiter.

Vielleicht doch ein Samba-/Mount-Problem? Aber weshalb die fehlerhaften arp-cache Einträge?

mutetella

[mutetella]

UPDATE: Wenn der Server-Laptop den Zustand wechselt und ich auf das Sambashare erst zugreife, nachdem ich ihn wieder zurückgeholt habe, funktioniert alles. Das Problem besteht also tatsächlich nur während sich der Server-Laptop in diesem ominösen Zustand befindet. Wie kann ich denn herausfinden, was da passiert?

mutetella

[mutetella]

Ok, nachdem ich durch mat6937 darauf aufmerksam wurde, dass die Schnittstelle des Servers nach ~ 10 Minuten nicht mehr ansprechbar ist, schaut die momentane Lösung für mich so aus, dass ich acpi komplett über die Kernel-Bootoption ``acpi=off`` deaktiviere. Eine Möglichkeit, die Stromsparfunktion nur für die Ethernetschnittstelle zu deaktivieren, hab' ich noch nicht finden können (``ethtool``??), wobei ich mir auch noch gar nicht wirklich sicher bin, ob das Problem tatsächlich bei der Schnittstelle liegt.

Vielleicht hat ja noch jemand Inspiration für mich...?

mutetella

[mutetella]

UPDATE: Hab' das Server-Laptop mal mit einem HooToo USB-Ethernet Adapter (ASIX 88179, ``ax88179_178a`` module) verbunden und mit acpi gestartet. Auch während dem Stromsparmodus funktioniert alles. Es scheint also tatsächlich am internen Ethernetinterface (RTL8111, ``r8169`` module) zu liegen.

Wie auch immer: Das Glück, dass jetzt alles funktioniert überwiegt der Neugier, da noch mit anderen Maschinen zu experimentieren!

Danke für die Hilfe!!!

mutetella

[mat6937]

Es scheint also tatsächlich am internen Ethernetinterface (RTL8111, ``r8169`` module) zu liegen.

Evtl. kannst Du das Modul "r8169" konfigurieren. Siehe z. B. die Ausgaben von:

Code: Alles auswählen

modinfo r8169 | grep -iE 'depends|parm'
lsmod | grep -i r8169

[mutetella]

@mat6937
Hmm, wäre zu schön gewesen, aber leider Fehlanzeige, powersave-Einstellungen (sofern überhaupt vorhanden) lassen sich nicht beeinflussen.

Jedenfalls danke für den Hinweis!

mutetella