Högis Dungeon

Und jetzt erst recht!

Scheintod einer Netzwerkkarte

Dieses Problem ließ mir schon längere Zeit keine Ruhe, doch wollte sich einfach keine Lösung finden – bis heute.

Wir haben für unsere mobilen Nutzer hauptsächlich ThinkPad-Notebooks von Lenovo im Einsatz, eines davon das Modell X220. Zwar schon etwas in die Jahre gekommen wurde es durch den Einbau einer SSD einer Verjüngungskur unterzogen. Besitzer (und Admin) soweit glücklich und zufrieden – bis zum (scheinbaren) Tod der Ethernet-Schnittstelle. Von einem Moment auf den anderen konnte keine Netzwerkverbindung mehr via Kabel – weder über die Dock-Station noch über den integrierten Port – hergestellt werden; die Schnittstelle hing im Windows Netzwerk- und Freigabecenter schier endlos im Stadium “Netzwerkidentifizierung…” fest und bekam einfach keine IP-Adresse.

Treiber aktualisieren!

Standardvorgehensweise (zumindest unter Windows), wenn ein Netzwerk-Adapter zickt; Treiber neu installieren bzw. auf neuesten Stand bringen. Leider erfolglos.

Kabel tauschen!

Einige durchprobiert, kein Unterschied. Auch die Buchse war in optisch einwandfreiem Zustand.

An anderen Switch hängen!

Ebenso einige durchprobiert, Speed und Duplex auf automatisch, von Hand oder auf skurrile Werte geändert; kein Glück.

Das Internet nach ähnlichen Fällen abgrasen!

Zahllose Forenbeiträge gewälzt, verschiedenste Suchbegriffe verwendet, Lösungsvorschläge, Tools, Registry-Hacks ausprobiert; hat die Karte kalt gelassen.

Tja, dann neu aufsetzen!

Die letzte Verzweiflungstat wenn nicht mal mehr das allwissende Internet hilft. Also Windows 7 neu drauf gebügelt und siehe da: das Problem besteht noch immer!!^1! In-Place Upgrade auf Windows 10 gemacht (denn das hilft ja bekanntlich immer); vollkommen egal, kein Netzwerk!

Dann liegt wohl ein Hardware-Defekt vor…

…sollte man meinen. Zum Glück wurde das Gerät nicht aus Wut und Verzweiflung entsorgt, denn man lese gespannt weiter 

An der falschen Stelle gesucht

Jetzt schlägt’s aber Dreizehn!  Als Vollbluttechniker kann ich sowas nicht auf sich beruhen lassen, es muss doch eine vernünftige Erklärung – und vor allem Lösung – für dieses Verhalten geben.

In einer ruhigen Minute konnte ich das Problem noch weiter eingrenzen; vergibt man dem Adapter eine statische IP-Adresse kommt man wieder ins Netz! Ok, daran hätte man schon früher denken können, aber zumindest ist nun gewiss, dass die Karte keinen physischen Defekt ausweist. Also ein Problem mit dem DHCP…?  Unser Windows DHCP-Server verrichtet aber nun schon seit Jahren unbeschwert seine Dienste und kein anderes IP-fähiges Gerät im selben Netz ist betroffen  Na was soll’s, dann schließen wir das eben auch noch aus. Also schnell einen DHCP-Server aufs Analyse-Laptop gepackt und das Problemkind direkt angestöpselt… und es klappt! 

Ok, eine heiße Spur, endlich! Jetzt will ich wissen, was sich auf der Leitung tut. Also etwas tiefer in die Trickkiste greifen und den guten alten Netzwerk-Sniffer auspacken, Gerät wieder am nicht-kooperierenden Netzwerk angeschlossen und mal auf BOOTP/DHCP gefiltert:

23-05-_2016_15-06-38

Ok, so weit so gut; wir haben einen DHCP Request, ein Offer vom Server mit einer IP im richtigen Netz und…

23-05-_2016_15-06-51

…ein NAK?!  Nach jedem Request/Offer?!

23-05-_2016_15-07-14

Und das Spiel wiederholt sich, mehrere hundert bis tausend Male; eine DHCP-Endlosschleife!

Na super! Jetzt wissen wir zumindest mal was das eigentliche Problem ist; unser DHCP-Server bietet dem Client scheinheilig eine gültige Adresse an, der Client möchte diese annehmen, wird nun jedoch abgelehnt (NAK) und der Zyklus beginnt von neuem. Anstatt bei der nächsten Anfrage eine neue, freie Adresse anzubieten, gibt der Server nun immer wieder dieselbe zurück und verweigert dem Client die finale Zusage. Endlosschleife. Gibt scheinbar nicht mal einen Timeout-Mechanismus, die Netzwerkidentifizierung steckt in diesem Stadium mehrere Minuten (und wahrscheinlich auch Stunden) fest.

Die Lösung

Also ist doch unser DHCP-Server Schuld an diesem Debakel, wer hätte das gedacht!  Jetzt müssen wir nur noch der Lösung auf die Spur kommen. Also mal am Server die Managementkonsole gestartet und die vorhandenen Leases inspiziert. Da sticht plötzlich unter den Reservierungen die Adresse hervor, welche dem Client permanent angeboten wird:

23-05-_2016_14-46-54

Äh, sowohl der Hostname als auch die MAC-Adresse gehören nicht zu dem betroffenen Client…  Egal, das ist die verdächtige IP, also Reservierung auf gut Glück kicken und das Laptop neu anstöpseln:

23-05-_2016_14-59-54

Hey, sieh’ an; eine neue Adresse wird angeboten! 

23-05-_2016_15-00-27

Und wir dürfen sie behalten!  Mysterium gelöst!

Schlusswort

Hin und wieder stößt man in der IT auf Probleme der Kategorie “Also das habe ich ja noch nicht erlebt…”, recherchiert stundenlang, grübelt endlos und erlangt dann schließlich doch noch die Erleuchtung und findet die Lösung. Ein gutes Gefühl 

Quellen


Fatal error: Uncaught exception 'TeamSpeak3_Transport_Exception' with message 'connection to server '127.0.0.1:10011' lost' in /var/www/wordpress/htdocs/wp-content/plugins/teamspeak-3-viewer-plugin-for-wordpress-widget/libraries/TeamSpeak3/Transport/TCP.php:108 Stack trace: #0 /var/www/wordpress/htdocs/wp-content/plugins/teamspeak-3-viewer-plugin-for-wordpress-widget/libraries/TeamSpeak3/Adapter/ServerQuery.php(77): TeamSpeak3_Transport_TCP->readLine() #1 /var/www/wordpress/htdocs/wp-content/plugins/teamspeak-3-viewer-plugin-for-wordpress-widget/libraries/TeamSpeak3/Transport/Abstract.php(102): TeamSpeak3_Adapter_ServerQuery->__destruct() #2 [internal function]: TeamSpeak3_Transport_Abstract->__destruct() #3 {main} thrown in /var/www/wordpress/htdocs/wp-content/plugins/teamspeak-3-viewer-plugin-for-wordpress-widget/libraries/TeamSpeak3/Transport/TCP.php on line 108