Gescheitertes Experiment

Heute ist mein nun seit 2 1/2 Jahren anhaltendes Experiment mit dem Verzicht auf einen privaten Festnetz-Internetanschluss offiziell gescheitert. Der Grund ist ganz einfach: die anhaltenden Pandemiemaßnahmen aufgrund des Corona-Virus. Die Auflagen für Versammlungen in (geschlossenen) Räumen für die Öffentlichkeit machen es sehr schwierig, deren Internetzugänge adäquat für mich nutzen zu können. Sei es in der öffentlichen Stadtbibliothek oder den Räumlichkeiten des angehörigen Vereins.
Nachdem ich im Herbst 2015 meinen damaligen alten Unitymedia-Kabelanschluss gekündigt habe, entschied ich mich wieder für diese Art des Breitbandinternetanschlusses. Bei dem Alten habe ich seinerseits für die 100 MBit Download und 5 MBit Upload 44 Euro monatlich bezahlt, nun aber habe ich mich für das kleinste Paket für den inzwischen durch Vodafone übernommenen Service entschieden, bei 50 MBit im Download und wieder die 5 MBit Upload für 20 Euro monatlich während der gesamten 24 Monate Vertragsmindestlaufzeit. Hinzu kommen aber noch die 68,22 Euro Bereitstellungsgebühr und wieder Stromkosten für das Netzwerkendgerät.
Richtig begeistert bin ich darüber, dass ich am Montagabend – also erst vorgestern – online die Bestellung getätigt habe, aber bereits heute seit dem frühen Abend das Paket mit dem für mich bereitgestellten Netzwerkendgerät und den Zugangsdaten in meiner nächsten zu Fuß erreichbaren DHL-Packstation deponiert wurden und ich jetzt diese Zeilen über den Festnetzanschluss veröffentlichen kann.

Inzwischen zeichnet es sich ja leider ab, dass eine zweite Corona-Infektionswelle auf uns zu rollen wird. Ich möchte aber dennoch kein weiteres (Halb-) Jahr verstreichen lassen und meine Hobby-IT-Projekte deswegen ruhen zu lassen bis ich vielleicht irgendwann mal wieder die Möglichkeit habe größere ISO-Dateien herunterladen zu können, oder Angst haben zu müssen, dass die Verbindungskosten für meinen Mobil-Vertrag deswegen explodieren.

Netzwerk-Bridge unter Linux mit TUN/TAP

Seit längerem trage ich bereits das Projekt in meinem Kopf herum, einen Mainframe-Computer der VAX-Reihe von Digital Equipment Corporation (kurz DEC) zu emulieren und auf diesem emulierten System wiederum das auch von DEC dazu entwickelte ‚Virtual Memory System‘ (kurz VMS später OpenVMS) als Betriebssystem zu installieren um damit ein wenig herum zu spielen. Ich habe aber bereits NetBSD, das ebenfalls von DEC entwickelte und proprietäre Unix Ultrix, als auch OpenVMS auf die emulierte Maschine kurz installiert. Nur waren diese Unternhmungen eher halbherzig, denn eine wichtige Komponente hatte ich bisher nie mit einbezogen. Nämlich die Netzwerkfähigkeit eines dieser Systeme. Ohne Netzwerk ist so eine emulierte Maschine zwar schön zum anschauen und herum probieren, aber sie verharrt weiterhin als eine Art Insellösung, wie früher, als die Computer in den häuslichen Wohnstuben noch nicht mit einem (Drahtlos-) Netzwerk verbunden waren und selbst das Internet mittels eines Modemzugangs noch teuer und keine Selbstveständlichkeit waren. Erst die Kommunikation von Computern untereinander macht sie flexibel und nochmals interessanter. Mit einer Netzwerkanbindung lassen sich Betriebssystem und Programme updaten oder gar upgraden, Dateien und Nachrichten hin und her übertragen und eigene Dienste anbieten.

