18.5.2006

(Un)Kreatives Vernetzen

Posted in Chaos & Illusion at 11:15 by Rafayel

Ich wollte es nicht. Ich hatte mir fest vorgenommen, zumindest in diesem Punkt "herauszustechen". Aber der gestrige Tagesverlauf hat alle Vorsaetze ueber den Haufen geworfen. Worum es geht? Um Blogeintraege, in denen sich der Autor ueber irgendetwas oder -jemanden beschwert.

Ausgangssituation

Gegeben seien zwei Notebooks A und B. Beide sind mit Bluetooth-USB-Sticks ausgeruestet und per PAN-Profil (Personal Area Network) miteinander verbunden. Grund dieser zugegeben ungewoehnlichen Vernetzung ist, dass die Sticks Ueberbleibsel der frueheren ISDN-ueber-Bluetooth-Installation sind und somit die kostenguenstigste (wenn auch etwas langsame) Art der kabellosen Vernetzung beider Rechner darstellen.

Rechner A ist zusaetzlich mit einem UMTS-PCMCIA-Adapter ausgeruestet, der den Zugang zum Internet herstellt. Dank ICS (Internet Connection Sharing) ist diese Verbindung auch fuer Notebook B mit dem Umweg ueber das Bluetooth-Netzwerk nutzbar. Alles in allem Internet fuer alle Rechner ohne auf die Uhr schauen zu muessen und ohne stoerende Kabel.

Zielstellung

Ein auf Rechner B in einer VMware installiertes grml 0.6 soll

1. mehrere .tar.gz-Archive in der Groessenordnung von wenigen Kilobyte bis zu 800 Megabyte (Gesamtumfang knapp zwei Gigabyte) erhalten und
2. mittels Bridging am schon beschriebenen Bluetooth-Netzwerk teilnehmen, um ebenfalls Zugriff auf das Internet zu erhalten.

Beides eigentlich Routineaufgabe, die jedoch je nach Spassfaktor diverser Hersteller einige Stunden in Anspruch nehmen koennen.

Durchfuehrung

Ich bin faul. Ich geb's ehrlich zu. Deswegen wollte ich die zweite Aufgabe quasi nebenbei erledigen, indem ich zur Vernetzung von Host (WinXP) und Guest (grml in VMware) von Anfang an Bridging anstelle des eigentlich dafuer vorgesehenen Host-only-Netzwerkes von VMware verwende. Zur kurzen Erklaerung: Beim Bridging sieht es so aus, als ob der in der VMware simulierte Rechner gleichberechtigt und unabhaengig vom Host (ohne NAT etc.) mit einem vorgegebenen Netzwerk verbunden ist. Problem an der Geschichte ist, dass es logischerweise nur funktioniert, wenn ein solches Netzwerk zur Verfuegung steht.

Gut, an Notebook B stehen dafuer zwei Schnittstellen zur Auswahl: PAN per Bluetooth und die uebliche per RJ45-Stecker. Das passende TP(Twisted-Pair)-Kabel lag jedoch zwei Meter entfernt (faul. boese.), sodass ohne laengeres Ueberlegen die schon aktive Bluetooth-Schnittstelle das Rennen gewann. Also VMware-Bridging an die Bluetooth-Schnittstelle binden, grml booten, passende IP etc. in /etc/network/interfaces eingetragen und schon konnte das obligatorische ping-pong starten.

Zur eigentlichen Dateiuebertragung standen drei Protokolle zur freien Wahl: FTP (Server waere der XP-Host), SFTP und SCP (Server jeweils grml). Da es nicht unbedingt sicher sein musste, weil je eh alles ueber localhost lief, probierte ich es zunaechst mit FTP. Die ersten Dateien (alle wenige KB gross) liefen prima, doch dann kam das erste 300MB-Archiv und die interne Festplatte des Notebooks lief Sturm, obwohl sie mit der Uebertragung eigentlich nichts zu tun hatte. Wenige Minuten spaeter erklaerte mir Windows auch, warum. Der virtuelle freie Speicher sei vollstaendig ausgeschoepft und ich sollte doch bitte mit Unannehmlichkeiten rechnen. Bitte schnallen sie sich an, das Flugzeug durchquert eine Wetterzone, oder so.

Auch der Wechsel auf SFTP oder SCP brachte das gleiche Ergebnis. Ein Blick in den Taskmanager entlarvte den Uebeltaeter: panapp.exe. Bei sowas bin ich ja schmerzfrei, also Prozess killen, ohne auch nur auf die Warnung mehr als den Blick "Wo ist der OK-Button?" zu verschwenden. Resultat war die Meldung, dass meine Bluetooth-Verbindung zu Notebook A ausgefallen sei. Naja, damit konnte ich leben. Zumindest bis zu dem Zeitpunkt, als mir VMware erklaerte, das Bridging sei voruebergehend deaktiviert, da die verknuepfte Schnittstelle inaktiv sei. Der Prozess panapp.exe sorgt naemlich – wie sollte es auch anders sein – fuer das PAN zwischen den beiden Notebooks.

Einige weitere Experimente lieferten dann das unglaubliche Ergebnis. Dieser Prozess waechst im Speicher etwa linear (und der zugehoerige Faktor ist nicht weit von der Eins entfernt) mit der uebertragenen Datenmenge!

Nochmal in verstaendlich: wenn ich ein Gigabyte Daten ueber das PAN uebertragen moechte, so muss ich dafuer sorgen, dass die ein Gigabyte in den Arbeitsspeicher (+Auslagerungsdatei, aber das wird echt langsam) des Rechners passen. Analog fuer zwei, zehn etc. Okay, Bluetooth ist langsam, solche Datenmenge uebertraegt man normalerweise nicht vor dem naechsten Neustart, aber bei der Geschichte mit VMware lief das alles ohne Funk und somit sehr viel schneller ab. Und auch das alte Bluetooth wird mehr und mehr durch seinen schnellen Nachfolger ersetzt, sodass man der RAM-Befuellung quasi in Echtzeit zuschauen kann.

Fazit

Loesung des Problems war zum einem, doch noch das TP-Kabel zu holen und die Archive darueber laufen zu lassen, und der anschliessende Wechsel auf einen anderen Bluetooth-Stack, auch wenn ich dort bereits wieder mit Problemen konfrontiert wurde. Ich jedenfalls werde in Zukunft oefter als bisher einen Blick in den Taskmanager risikieren. Ey, du kommst ier nit rein! Fuer die Zukunft wuensche ich mir die kill-Befehle fuer Windows. Ja, ich kenne PsTools von Sysinternals, doch so maechtig wie ein killall -9 sind die leider noch lange nicht.

Permalink Trackback