Kurzfassung
Kann ein Cisco CP-9951 DOOM ausführen?
Ja. Nativ, lokal, persistent und offline.
Der finale v.666-Build läuft auf der ARM-CPU des Telefons, rendert direkt auf /dev/fb1, liest die echten Cisco-Tasten über /dev/input/keypad0, erzeugt hörbaren Sound über den lokalen Medienpfad, überlebt Neustarts und startet über Applications → Doom.
Der tatsächliche Ablauf
Das Projekt ergibt eigentlich nur als Geschichte Sinn, weil sich die Antwort auf „läuft DOOM jetzt wirklich auf dem Cisco?“ mehrfach geändert hat. In den ersten drei Stufen hing das Telefon noch an Arbeit, die Cthulhu erledigte. Der entscheidende Bruch kam mit der lokalen Shell; erst danach wanderte die Laufzeit wirklich auf das Telefon.
Prolog: ein 35-€-Bürotelefon kommt an; der Kater wird Hintergrundbild.
1 · Werner: beweisen, dass das unveränderte Telefon H.264-Video und PCMU-Audio sinnvoll empfangen kann.
2 · Gestreamtes DOOM: Cthulhu führt das Spiel aus; das Cisco empfängt es auf Nebenstelle 666.
3 · Cisco als Controller: echte Tasten → DTMF → Asterisk AMI → uinput → entferntes DOOM.
4 · Shell: Ciscos Diagnose-SSH-Pfad bringt uns direkt in MontaVista Linux auf dem Telefon.
5 · Raven-Hardware: Framebuffer untersuchen und /dev/input/keypad0 vermessen.
6 · Natives DOOM: Ausführung, Rendering und Eingabe direkt auf dem Cisco.
7 · Lokaler Sound: der Medienpfad des Telefons liefert den Spielsound.
8 · Persistenz: Installation im Flash und Start über Applications → Doom.
Finale: Ethernet abziehen, kalt starten, DOOM öffnen und vollständig offline spielen.
Prolog — ein 35-€-Bürotelefon kommt an
Das Experiment begann mit einem gebrauchten Cisco Unified IP Phone CP-9951. Der ursprüngliche Plan war tatsächlich nur Reconnaissance: Provisionierung, SIP, Video, lokale Hardware und die Schnittstellen verstehen, die Cisco auf dem Gerät übriggelassen hatte.
Das Telefon blieb auf seiner normalen Cisco-Firmware sip9951.9-2-1. Cthulhu lieferte DHCP/TFTP-Provisioning, Asterisk übernahm SIP. Eine technische Anforderung stand allerdings sofort fest und wurde nie wieder diskutiert: Der Kater bleibt als Hintergrund.
Von nativem DOOM war da noch keine Rede. Es war einfach ein sehr billiges Enterprise-Telefon, in dem offensichtlich deutlich mehr Computer steckte, als ein Telefon vernünftigerweise bräuchte.
1 — Werner auf 111
Die erste absichtlich unnötige Anwendung war Werner. Bevor DOOM überhaupt auf den Tisch kam, wollten wir sauber beweisen, dass das unveränderte CP-9951 mit seiner Stock-Firmware als echter H.264/PCMU-Endpunkt taugt.
Über die Provisionierung wurde der H.264-Empfang des Telefons nutzbar gemacht, Asterisk routete Nebenstelle 111, und Baresip lieferte 640×480-H.264-Video plus PCMU-Audio. 111 anrufen — Werner erscheint auf dem Bürotelefon. Vollkommen sachgerechte Nutzung von Enterprise-Telefonie.
Cthulhu ↓ H.264 + PCMU Asterisk / Baresip ↓ Nebenstelle 111 Cisco CP-9951 ↓ Werner
Werner ist hier Kult. Die Comics und Filme gehören in Deutschland für sehr viele Leute einfach zum kulturellen Inventar. Falls man Werner nicht kennt: Die Figur stammt von Rötger Feldmann („Brösel“); die Eisrennen-Szene hier ist aus Werner – Das muß kesseln!!! (1996).
Nobelschröder hat sein Auto auf dem zugefrorenen See geparkt. Er steigt aus und merkt sofort, wie glatt es ist: „Huch, ist das glatt.“ Werner: „Sag mal, kannst du nicht mal vernünftig grüßen?“ Andi: „Mach mal einen vernünftigen Diener.“
Nobelschröder versucht es, rutscht weg, macht ungefähr einen halben Salto und landet auf dem Kopf. Werner kommentiert trocken: „Der macht das ganze Eis kaputt mit seiner Abrissbirne.“ Genau das läuft da auf Nebenstelle 111. :D
Das war wichtig: Bildschirm und Lautsprecher des unveränderten Telefons waren damit als brauchbarer Medienendpunkt bewiesen. Die nächste Frage war im Nachhinein natürlich unvermeidbar: Wenn Werner funktioniert — was passiert dann auf Nebenstelle 666?
2 — Live-DOOM auf 666: noch auf Cthulhu
Der erste DOOM-Erfolg war noch nicht nativ. DOOM lief weiterhin auf Cthulhu unter Wayland/Sway; das Cisco bekam das laufende Spiel als Videoanruf.
DOOM / Sway auf Cthulhu ↓ wf-recorder ↓ v4l2loopback (/dev/video42) ↓ Baresip / H.264 RTP ↓ Asterisk ↓ Nebenstelle 666 Cisco CP-9951
Der erste Medienpfad funktionierte technisch, puffert aber mehrere Sekunden. Zum Anschauen eines Clips okay, für DOOM kompletter Quatsch. Der Wechsel auf v4l2loopback beseitigte diese Verzögerung und brachte die Anzeige auf dem Telefon nahe genug an Echtzeit, dass der Unsinn plötzlich praktisch benutzbar wurde.
Das Cisco zeigte DOOM an und spielte den Call-Ton ab — der eigentliche Spielprozess lief aber noch auf Cthulhu.
3 — Aufnahme 03: Das Cisco steuert DOOM wirklich
DOOM auf dem Telefon anzuzeigen war lustig. DOOM mit dem Telefon zu spielen war besser. Das letzte fehlende Stück der gestreamten Phase war deshalb die Eingabe.
Die echten Zahlentasten sendeten während des Anrufs RFC4733-DTMF. Asterisk stellte die Ereignisse über eine nur lokal erreichbare AMI-Verbindung bereit, und eine kleine Python-Bridge erzeugte daraus über /dev/uinput echte Linux-Tastaturereignisse.
Cisco-Tastatur ↓ RFC4733 DTMF ↓ Asterisk ↓ AMI-DTMF-Ereignisse ↓ lokale Python-Bridge ↓ Linux /dev/uinput ↓ DOOM Retro auf Cthulhu
2 = vorwärts 8 = rückwärts 4 = links drehen 6 = rechts drehen 5 = feuern 0 = benutzen / öffnen
Der vorhandene Video- und Audiopfad blieb unverändert; AMI blieb lokal auf Cthulhu gebunden.
Das Cisco war jetzt gleichzeitig Anzeige und Controller. DOOM lief aber immer noch nicht auf dem Telefon. Eigentlich wäre das schon albern genug gewesen, um aufzuhören. Haben wir natürlich nicht.
4 — Der Wendepunkt: rein in die echte Linux-Shell
Hier hörte das Projekt auf, nur ein cleverer SIP-Trick zu sein. Cisco hatte für diese 89xx/99xx-Generation einen Diagnosezugang über SSH vorgesehen. Also nutzten wir die bereits funktionierende Provisionierung, statt Firmware oder Bootloader anzufassen.
Cthulhu ↓ dnsmasq / TFTP ↓ SEPC40ACB4D05D0.cnf.xml ↓ Cisco CP-9951
Die funktionierende SEP-Konfiguration wurde zuerst gesichert. Danach kamen die SSH-Zugangsdaten über die Provisionierung hinein und TCP-Port 22 war erreichbar. Der SSH-Server des Telefons ist alt genug, dass ein zeitgenössischer Client die praktische Lösung war:
/tmp/putty-0.60/unix/plink -ssh nebu@10.1.1.2
Die erste SSH-Anmeldung war nur der äußere Diagnose-Login. Danach erschien ein zweiter Login für das eingebettete System. Auf der getesteten Firmware sip9951.9-2-1 lautete der interne Shell-Login default / cisco.
Im Kopf war Google schon offen: irgendein vergessenes Service-Manual von 2011, ein toter Forenlink und am Ende bestimmt ein Factory-Passwort wie C1sc0!raven#diag$ oder 2434!!$$5/b.
„Mhhh. Passwort … ich mach mir besser erstmal einen Ostfriesentee.“
...ach was soll's. cisco?
Enter.
Erster Versuch.
Das Telefon sinngemäß: „Ja moin. Welcome to MontaVista(R) Linux(R) Professional Edition Blackfoot.“
Alles klar. Let's go. :D
Welcome to MontaVista Linux Professional Edition Blackfoot Linux 2.6.18_pro500 ARMv6 / ARMv6TEJ Hardware: raven roughly 244 MB RAM Cisco Enhanced BusyBox 1.9.1 uid=65533(default) gid=100(users)
Die Frage änderte sich sofort von „wie weit können wir das Telefon als DOOM-Terminal missbrauchen?“ zu „wenn das Ding Linux auf ARM ist — können wir DOOM dann nicht einfach direkt darauf laufen lassen?“
Was steckt eigentlich in dem Ding?
Die Shell war kein Root-Zugang, zeigte aber einen erstaunlich normalen kleinen Embedded-Linux-Rechner: ARMv6, MontaVista mit einem 2.6.18er Kernel, BusyBox, ungefähr 244 MB RAM und Hardware mit dem Namen raven.
Vor allem waren die Schnittstellen, die wir brauchten, einfach da:
/dev/fb0 /dev/fb1 /dev/fb2 /dev/fb3 /dev/input/keypad0 /dev/input/touchscreen0 /dev/input/hookswitch0
Damit sah das Projekt plötzlich völlig anders aus. Keine Custom-Firmware nötig. Wir hatten einen Framebuffer, echte Eingabegeräte und genug Userspace, um das Telefon endlich als das zu behandeln, was es die ganze Zeit gewesen war: ein kleiner ARM-Linux-Rechner mit Hörer.
5 — Raven-Keypad und der lokale Hardwarepfad
Das echte Tastenfeld wurde direkt am Gerät vermessen. Kernel-Symbole und Geräteverhalten zeigten den Pfad aus Raven-Keypad und Ciscos keyhandle-Schicht:
physische Taste ↓ Raven-Keypad-Hardwaretreiber ↓ Cisco-keyhandle-Schicht ↓ /dev/input/keypad0 ↓ lokale Userspace-Anwendung
Das Gerät liefert 16 Byte große Linux-artige Input-Records. Navigationskreuz, Ziffernblock, Softkeys, Leitungstasten, Lautstärketasten und Funktionstasten wurden am echten Telefon vermessen.
/dev/fb1 wurde das lokale DOOM-Ziel für die Bildausgabe.
Damit war die DTMF-Steuerung Geschichte: Das native Spiel konnte die echten Cisco-Tasten direkt lesen — ganz ohne SIP-Tastenweiterleitung oder Controller-Bridge auf dem Desktop.
6 — Natives DOOM
DOOM wurde anschließend für die ARM-Umgebung des CP-9951 gebaut. Im finalen lokalen Laufzeitpfad gibt es kein Rendering auf Cthulhu, keinen H.264-Spielstream und keine DTMF-Steuerbrücke mehr:
DOOM-Engine → läuft auf der Cisco-ARM-CPU → rendert direkt auf /dev/fb1 → liest /dev/input/keypad0 → nutzt die echten Cisco-Tasten → kehrt beim Beenden sauber zur Cisco-Oberfläche zurück
Das Navigationskreuz steuert Bewegung und Menüs, OK bestätigt, * feuert, # benutzt/öffnet, und die rote Hörertaste beendet DOOM sauber.
Ab hier laufen Spielschleife, Framebuffer-Ausgabe und Tastenabfrage wirklich lokal auf dem CP-9951.
7 — Lokaler Sound: das letzte große Laufzeitproblem
Bild und Eingabe waren lokal; Sound war das letzte große Laufzeitproblem. Der fertige Build sendet kompakte Soundereignisse an einen kleinen lokalen Relay-/Servicepfad, der 8-kHz-G.711-μ-law-RTP für das vorhandene Cisco-Mediensystem erzeugt.
Der entscheidende physische Fix für den Betrieb ohne Netzwerkkabel war, die RTP-Quelle an 127.0.0.1 zu binden. Mit Ethernet kann die konfigurierte Telefonadresse Ziel sein; ohne Ethernet fällt der Dienst auf Loopback zurück, statt an einer fehlenden Route zu sterben. Hörbarer DOOM-Sound wurde am echten Telefon bestätigt.
8 — Persistenz: Applications → Doom
Ein natives Binary ist nett. Ein Telefon, das nach jedem Neustart erst wieder einen Rechner und einen Shell-Befehl braucht, ist aber noch nicht fertig.
Die finale Installation liegt persistent unter:
/mnt/flash2/doom-v666
Das normale Cisco-Applications-Menü startet den lokalen Endpunkt:
http://127.0.0.1:8095/launch
Ein isolierter persistenter xinetd-Dienst nutzt Ciscos vorhandenen Bootpfad. Spiel, Freedoom-IWAD und Hilfsprogramme überleben Neustarts; Installer und Rollback gehören zum Paket. Für den normalen Betrieb ist kein manueller Shell-Befehl mehr nötig.
Finaler physischer Beweis — 15. September 2026
Der Abnahmetest nahm die letzte Unklarheit weg. Ethernet wurde physisch abgezogen. Das Telefon wurde komplett stromlos gemacht und kalt gestartet. Kein Cthulhu-Dienst war verfügbar. Kein Shell-Dienst wurde manuell gestartet.
Nach dem Boot: Applications → Doom.
Ethernet abziehen Strom trennen Kaltstart nur mit Strom Applications öffnen Doom auswählen mit den echten Cisco-Tasten spielen lokalen Sound hören mit der roten Hörertaste sauber beenden
Der Player wird erst nach einem Klick geladen. Direktlink: Cisco CP-9951 runs DOOM natively — v.666 offline cold boot proof.
Das Cisco CP-9951 führt DOOM nativ, lokal, persistent und offline aus.
v.666 — Release und Quellcode
Cisco CP-9951 DOOM v.666
Das öffentliche Paket heißt Cisco9951-doom.doompkg und verwendet Freedoom Phase 2. Es enthält weder Cisco-Firmware noch proprietäre Cisco-Bibliotheken oder kommerzielle DOOM-IWADs.
SHA-256 2f0c29fa6213bf0cdb0a5cb9124d083c1ccff54ce4009730917c371d784d4dbd Cisco9951-doom.doompkg