Die Möglichkeit der Netzwerkkonnektivität ist aus meiner Sicht zumindest bei der Desktop-Virtualisierung eine recht einfache Sache. Denn die VMWare’s, Parallels und VirtualBox’es dieser Welt richten während ihrer Installation eine Netzwerkbridge in Software für das Wirtssystems automatisch mit ein, da sie die nötigen Treiber bereits mitbringen. So kann für eine virtuelle Maschine der Bridge-Modus zum direkten Zugriff auf ein physikalisches Netz, ein geteiltes Subnet mit NAT für mehrere virtuelle Maschinen untereinander oder eine Peer-To-Peer Verbindung zum Wirtssystem angeboten werden.

Bei der Emulationssoftware simh ist das etwas anders. Das Programm bringt keinen eigenen Treiber für eine Netzwerkbridge mit. Das Programm selber ist zwar netzwerkfähig, aber es ist nötig einen virtuellen Netzwerk-Kernel-Treiber wie TUN/TAP zu installieren, um die Netzwerkgeräte zu simulieren.

TUN simuliert dabei ein Ende-zu-Ende-Netzwerkgerät (ISO OSI-Schicht 3) und kommuniziert mit IP-Paketen mit der Software, während TAP eine Punkt-zu-Punkt-Verbindung mittels Ethernet-Gerät simuliert (ISO OSI-Schicht 2) und über Ethernet-Frames mit der Software kommuniziert.

In meinem DokuWiki habe ich einen ersten Workaround zur Erstellung einer Netzwerk-Bridge unter Linux mit TUN/TAP erstellt.:
Netzwerk-Bridge mit TUN/TAP für eine Computer-Emulation

Links:
TUN/TAP (engl. Wikipedia)
TUN/TAP (Projektseite auf source forge)
SIMH (dt. Wikipedia)
DEC VAX (engl. Wikipedia)
DEC OpenVMS (engl. Wikipedia)
Ultrix (engl. Wikipedia)
NetBSD (dt. Wikipedia)

Individuelles ISO-Image unter macOS erstellen

Im Zuge meines Vorhabens dass ich mir nach langer Zeit wieder ein MS-DOS virtualisiert habe, stand ich auch wieder vor dem Problem ein individuelles ISO-CD-Image mit Computerdateien unter macOS zu erstellen. Im graphischen Programm ‚Disk Utility‘ (dt.: Festplattendienstprogramm) ist dies leider nicht direkt möglich. Allerdings muss im ‚Disk Utility‘ über das Menü ‚File‚ -> ‚New Image‚ -> ‚Blank Image …‚ ein leeres Image erstellt werden. Dabei ist darauf zu achten, dass im Dialogfenster unter ‚Partitions‘ ‚CD/DVD‘ und bei ‚Image Format‘ ‚DVD/CD-Master‘ als Optionen ausgewählt sind.

Somit ist erst einmal ein Image mit der Dateierweiterung .cdr erstellt, das mit Dateien gefüllt werden kann. Um daraus nun ein CD-ROM-konformes ISO-Image zu erstellen, ist das Kommandozeilenprogramm hdiutil nötig.

Der Befehl lautet:

hdiutil makehybrid -iso -o CD-ROM.ISO CD-ROM.cdr

Bei der Benennung der Output-Datei ist es aber nicht nötig .ISO als Dateierweiterung an zu hängen, da hdiutil dies automatisch tut.

Links:
Einrichten eines virtualisierten MS-DOS Systems (eigener Blogartikel)
ISO 9660 (dt. Wikipedia)

Einrichten eines virtualisierten MS-DOS Systems

Erst einmal eine Sache vorweg: Auch wenn ich bei der Lösungserstellung VMWare Fusion für Mac als Desktop-Virtualisierung verwendet habe, wird diese aber auch mit VMWare Desktop für Linux oder Windows, den Virtualisierungslösungen Parallels Desktop oder Oracle VirtualBox, und sogar mit diversen x86-Emulatoren funktionieren.

