Zugschlusbeobachtungen (Entries tagged as windows)

Woran erkennt man unter Windows laufende Displays

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 29 Jan 2009 17:03:00 +0100

Richtig, an der mittig über der laufenden Präsentation liegenden Fehlermeldung.

Abgründe bei der Installation von Windows XP auf nicht ganz alter Hardware

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 07 Oct 2008 22:10:20 +0200

Frau K. bekommt den nach meinem Notebook von 2005 zweitneuesten Rechner, den ich mir eigentlich als Arbeitsplatzrechner für mich selbst ausgeguckt habe, der aber aufgrund seines räudigen nForce-Chipsatzes nicht mit der DVB-S-Karte wollte. Die in dem Artikel angesprochene Windows-Lizenz habe ich endlich organisieren können, und so ging es heute an die Installation, zunächst eines “richtigen” Windows, das direkt auf der Hardware läuft.

Dieses Vorhaben kam leider schnell zu einem Halt, denn das Ende dieses Monats sieben Jahre alt werdende Spitzenprodukt des Marktführers findet die SATA-Festplatte des viereinhalb Jahre alten Rechners nicht und behauptet, keine Platte zu sehen. Die vom Hersteller vorgesehene Methode, einen zum Massenspeicher passenden Treiber von Diskette (!) nachzuladen, scheitert (A) am Nichtvorhandensein eines Diskettenlaufwerks im Zielssystem und (B) daran, dass der Mainboardhersteller die aktuellen SATA-Treiber in einer Form zum Download bereithält, die aufgrund der Dateigröße von knapp 30 MB nicht darauf schließen lässt, dass sie auf eine Diskette passen würden. Der Betrieb der Platte im Legacy-Modus scheidet aus Eitelkeitsgründen aus: Ich werde nicht auf einem nagelneu installierten System mit einer Altlast beginnen, da könnte man ja gleich das A20-Gate mit ins Jahr 2010 nehmen.

Dafür verrät einem die allwissende Suchmaschine, dass Windows XP ab Service Pack 2 SATA auch im AHCI-Modus unterstützt. Nur drei Stunden später ist ein ISO-Image erstellt, dass (A) Service Pack 3 hineingeslipstreamed hat, (B) bootfähig ist und (C) klein genug ist um noch auf einen CD-Rohling zu passen. Leider stelle ich dann fest, dass die oben zitierte Aussage leider nicht korrekt war und der Installationsprozess wiederum mit “Keine Festplatte gefunden, drücken Sie F3 um den Computer neu zu starten” verstirbt.

Weitere Bedienungen der Suchmaschine bleiben unerfolgreich; auch die Microsoft-Knowledgebase hat keine konkreten Hilfen, um das im Enterprise-Bereich immer noch marktführende Desktop-Betriebssystem auf aktueller Hardware ohne historische Peripherie zu installieren.

Im Usenet bekomme ich schließlich Hinweise, wie man die Treiber als Pseudo-OEM auf eine Diskette slipstreamen kann. Leider sind diese Hinwesise auf einem derartig hohen Niveau, dass sie mein Windows-Wissen übersteigen. Auch wird mir dort wärmstens empfohlen, nicht die vier Jahre alten SATA-Treiber vom Mainboardhersteller, sondern die aktuellen vom Chiphersteller zu nehmen. Ich versage auf der Suche nach der in der Antwort genannten konkreten Version, finde nur eine ein Jahr ältere Version für den auf dem Mainboard verbauten SATA-Chip, breche an dieser Stelle ab und nehme die Treiber vom Mainboardhersteller.

Da ich keine Lust auf das Verbrennen weiterer CD-Rohlinge habe, wühle ich im Asservatenschrank und finde noch ein Diskettenlaufwerk samt dazugehörigem Kabel. Das Mainboard hat zum Glück noch einen Diskettenanschluß, und eine Diskette finde ich auch noch. Dann ein grml booten, und den Rechner unter Linux dazu benutzen, die SATA-Treiber vom USB-Stick auf die Diskette zu kopieren und dann darf ich endlich nach dem Boot von CD F6 drücken und mich darüber freuen, dass der Rechner sich endlich darüber bewusst ist, eine Festplatte zu haben. Was ein Kampf!

