Die Portnummern-Kopfnuss
Alles begann damit, dass Genosse Chefprogrammierer zu mir kam furchtbar schimpfend über unsere RPC-Library.
Als ich ihn fragte, was denn los sei, meinte er, dass bei einem unserer Kunden immer wieder die Portverbindung abreißt und der dortige Techniker von uns als Beweis, dass es nicht an unserer Software liegt, tcpdumps der Sessions wollte.
Faktisch kann es nicht an unserer SW liegen, weil wenn alle User gleichzeitig disconnectet werden, jedem User aber eine eigene Logon-Session mit eigener Socketverbindung zugeordnet ist, dann wäre das schon ein sehr merkwürdiger Zufall. Aber nachdem das Problem angeblich seit Versionseinspielung auftritt, sollten wir also den Beweis antreten.
Der Genosse hatte versucht, mithilfe von tethereal die Datenströme je nach Ports zu filtern. Da kam aber nix. Gar nix. Nicht mal wenn man eine Verbindugn machte auf den Port. Kein SYN-Paket, einfach nix.
Also habe ich gemeint, man könnte es ja mal mit tcpdump probieren. Selbes Resultat: Kein Mucks.
Das kam mir jetzt schon etwas spanisch vor.
Unsere Applikation startet über xinetd einen Hostextender (der rennt über stdio und wird über xinetd mittels tream eben durchgepiped). Der Hostextender läuft auf einem in /etc/services eingetragenen Port, der Port wird daher zu einem Namen aufgelöst.
Nun lag die Vermutung nahe, dass es sich viell. um ein xinetd-Problem handeln könnte (wenngleich tcpdump ja im promicious mode eigentlich alles mitkriegen sollte, was da so abläuft). Andere xinetd-Dienste belauscht, da funktionierte es problemlos.
Die nächste Strategie war, einmal mit iptrafnachzusehen, wo denn nun der Traffic läuft, wenn man etwas im Terminalemulator tut. Da sah man, dass die Verbindung auf Port 3464 lief.
Suchte man im netstat nach dem Port, so fand man keine Verbindung gelistet. Gespenstisch. Und immer wenn man auf Port 3464 verband, erhielt man auch die freundliche Login-Hilfe des Hostextenders.
Wir habe ndann mal verifiziert, ob auf anderen Rechner auch auf diesem Port der Hostextender läuft. War überall dort anzutreffen. Mit tcpdump auf 3464 konnte man auchdie Datenströme dumpen.
Nun war das Problem zwar eigenltihc gelöst, aber etwas mulmig war uns doch bei der Sache. woher kommt diese wundersame Portnummer, die wir noch nie gesehen haben. Laut /etc/services irgendein edm-mgr-sync. Merkwürdig.
Nach längerem Suchen und grübeln sah ich mir nochmals die Portnummer an: 69000.
Da fiel es mir wie Schuppen von den Augen, was neulich der neue Kollege aus der Technik bereits bei meiner Erklärung unseres Terminalemulator-Systems eingewandt hatte: Gibt’s net nur 65535 Ports?
Daran hatte bis jetzt niemand gedacht, weil wenn man das auf einen short castet kommt immer der richtige Wert raus. tcpdump und Konsorten haben aber scheinbar keine Bereichsüberprüfung und fressen alles 1:1, sie arbeiten ja im promicious mode und sich nicht gezwungen, das socket-Struct zu befüllen, welches als Datentyp short vorgibt.
# tcpdump port 9999999094835023480523749807529304870592374895273405273489057029345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
funktioniert also genauso. Autsch!
System programmer