Beruflich nutze ich ein Dell Latitude D830. Über Dells QuickSet-Software ist es möglich, die Option zu aktivieren, bei abgezogenem Netzgerät und abgezogenem Netzwerkkabel die interne Netzwerkkarte abzuschalten, um Strom zu sparen. Diese Option war bis heute auf meinem Laptop aktiviert.

Gestern war ich bei einem Kundentermin und habe dort meinen Laptop in oben beschriebener Weise verwendet. Als ich nun heute morgen den Rechner auf dem Schreibtisch wieder an die Peripherie angeschlossen hatte und die Mails des vergangenen Tages lesen wollte, stellte ich fest, dass ich keine Netzwerkverbindung hatte. Nach einiger Suche stellte sich heraus, dass eben die interne Netzwerkkarte abgeschaltet war. Leider gibt es keinen Button, um sie wieder zum Leben zu erwecken. Aus das Anschließen der für diesen Zustand verantwortlichen Peripherie in jeglicher Reihenfolge brachte keine Besserung. Beheben ließ sich das Problem nur durch die Deinstallation und anschließende Neuinstallation der Netzwerkkarte im DeviceManager. Im Anschluss an diese Prozedur empfiehlt es sich, die Stromsparfunktion abzuschalten.

Nun, ein seltsames Problem ist mir da über den Weg gelaufen. Letzte Woche ist mein neues Werkzeug angekommen; Ein Laptop soll meine Shuttle-PC ersetzen. Heute habe ich zum ersten Mal die Windows-Version unseres aktuellen Projekts gestartet und dabei ein Verhalten beobachtet, dass mir bereits einige Entwickler aus dem Team berichtet hatten, ich jedoch nicht reproduzieren konnte.

Der Laptop ist mit einem Kabel am Netzwerk angeschlossen. Das Kabel  war vorher an einem i.LON 100 internet server angeschlossen, für den ich ein Netzwerk-Interface programmiert habe. Da dies nun abgeschlossen ist, habe ich dem Server einfach mal das Kabel geklaut und meinen Laptop damit verbunden. Als ich nun die Software angeworfen habe, hat diese auch schön brav die Konfigurationsdatei für das Interface gefunden, die EInstellungen ausgelesen und wollte diese mit dem Server angleichen. Also, Socket aufmachen und Packete tauschen. Was ja nicht funktioniert, da der Server nicht am Netzwerk hängt. Allerdings schlug beim connect() nicht der Timeout zu, sondern es wurde eine korrekte Verbindung gemeldet.

Auf die Schnelle konnte ich im Netz nichts finden, auch eine andere Entwickler hatten dies noch nicht beobachtet. Ich dachte daher, dass es an der geänderten Netzwerkhardware oder dem Treiber liegen müssen. Also habe ich den aktuellsten Treiber installiert; jedoch ohne Erfolg.

Gerade bin ich jedoch auf eine interessante Seite gestoßen: Die winsock Implementierung meldet immer einen erfolgreichen connect, wenn eine Modemverbindung verfügbar ist. Wobei verfügbar nicht mit geöffnet zu verwechseln ist, sondern wenn ein Modem vorhanden ist.

Ich werde also morgen mal im BIOS das Modem des Laptops deaktivieren und dann mal schauen, ob ich noch immer einen erfolgreichen Verbindungsversuch gemeldet bekomme. Für mich als Winsock-Neuling auf jeden Fall ein lehrhafter Tag. Morgen mehr...

Nachtrag 31.07.08:
Es ist nicht ganz beim 29.07. geblieben. Allerdings habe ich mittlerweile einige Test durchgeführt. Weder das Ausschalten des Modems in Gerätemanager noch das Ausschalten des Modems im BIOS hat das Ergebnis de Connect-Methode beeinflusst. Ich werde das ganze noch einige Male beobachten. Vlt. hat ja noch jemand eine Idee? Sollte sich was ergeben, werde ich es natürlich hier bekannt geben.

Ich hoffe, dass mein Handyvertrag jetzt schneller ausläuft und mein Provider des Vertrauens das kleine Juwel in sein Portfolio übernimmt. Man sehe uns staune... das iPhone ist ja wohl ein Witz dagegen. Darauf läuft ja noch nicht einmal ein .NET Framework ;)