Dass ich schließlich den USB-Stick nochmal brauche, um dem Rechner beizubringen, dass er neben der Festplatte auch noch ein Ethernet hat, ist beim Marktführer-Betriebssystem so logisch, dass ich es nicht mehr extra erwähne. Dann beginnt die Post-SP3-Update-Orgie, denn wenigstens das Slipstreaming des Service-Packs hat funktioniert, was die Geschichte sicher um zwei Stunden abkürzt.

Und da sage bitte nochmal jemand, Linux installieren sei kompliziert und bräuchte besonderes Knowhow. Immerhin kommt man unter Linux in aller Regel ohne prähistorische Speichermedien aus.

Weird networking MTU issue

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 11 Oct 2006 15:17:00 +0200

Given a simple, switched LAN with Debian Linux (sid, iputils-ping) and Microsoft Windows XP (Service Pack 2, with the Windows Firewall disabled). A user complains about the network being slow (meaning his Windows notebook). I quickly find out that I can ping the box from my Linux notebook if my -s parameter is < 1393 or > 1472. If it’s between 1393 and 1472, no replies are received.

I spend the next hour with debugging this not so interesting phenomenon.

Consulting with my Windows colleagues, they quickly find out that “it must be a Linux issue”, since if it’s a Windows box issueing the ICMP echo request, everything is fine.

Unfortunately, this issue cannot be reproduced with most of the test Windows boxes we have available. After finally finding an available test box which shows the issue, I install Wireshark on the Windows box, which is a rather pleasing experience since Wireshark has a clickable .exe installer that also takes care of installing the winpacap library. This is a lot less painful than it was with Ethereal two years ago.

Looking at the packet trace, the issue is quickly explained.

iputils-ping sends out the ICMP echo request packets with the “don’t fragment” bit set.
Windows’ ping allows fragmentation by keeping the “don’t fragment” unset.
If the echo request is smaller than 1393 bytes, everything is fine. The Windows box answers as it is supposed to. It doesn’t matter whether the request is from Linux or from Windows since fragmentation does not play a role here.
If the echo request is bigger than 1472 data bytes, the request needs to be fragmented as the Linux box’ MTU is 1500. In this case, iputils-ping - of course - does not set the DF bit, and the Windows box sends back a properly fragmented echo reply. Same thing happens - of course - with the Windows-generated ping since Windows’ ping never sets DF.
Now, if the Linux-generated echo request (thus having DF set) is within the size range mentioned above, Windows does not answer at all.
If the Windows-generated echo request (not having DF set) is within the appropriate size range, the request fits in a single frame. Windows fragments the reply with the first fragment being 1434 bytes long.

I now place the hypothesis that some of our Windows boxes operate with a MTU of 1434. Thus, it is not supposed to answer the Linux-generated echo request (with DF set) if it cannot send back the answer unfragmented. It is, however, IMO, supposed to send back a “host unreachable, fragmentation needed but DF set” ICMP error packet. It doesn’t do that, which causes the behavior observed.

The Windows boxes in question do not have an “MTU” option in the advanced settings of the network interface as other boxes have, and the appropriate Registry key setting the MTU is missing in the adapter settings.

I am now wondering whether my reasoning is wrong, or Windows is indeed buggy. Or misconfigured.

Any ideas?

DHCP challenges

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 19 May 2006 12:29:16 +0200

My notebook’s DHCP setup seems to be a challenge for DHCP servers around the world. Looks like almost no server implements the standard in a decently complete way.

My notebook has a wired Fast Ethernet, and a wireless 802.11bg network interface. Of course, both interfaces have their own MAC address. I want the thing to work at least at home, regardless of whether wired or wireless is in use, with preferably the same static IP address, and on the office wired network, again, with the static IP address allocated to me there.

Configuring this is considerably harder than I expected.

At home, I am using a Linksys WRT54G router with OpenWRT, which has dnsmasq as DHCP server. Unfortunately, dnsmasq does not support the case where multiple MAC addresses are statically assigned to the same IP address: Only the first dhcp-host statement in the configuration file is honored, all others are ignored.