Der Hintergrund warum ich diesen Artikel erstellt habe ist, dass ich mich vor einigen Tagen in ein Gespräch mit zwei mir mehr und weniger bekannten Personen dazu gesellt habe, wo es um eine Software zur Erstellung von Partituren im MIDI-Format ging. Ich berichtete, dass ich im Alter von 15 bis 17 Jahre selber eine Windows-Software besaß, mit der es möglich war in Form einer Partitur MIDI-Songs zu erstellen, um die musikalischen Partner für das Üben zu ersetzen. Die Software die ich damals einsetzte – und auch heute auf Diskette noch habe, heißt „MIDI Recording Session“. Auch wenn es sich bei dieser um ein 16-bittige Windows 3.x Anwendung handelt, so konnte ich sie dennoch ohne Probleme in einer bestehenden virtuellen Maschine mit Windows XP starten und benutzen. Allerdings kam mir bereits bei dem ersten Gedanken das Programm nach so langer Zeit mal wieder zu Starten auch die Idee, nach recht langer Zeit ein MS-DOS mit Windows 3.11 mal wieder zu virtualisieren.
So habe ich meine Disketten-Images aus dem Schrank geholt und das Microsoft DOS 6.2 in eine virtuelle Maschine installiert. Um das Windows for Workgroups in der Version 3.11, sowie das Microsoft Works für Windows Version 2 von CD-ROM in die DOS-VM installieren zu können, bedarf es allerdings auch noch einen Treiber um überhaupt auf das optische Laufwerk zugreifen zu können.

Bei meiner Recherche nach einem adäquaten DOS-Treiber für das virtualisierte MS-DOS bin ich auf das Technology Blog von Werner Ziegelwanger gestoßen. Dieser hatte es sich zu seinem Hobby gemacht einen DOS-PC zusammen zu bauen und ist bereits auf das selbe Problem gestoßen wie ich, nur mit der zusätzlichen Schwierigkeit im Gegensatz zu mir, dass er eben kein virtualisiertes System verwendet, wo sich die (Pseudo-) Hardware immer gleich verhält, sondern dass er mit den Herstellereigenen Besonderheiten der Laufwerke zu kämpfen hatte, die immer für Fummelarbeiten bei den Treibern unter einem nativ ausgeführten DOS sorgten.
Ziegelwanger hat die Arbeitsschritte sehr schön dokumentiert, so dass es mir ohne Probleme möglich war das optische Laufwerk aus der virtualisierten DOS-Umgebung ansprechen zu können. Ich habe sie als Anleitung nochmals in mein Wiki übernommen.

Links:
Anleitung im eigenen Dokuwiki
Technology Blog – DOS CD Rom Treiber installieren

Darüber hinaus stand ich vor dem Problem, Dateien, wie zum Beispiel eben die Treiber für den Zugriff auf das CD-Laufwerk, von meinem Host-System (macOS) in die virtuelle Maschine zu übertragen. Der Trick ist für das erste aber recht einfach.:

  1. Über das Terminal unter macOS (Linux, BSD) ein leeres Disketten-Image mit dem Konsolenprogramm dd erstellen.
    dd if=/dev/zero bs=512 count=2880 of=msdos-floppy.img
  2. Das erstellte Disketten-Image mit dem Virtualisierungsprogramm als Diskettenlaufwerk verbinden und mit dem Befehl format a: mit dem Dateisystem FAT12 unter DOS formatieren.
  3. Image von der VM wieder lösen und im Dateimanager (macOS Finder oder dem jedes anderen Host-Systems) wieder mounten und dann die Dateien hineinkopieren.
  4. Zuletzt das Image wieder aus dem Dateimanager auswerfen und mit der virtuellen Maschine verbinden. Die Dateien können gelesen beziehungsweise wenn nötig verändert werden.

Auf Dauer ist dies aber natürlich keine Lösung und ziemlich umständlich sowie nervend.

Teletext auf dem Raspberry Pi generieren

