# Firmware-Analyse — RY-LGSP38-28 v8.90.1931 Referenzdatei: `RY-LGSP38-28_v8.90.1931_CM_202607004.imgs` (23'120'318 Bytes). Diese Datei dient ausschliesslich als lokale technische Referenz. ## 1. Container-Format Die Datei beginnt mit dem ASCII-Header `Firmware&EZCM001`, gefolgt von einem proprietären TLV-artigen Eintrag (`login_logo.png`, ein rohes PNG). Es handelt sich um ein herstellerspezifisches Update-Container-Format („EZCM“), das mehrere Partitionsimages hintereinander bündelt (vermutlich Bootloader, Kernel, Root-Filesystem, ggf. weitere Blobs). Ein vollständiger Parser für dieses Containerformat wurde **nicht** geschrieben (out of scope, niedrige Priorität lt. Aufgabenstellung Abschnitt 28: "Original WebStaX- Kompatibilität" ist Priorität 4). Per Magic-Byte-Scan über die Rohdatei wurden folgende eingebettete Signaturen gefunden: | Signatur | Anzahl | Interpretation | |---|---|---| | `hsqs` (SquashFS little-endian) | 1 (Offset `0x3C0280` / 3'932'807) | Root-Filesystem | | `gzip` (`1f 8b`) | 11 | einzelne gzip-komprimierte Blöcke innerhalb SquashFS | | `xz` (`FD 37 7A 58 5A`) | 11 | xz-komprimierte SquashFS-Datenblöcke | | `zlib` (`78 DA` / `78 9C`) | 22 | zlib-Streams (u. a. PNG-IDAT, ggf. weitere Assets) | **Vorgehen:** Ab Offset `3'932'807` wurde der Rest der Datei (`19'187'511` Bytes) extrahiert und mit `unsquashfs` erfolgreich als SquashFS-Image gemountet/entpackt (2108 Einträge: 1595 Dateien, 75 Verzeichnisse, 438 Symlinks). Das ergibt ein vollständiges Linux-Root- Filesystem, wie in der Aufgabenstellung beschrieben (Buildroot, Cortex-A53). ## 2. Root-Filesystem — relevante Inhalte ``` /usr/bin/switch_app – Hauptanwendung (Microchip MEBA/MESA, WebStaX, SNMP-Subagent) /etc/mscc/service/switch_app.service – Startet switch_app /etc/hiawatha/hiawatha.conf – Webserver-Konfiguration (Port 80, CGI-Wrapper) /var/www/hiawatha/index.html – Platzhalter-Seite von Hiawatha selbst /var/www/webstax/*.htm (1181 Dateien) – Das komplette WebStaX-Web-UI /var/www/webstax/lib/*.js – ajax.js, config.js, dynforms.js, spom.js, MasterControl.js, mootools-core.js … /bin/*, /sbin/* – BusyBox-basierte Shell-Umgebung /usr/bin/dropbear* – SSH-Server/-Client ``` `switch_app` ist ein natives ARM64-ELF-Binary; sein internes Verhalten (MEBA/MESA-API-Aufrufe) wurde **nicht** disassembliert — für den Management-Plane-Simulator ist das nicht nötig, da wir keine ASIC-Dataplane nachbilden. Stattdessen wurde das **WebStaX-Frontend** (HTML/JS) analysiert, um die tatsächlichen AJAX-Endpunkte und deren Antwortformate zu extrahieren. ## 3. WebStaX-Backend-Protokoll (kein JSON!) Wichtiger Fund: WebStaX verwendet **kein JSON**, sondern ein kompaktes, zeilen-/trennzeichenbasiertes Text-Format (typisch für eingebettete Geräte mit wenig RAM). Aufrufe erfolgen über `lib/ajax.js` → `loadXMLDoc(url, callback, elementId)` per `XMLHttpRequest` (`GET`), Antwort ist `text/plain`. Format generell: `!` wobei `` bei Erfolg leer ist; `` ist meist mit `|` in Zeilen (z. B. pro Port) und mit `/` in Felder je Zeile unterteilt. Diese Formate wurden aus den entpackten `.htm`-Dateien direkt reverse- engineered (JavaScript-Parser-Funktionen `processUpdate()` in jeder Seite) und sind für unsere WebStaX-Compatibility-Layer (niedrigste Priorität, aber wo umgesetzt exakt nachgebaut) massgeblich: ### `GET /stat/poe_status` (aus `poe_status.htm`) ``` !||...| ``` Jeder Port-Eintrag (getrennt durch `/`): ``` portIndex/powerRequested/powerUsed/powerPriority/currentUsed/portStatus/pdClass/powerAllocated ``` - `powerRequested`, `powerUsed`, `powerAllocated` in **Zehntel-Watt** (JS teilt durch 10 für die Anzeige in W). - `powerPriority`: `0=Low, 1=High, 2=Critical`. - `portStatus`: Freitext-String, z. B. `"PoE not available - No PoE chip found"` (wird herausgefiltert) oder ein Statustext wie `Delivering Power`. - `currentUsed` in mA. Implementiert in `app/Api/WebstaxController.php::poeStatus()`. ### `GET /config/ports` (aus `ports.htm`) ``` |||...| ``` Jede Zeile: `/`-getrennte Feldliste, u. a. Index 1 = Port-Capability-Bitmask (`MEBA_PORT_CAP_*`, u. a. Bit für SFP-only/10G/25G zur Unterscheidung Kupfer/SFP), Index 7/13/24/27 (aus Zeile 0) = Grenzwerte für Port-Zählungen/-Typen zum Bau des Tabellenkopfs. Die ersten Zeilen enthalten switch-globale Metadaten, ab Zeile mit Port-Index die eigentlichen Port-Datensätze (Admin/Link/Speed/Duplex/Autoneg/FlowControl/Description). In unserer Implementierung liefern wir ein vereinfachtes, aber konsistentes Subset (Admin-Status, Link, Speed, Duplex, FlowControl, Beschreibung) im gleichen `/`- und `|`-Schema, ausreichend für Tools, die nur diese Felder auswerten; das vollständige `MEBA_PORT_CAP_*`-Bitfeld für alle 30+ TSN/QoS- Sonderfälle wird **nicht** nachgebildet (nicht im Simulationsumfang). ### `GET /stat/ddmi_detailed[?port=N]` (aus `ddmi_detailed.htm`) ``` | ``` `` = kommagetrennte Portliste für das Dropdown. `` = `/`-getrennte Werteliste in fester Reihenfolge (Temperatur, Spannung, Tx-Bias, Tx-Power, Rx-Power, jeweils inkl. der vier Schwellwerte), die 1:1 in eine feste `overview_head`-Zeilen-Tabelle gerendert wird. Implementiert in `WebstaxController::ddmiDetailed()` mit denselben fünf Messwerten + Schwellwerten aus `ddmi_values`. ### `GET /config/lldp_neighbors` (aus `lldp_neighbors.htm`) Analoges `|`/`,`-Format; pro Port ein Eintrag mit Chassis-ID, Port-ID, System-Name, System-Description, Management-IP, Capabilities, TTL. ### `GET /stat/sfpinfo?port=N` (aus `sfp_info.htm`) Liefert die SFP-Inventardaten (Vendor, Part-Number, Serial, Typ, Wellenlänge) für genau einen Port als einzelnen `/`-getrennten Datensatz. ### `GET /config/veriphy?port=N` (aus `veriphy.htm`) Cable-Diagnostics-Trigger/Abfrage für Port `N` (Start + Poll auf denselben Endpunkt, Status `running` → `completed` mit Ergebnis je Adernpaar). ## 4. Umsetzung im Simulator Priorität lt. Aufgabenstellung: 1. Simulator, 2. SNMP, 3. REST-API, 4. WebStaX-Kompatibilität. Die oben dokumentierten sechs Endpunkte (`stat/poe_status`, `config/ports`, `stat/ddmi_detailed`, `config/lldp_neighbors`, `stat/sfpinfo`, `config/veriphy`) sind in `app/Api/WebstaxController.php` als dünne Compatibility-Layer über `SimulatorStateService` umgesetzt — sie generieren das oben dokumentierte Text-Format aus denselben Daten, die auch REST-API und SNMP-Agent liefern. Die übrigen ~1175 WebStaX-Seiten (VLAN, STP, QoS, TSN/PSFP, RADIUS, …) werden **nicht** nachgebaut; unsere eigene Management-UI deckt den Simulator-Funktionsumfang ab (Vorgabe Abschnitt 28: „Baue nichts unnötig nach, wenn unsere eigene Management-Oberfläche ausreichend ist“). ## 5. Nicht analysiert / bewusst ausgeklammert - `switch_app`-Binary-Disassemblierung (nicht nötig für Management-Plane-Sim). - Vollständiges Parsing des `EZCM001`-Containerformats (Bootloader/Kernel- Partitionen) — nicht relevant, da wir keine Firmware flashen/booten. - Die übrigen WebStaX-Backend-Endpunkte ausserhalb der oben genannten sechs (z. B. VLAN/STP/QoS/RADIUS/TSN) — explizit **nicht implementiert**.