So we need to resort to using a dhcp client-identifier. In DHCP request option number 61, the client can send an identifier, which the Server can then use to determine the client’s identity and assign a static IP address. The client identifier, according to RFC2132, is to be treated as an opaque string by the DHCP server.

This works fine with dnsmasq, solving the issue at home. But it causes more grief in the office network.

My office is the kind of place where a non-Microsoft solution is rarely considered. Thus, our network is fully buzzword compliant and the network infrastructure, including DNS and DHCP servers, is based on Windows Server System. I am the only one using a non-MS operating system in my work environment. When I plugged my notebook into the network this morning, I noticed that I didn’t receive my static IP address but a different one from the dynamic pool.

After verifying that the Windows guys didn’t touch the DHCP server in the last days, I began to think what I changed locally and naturally remembered configuring the DHCP client identifier. Removed it for testing, got my normal static IP address, so the client identifier was quickly pinned down as the culprit.

After my Windows colleagues decided that it must be a client issue, I began investigating how to configure the Windows DHCP server to honor a client identifier. MS Knowledge Base article #172408, “Custom DHCP Client Identifiers for Windows NT”, is a high hit on Google, but is like three years old and shows that somebody at MS has badly misunderstood the DHCP standard - they think that the Client Identifier is a 4 byte number in little endian order.

I couldn’t believe that and investigated further. But it looks like the Windows DHCP server really cannot handle free-form client identifiers at all. I tried coding my free-form identifier in ASCII and entering it as MAC address, big endian, little endian, to no avail. So, I have come to the conclusion that MS has - again - only partly implemented a very important protocol for their network software. “Embrace and extend”, my <censored>, DHCP wasn’t extended at all. Looks like they stopped developing after the first developer box had successfully received an IP address, and shipped the resulting code. Woah.

If somebody can tell me how to configure the Windows DHCP server to properly handle a free-form string DHCP client identfier, I’ll be most graceful for that information.

I finally resorted to setting the DHCP client identifier of my notebook to the MAC address of the wired ethernet interface, which has at least brought my static IP address at the office back. I hope that the dnsmasq at home will successfully grok this or I am - again - back to square one.

All software sucks

Mit putty von Windows auf unixoides

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 28 Feb 2006 19:38:04 +0100

Steve Friedl hat mal wieder einen exzellenten Artikel geschrieben, diesmal darüber, wie man von einem Windows-Rechner per ssh auf einen unixoiden Server zugreifen kann. Das ganze ist auf Windows-Level geschrieben, mit vielen Screenshots etc.

Ein anderer Artikel von ihm zum Thema “SSH Agent Forwarding” findet sich ebenfalls.

Selbst ausprobiert hab ich die Anleitung nicht, da ich selbst einen openssh-Client im rxvt von cygwin verwende, wenn ich mit Geld dazu gezwungen werde, mit einem Windows-Arbeitsplatz zu arbeiten.

D-Link macht Linux inkompatibel mit Linux

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 26 Feb 2006 16:07:48 +0100

D-Link hat mit der DSL-xxxT-Linie

eine Produktreihe von DSL-Routern mit MIPS-Chip, die mit Montavista Linux ausgeliefert werden. OpenWRT ist für diese Hardware verfügbar.

Nun ist vor einigen Wochen ein User auf der netfilter-Mailingliste aufgeschlagen, dessen 504T nicht mit dem Linu-Rechner des Anwenders wollte: Außer ping hat nix funktioniert. Nun, diese Fehlermeldung ist nicht eben wirklich exakt, und deswegen enthalte ich mich eines Urteils, ob der User nun einen Fehler gemacht hat oder nicht.

Der Hammer ist allerdings die Reaktion von D-Link auf die Supportanfrage des Users. Sie besteht aus dem einzigen Satz “Der DSL-504T ist leider nicht kompatibel mit Linux”.

Das muss man sich mal auf der Zunge zergehen lassen: Da wird ein Stück Hardware ausgeliefert, das Linux als das eigene Betriebssystem verwendet. Und man hat es tatsächlich hinbekommen, dieses Linux mit einem anderen Linux inkompatbel zu machen und verkauft das dann auch noch als Feature. Bemerkenswert.