Im Herbst 2018 veröffentlichte der Heise-Verlag zum ersten Mal das Sonderheft c’t-Retro. Neben den Themen zu alten Computern wie den ZX Spectum oder Commodore C64 sowie anderen Technik-Bereichen der IT aus der Sicht längst vergangener Tage, hatten die Redakteure ein Raspberry Pi Projekt vorgestellt, mit dem es möglich ist, selber den Fernseh-Teletxt zu erstellen und auszugeben.

Teletext, hier in Deutschland eher unter dem Begriff Videotext bekannt, ist ja das textuelle Zusatzangebot der Fernsehsender für die eigenen Programminformationen, sowie aktuelle Sportergebnisse und Nachrichten. Übertragen wird der Teletext mit dem PAL-Normsignal in der Austastlücke.

Zum Nachbau des Projektes braucht es nicht viel an Hardware. Glücklicherweise habe ich noch einen Raspberry Pi der ersten Generation mit einer Buchse für den Composite Video Cinchstecker. – Die neueren Generationen haben statt der Chinchbuchse nur einen GPIO-Pin für die analoge Videoausgabe. Mein elektronischer Aufbau ist daher recht übersichtlich.:

Am Composite-Ausgang des Raspberry Pi’s geht ein Chinchkabel auf den Adapter für S-Video und Composite meines Elgato TV-Hybrid DVB-T USB-Sticks. Der DVB-T Stick ist also der „Fernseher“, der mit seiner Fernseh-Software EyeTV das PAL-Signal wieder als Bild ausgibt.
Der Raspberry Pi selber besitzt in seiner jetzigen finalen Aufbaustufe eine SD-Karte mit einem Respbian-Linux für die Teletext-Software und einen kleinen USB-WiFi-Dongel, um sich auf ihn über W-LAN zu administrativen Zwecken mittels SSH verbinden zu können.

Ist der Raspberry Pi so konfiguriert, dass die Bildschirmausgabe über das PAL-Signal an den „Fernseher“ geht und eine USB-Tastatur direkt am Raspberry Pi angeschlossen ist, dann fällt direkt die enorme Latenz auf, die durch den analogen Umweg entsteht. Ist der Raspberry Pi über seinen HDMI-Ausgang an einem gewöhnlichen Computerbildschirm angebunden, besteht die enorme Latenz nicht.
Wird dann der Teletext-Dienst VBit2 gestartet, so ist über die Teletext-Taste des „Empfangsgerätes“ der Videotext, der aus den vorinstallierten Tafeln besteht, zu sehen und es lässt sich wie bei den klassischen Fernsehsendern durch ihn hindurch navigieren.
Es gibt aber bereits eine Teletext-Tafel, in der die Temperatur des ARM-Chips und die lokale IP-Adresse des Rasperry Pi’s ausgelesen und angezeigt werden.
Die c’t-Redaktion hatte sich dann entsprechende Tafeln erstellt, mit denen die Meldungen und Nachrichten aus dem Heise-Newsticker als Teletxt abgerufen werden können.

In meinem Wiki habe ich eine entsprechende Installationsanleitung erstellt, wie die Software VBit2 auf dem Raspbian zu installieren ist.
Link: https://sommteck.net/wiki/doku.php?id=linux:vbit2_teletext-generator

Sobald ich meine ersten eigenen Gehversuche bei dem Erzeugen eigener Teletext-Tafeln erfolgreich durchschritten habe, werde ich dazu ein Update schreiben.

Update 05. April 16:05 Uhr:

Von der genannten Teletext-Tafel, in der die Temperatur des ARM-Chips und die lokale IP-Adresse des Rasperry Pi’s ausgelesen und angezeigt werden kann, gibt es natürlich auch ein Foto. Ich habe alle Bilder in einer eigenem Album.:
Link Fotoalbum VBit2

Links:
Heise c’t-Artikel: Teletext auf dem Raspberry Pi generieren
Links Teletext auf dem Raspberry Pi generieren
Projekt Heise Raspi Newstext (Github)
Teletext Page Editor im Browser
Teletext (dt. Wikipedia)
Raspberry Pi (dt. Wikipedia)
Composite Video (dt. Wikipedia)
Geniatech EyeTV (ehemals Elgato)