Zusammenfassung

  • RFC 1207 dokumentierte zwei Sun 3/60, die über ihre ttya-Anschlüsse per SLIP verbunden waren. ping und rlogin funktionierten, doch der NFS-Mount meldete server not responding: RPC Timed Out. Die Antwort verwies auf eine unter SunOS 3.5 deaktivierte UDP-Prüfsumme und darauf, dass SLIP keine eigene Prüfsumme mitbrachte.
  • Im selben Abschnitt stand ein anderes Hindernis: SCO TCP/IP für Xenix konnte SLIP nur mit SCO-Serientreibern nutzen. Eine intelligente Mehrportkarte mit eigenem Treiber half bei dieser Implementierung nicht. Verbindungsaufbau und brauchbarer Betrieb lagen an verschiedenen technischen Grenzen.

Der Port auf dem Einkaufszettel

Wer 1991 viele serielle Anschlüsse brauchte, konnte eine intelligente Mehrportkarte wählen. Die Zahl der Buchsen war leicht zu zählen. Schwieriger war die Frage, ob SCO TCP/IP für Xenix seinen SLIP-Dienst über deren Treiber überhaupt erreichen konnte. In RFC 1207 lautet die Antwort: SCOs SLIP funktionierte mit SCO-Serientreibern, nicht mit intelligenten Karten, die ihren eigenen Treiber lieferten. Für viele SLIP-Ports empfahl der Text mehrere einfache Anschlüsse oder eine einfache Mehrportkarte.

Das klingt wie eine kleine Kompatibilitätsnotiz. Für eine Beschaffung war es die ganze Rechnung. Ein auf dem Papier leistungsfähigeres Stück Hardware konnte die geplante Nutzung blockieren. „SLIP vorhanden“ beim Betriebssystem und „viele Ports“ auf der Karte ergaben noch keinen gemeinsamen Treiberpfad. Wer nur diese zwei Merkmale prüfte, fand die fehlende Schnittstelle erst nach dem Einbau.

Die Frage stand in einem FYI für erfahrene Internetnutzer, das G. Malkin, A. Marine und J. Reynolds im Februar 1991 veröffentlichten. Die Herausgeber hatten große Mailinglisten beobachtet, wiederkehrende Fragen gesammelt und Antworten für Betriebsteams zusammengestellt. Besonders neue Netze am Internet sollten eine verlässliche Arbeitshilfe bekommen. Auch die Listen selbst sollten von derselben immer wieder vorgetragenen Frage entlastet werden. Die Treibernotiz ist genau das Wissen, das in einer Produktübersicht leicht verschwindet und im Betrieb teuer wieder auftaucht.

Zwei bestandene Tests und eine gescheiterte Arbeit

Gleich daneben schilderte die FAQ ein anderes Problem. Zwei Sun 3/60 mit SunOS 3.5 und 4.3BSD-TCP/IP/SLIP-Paketen waren über ttya verbunden. ping funktionierte. rlogin funktionierte. Das Einbinden eines NFS-Dateisystems endete mit einem RPC-Timeout. Die Frage lautete nun nicht mehr, ob Rechner miteinander sprechen konnten. Sie lautete, warum gerade diese Dateiarbeit über eine ansonsten benutzbare Leitung scheiterte.

Die veröffentlichte Antwort beschuldigte eine Einstellung in SunOS 3.5: Die UDP-Prüfsumme war abgeschaltet. Auf Ethernet konnte das wegen der Prüfung auf der Verbindungsschicht gutgehen. SLIP selbst lieferte keine Prüfsumme. Für NFS auf dieser seriellen Strecke sollte UDP deshalb wieder prüfen. Der nächste Schritt führte an die Kernel-Einstellung, nicht an den NFS-Server.

Der vorgeschlagene Eingriff lag erstaunlich tief für eine Meldung des Dateisystems. Aber die drei Anwendungen hatten nicht dieselbe Aussagekraft. ping hatte seine eigene Erreichbarkeit geprüft, rlogin eine interaktive Sitzung. Der NFS-Mount brauchte Datenaustausch unter anderen Bedingungen. Wer vom ersten grünen Signal auf die letzte Anwendung schloss, verschenkte die einzige Frage, die den Fehler sichtbar machte.

Am Anfang des Kapitels korrigierte RFC 1207 sogar eine Verwechslung der Leitungsart: SLIP sei nicht für synchrone Leitungen entworfen, sondern für asynchrone; PPP könne beides. Für das Betriebsteam standen damit mehrere eigenständige Entscheidungen an. Welcher Leitungstyp ist vorhanden? Welcher Treiber bedient die Karte? Wo werden beschädigte Daten erkannt? Welche Anwendung muss am Ende funktionieren? Die Fragen gehören zusammen, aber eine Antwort ersetzt die andere nicht.

Ein Eingriff in den Kernel, keine neue Leitung

Die FAQ druckte ihren Vorschlag nicht als allgemeines „Prüfsummen einschalten“, sondern als konkrete Anweisung: adb -k -w /vmunix /dev/kmem udpcksum?w 1. Der Befehl benennt das Kernel-Abbild /vmunix, den Zugang zum Kernelspeicher /dev/kmem und die Variable udpcksum, der der Wert 1 geschrieben werden soll. Deshalb steht unmittelbar daneben der Rat, den alten Kernel aufzubewahren. Bei dieser Reparaturidee änderte sich weder die serielle Verkabelung noch der NFS-Server; der lokale Rechner sollte seine UDP-Datagramme anders behandeln.

Ein zweiter Mount nach diesem Eingriff steht im RFC nicht. Ein Paketmitschnitt und der vor und nach dem Eingriff ausgelesene Wert würden zeigen, ob der Vorschlag an den beschriebenen Rechnern wirkte. Die Herausgeber hatten die Frage aus Mailinglistenmaterial aufbereitet, Antworten teils gekürzt und Korrespondentennamen entfernt. Der Eintrag bewahrt also den Weg zur vermuteten Ursache und die genaue Stellschraube; das Ergebnis des Eingriffs blieb außerhalb der veröffentlichten Akte.

Quelle