netdiagPdfGeraeteDiff() gibt die Listen getrennt aus: neu, nicht mehr
erreichbar, mit neuer IP-Adresse, gleiche Adresse mit anderen offenen Ports.
Beim Wiederholungstermin zaehlt, WELCHES Geraet neu ist, nicht nur wie viele.
An jeder Zeile steht, worueber das Geraet wiedererkannt wurde - "erkannt ueber
IP und Portmuster" ist eine schwaechere Aussage als "ueber Netzwerkname", und
der Unterschied gehoert ins Dokument statt in eine Fussnote.
Geprueft im Durchstich: in der App gegen echte Serverdaten gemessen
(ND2026-0016 gegen ND2026-0006), synchronisiert, PDF erzeugt und angesehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
netdiagPdfDns(): je befragtem Server eine eigene Zeile statt einer
|-getrennten Kette. Bei zwei Servern ging die generische Darstellung noch,
bei den vier bis fuenf Eintraegen eines Firmennetzes waere die eigentliche
Aussage - welcher Server antwortet und welcher nicht - nicht mehr auffindbar
gewesen. Damit hat jedes Werkzeug mit Listenergebnis einen eigenen Renderer.
Geprueft im vollstaendigen Durchstich: in der App gemessen (Emulator gegen die
lokale Testinstanz), synchronisiert, PDF aus ND2026-0016 erzeugt und angesehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gefragteServer und antworten in die Kunden-Whitelist, dnscheck in die
Werkzeugliste. Ohne diese drei Zeilen stuende im Kundendokument nur die
Ampel - die einzelnen Serverzeilen sind das eigentliche Ergebnis.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"0 DHCP-Server (!)" in Rot: In der Produktionsdatenbank stehen drei
ausgelieferte Messungen des entfernten Werkzeugs dhcpcheck mit Ergebnis
{"count":0,"server":[],"hinweis":""} und Status 2. Bei Kabelverbindung gibt
Android die DHCP-Angaben aber grundsaetzlich nicht heraus (nur DhcpInfo, nur
WLAN, deprecated) - gemessen wurde also nichts, "0 gefunden" war der
Rueckgabewert fuer "nicht ermittelbar". netdiagAltlastKorrektur() zeigt diese
Messungen jetzt als "nicht messbar" mit Erklaerung, in PDF und
Technikeransicht. Rohdaten bleiben unangetastet, korrigiert wird nur die
Darstellung - und die wird bei jedem Abruf neu erzeugt. Die Ergebniszahlen
werden dabei unterdrueckt: "Gefundene Geraete: 0" widerspraeche der Aussage
direkt darueber.
"Lease-Dauer: 864000 s s": aeltere App-Fassungen haben die Einheit in den Wert
geschrieben, die Feldtabelle haengt sie erneut an (Prod-Messung #42).
Adress- und Lease-Felder mit dem Wert 0 erscheinen jetzt als "nicht
ermittelbar" statt als "0" - das war nie eine Messung, sondern das
"nichts ermittelt" der alten Android-API.
Neu in der Whitelist: dhcpQuelle (system = LinkProperties ab Android 11 fuer
jeden Anschlusstyp, wlan = alter Weg nur fuer WLAN). Damit ist klaerbar, ob
eine fehlende DHCP-Angabe an der Leitung lag oder an der Android-Version.
Geprueft gegen die lokale Testinstanz mit einer Kopie der echten
Prod-Messungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
netdiagPdfKette() fuer das neue App-Werkzeug: Fehlerglied als eigene
hervorgehobene Zeile, darunter die vier Stufen einzeln, dann Systemurteil
und Hinweis. Ohne eigenen Zweig stuenden die Stufen als |-Kette in einer
Zelle und das Fehlerglied - die eigentliche Aussage - mittendrin.
Dabei ein Fehler gefunden, der jedes Protokoll betrifft: pdf_getPDFFont()
liefert Helvetica, einen Core-Font mit WinAnsi-Kodierung. Alles ausserhalb
dieses Zeichenvorrats setzt TCPDF wortlos als "?" (KB #1025). Aufgefallen
an "www.google.de -> 142.250.185.67", das im Kundendokument als
"www.google.de ? 142.250.185.67" ankam. netdiagPdfText() ersetzt die
betroffenen Zeichen jetzt in ALLEN PDF-Zweigen, also auch fuer Altdaten.
Bewusst keine Unicode-Schrift: dejavusans wuerde Schriftbild und Dateigroesse
aller Protokolle aendern. Gedankenstrich, Mittelpunkt und Anfuehrungszeichen
sind in WinAnsi enthalten und bleiben unangetastet (nachgeprueft).
Feld-Whitelist um fehlerglied, stufen, systemUrteil, validated und
captivePortal erweitert. Die letzten beiden kommen aus dem LinkInfo-Objekt
und erscheinen damit auch beim IP-Test an der Dose.
Geprueft an vier Faellen gegen die lokale Testinstanz, zwei davon die echten
Emulator-Messungen dieser Nacht (Gutfall und Flugmodus).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Dauerueberwachung lief im generischen else-Zweig und wurde von
netdiagPdfFlattenResult() zu EINER |-getrennten Zeile zusammengeschoben.
Bei zehn ueberwachten Geraeten standen damit die zehn Geraete-Zeilen und
saemtliche Einzelausfaelle in einer einzigen Tabellenzelle - vollstaendig,
aber beim Kunden nicht lesbar. Dauertest und WLAN-Kanal hatten laengst je
einen Tabellen-Renderer, der Monitor nicht.
netdiagPdfMonitor() gibt jetzt aus: Kennzahlenzeile, Tabelle "Ueberwachte
Geraete", Tabelle "Einzelne Ausfaelle" mit Uhrzeiten, Hinweis zum
Messverfahren am Schluss. Tabellenkoepfe wiederholen sich nach einem
Seitenumbruch.
Die Falle dabei, gegen die im Code ein Kommentar steht: beim Dauertest
fuehrt ein gesetztes 'hinweis' zum sofortigen Abbruch der Ausgabe. Der
Monitor legt aber IMMER einen Hinweis an (das Messverfahren gehoert zur
Aussage dazu) - derselbe Aufbau haette hier bei jedem Lauf alle Zahlen
verschluckt. Nur 'fehler' bricht ab.
Obergrenze 200 Ausfallzeilen gegen ein im Sekundentakt flappendes Geraet.
Gekuerzt wird sichtbar ("... und N weitere Ausfaelle") - stilles Kuerzen
waere bei einem Abnahmebeleg eine Falschaussage.
Ausserdem: 'ausfallzeitSek' heisst jetzt "Ausfallzeit (schlechtestes
Geraet)". Der Wert ist der des schlechtesten Geraets, nicht die Summe -
bei zehn Geraeten las sich "Ausfallzeit: 8 min" wie eine Gesamtaussage.
Geprueft gegen die lokale Testinstanz mit vier konstruierten Faellen
(10 Geraete mit Aussetzern, ein durchgehend totes Geraet, 250 Ausfaelle
ueber sechs Seiten, abgerissener Lauf) und gegen die echte Monitor-
Messung aus ND2026-0016. PDF gerendert und angesehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Geraete-Monitor liefert ab sofort eine richtige Messung (App-Seite).
Ohne diese sechs Schluessel stuende im Kunden-PDF nur die Ampel — genau der
Fehler, der bei der Whitelist schon einmal passiert ist.
geraeteAnzahl, verfuegbarkeitProzent, ausfallzeitSek, aussetzer, geraete,
ausfaelle. Die Werte sind der Beleg fuer "das Netz war ueber X Stunden stabil"
bzw. fuer die haeufigste Reklamation ("die Kamera faellt staendig aus").
Alle vier durch eine systematische Gegenpruefung des echten Codes gefunden,
nicht durch Symptome — sie waren bereits ausgeliefert und still.
1. Whitelist-Schluessel 'typ' existiert nicht. Die App liefert das
LinkInfo-Objekt durch, dort heisst das Feld 'type' (app/src/lib/types.ts).
Folge: im Kundendokument fehlte ausgerechnet beim IP-Test an der Dose die
Angabe, ob per LAN oder WLAN gemessen wurde - bei einem Abnahmebeleg die
halbe Aussage. Zusaetzlich 'rssi' aufgenommen: bei einer WLAN-Dose IST der
Empfangspegel der Messwert, er wurde bisher verworfen.
Die Rohwerte sind englisch; netdiagKundentext() bildet sie jetzt ab
('ethernet' -> 'LAN (Kabel)'), sonst stuende "Anschlussart: ethernet" im
Abnahmeprotokoll eines deutschen Handwerksbetriebs.
2. Leeres Array druckte "Offene Ports: " ohne Wert. Die Leerpruefung ist ein
elseif hinter dem Array-Zweig und wurde nie erreicht. Betraf ausgerechnet
die GUTEN Ergebnisse: Portscan ohne offenen Port, IP-Konflikt ohne
Konflikt, IP-Scan ohne Veraenderung. Jetzt "keine" - Weglassen waere
schlechter, weil der Kunde sonst nicht unterscheiden kann, ob nichts
gefunden oder nichts geprueft wurde.
3. 'error' fehlte in der Whitelist. Der IP-Konflikt gibt im Abbruchfall
{ error: ... } mit roter Ampel zurueck - im Kundendokument stand eine rote
Ampel ohne einen Buchstaben Erklaerung. Die App vereinheitlicht kuenftig
auf 'fehler', aber Altdaten lassen sich nicht aendern.
4. tool/category/label wurden beim Sync nicht auf die Spaltenlaenge gekuerzt
(varchar 64/32/255). Bei striktem SQL-Modus kippt EIN zu langes Label den
gesamten Sync per rollback() - der Techniker steht beim Kunden mit einem
Protokoll da, das sich nicht abschliessen laesst, weil eine Beschriftung zu
lang war. Die App setzt Labels durch Verketten zusammen, 255 Zeichen sind
erreichbar. found_via wurde 20 Zeilen darueber laengst gekappt.
Ausserdem:
- GET-Zweig der API prueft jetzt eine Berechtigung. Bisher konnte jeder
angemeldete Benutzer mit einer geratenen ID ein fremdes Protokoll samt
Geraeteliste, IP-Adressen und offenen Ports abrufen. 'write' wird bewusst
mit akzeptiert: die Rechte sind in Dolibarr einzeln vergebbar, und ein
Techniker mit Schreib- ohne ausdruecklichem Leserecht duerfte nicht
ausgesperrt werden - das waere erst beim Kunden aufgefallen.
- netdiagDauerLesbar: "1 Tage 0 Std" -> "1 Tag". floor() liefert einen Float,
1.0 === 1 ist in PHP false.
Geprueft: php -l, und netdiagFeldFuerKunde() mit 13 echten Faellen gegen die
lokale Instanz durchgerechnet (LAN/WLAN/Mobilfunk, leere und gefuellte Arrays,
error/fehler, tote Schluessel, Interna).
Regression aus dem vorherigen Commit, gefunden bei der Bestandsprüfung von
Phase 6: netdiagKundenfelder() war gegen selbst erzeugte Testdaten gebaut,
nicht gegen die Namen, welche die App-Werkzeuge tatsächlich liefern.
Konkret liefert die App "ziel"/"zielErreicht" (Traceroute), "gegenstelle"/
"downloadMbps"/"uploadMbps" (Durchsatz), "scanned"/"open" (Portscan),
"geprueft"/"runden"/"konflikte" (IP-Konflikt), "port"/"linkSpeed"/
"eingangsFehler"/"ausgangsFehler" (SNMP) sowie das gespreadete LinkInfo beim
IP-Test. Keiner dieser Schlüssel stand in der Tabelle — und weil
netdiagFeldFuerKunde() unbekannte Schlüssel verwirft, wäre im Kundendokument
von diesen fünf Werkzeugen nur noch die Ampel übrig geblieben, ohne einen
einzigen Messwert. Das ist schlechter als der Zustand davor (rohe Schlüssel).
Alle real emittierten Schlüssel ergänzt und gegen die echten Ergebnis-
Strukturen geprüft, Beispiel Portscan:
"Gerät: 192.168.1.50 | Geprüfte Ports: 10 | Offene Ports: 80/http, 443/https"
Lehre für künftige Werkzeuge: die Tabelle ist eine Whitelist, ein neues
Werkzeug braucht dort einen Eintrag — sonst verschwinden seine Messwerte
stillschweigend aus dem Kundendokument.
- Werkzeug-Klarnamen statt interner IDs: "IP-Scanner — 46 Geräte im Netz …"
statt "[netzwerk] ipscan — …". Bewusst eine kurze Zuordnung in
netdiagToolName() statt eines zweiten Satzes Sprachschlüssel — die
kanonischen Namen stehen in der App, doppelte Pflege wäre eine Fehlerquelle.
Enthält auch dhcpcheck/wifiscan: in der App gibt es sie nicht mehr, in der
PRODUKTIONSDATENBANK stehen dazu aber noch Messungen (4 bzw. 2). Die
Gegenprüfung hielt den Punkt für gegenstandslos, hatte dabei aber nur die
Testdatenbank angesehen.
- Messparameter anzeigen (Prod-Messung #126): unter jeder Messung steht jetzt
"Ziel: 192.168.1.1 · Dauer (s): 300" in Karte und PDF. Vorher stand das
Ergebnis ohne Bezugspunkt da — man sah nicht, wogegen gemessen wurde.
- Listenseite: Ampel je Protokoll (schlechteste Einzelmessung) plus Anzahl,
dazu ein Filter "nur mit Befund". Status 3 "nicht messbar" geht bewusst
NICHT ins Maximum ein — er ist keine Aussage über das Kundennetz — sondern
wird separat als "n.m." ausgewiesen. Im Browser geprüft: der Filter liefert
ausschließlich Protokolle mit Warnung oder Fehler.
- N+1-Queries behoben: fetchAllByProtocol() las nur die rowids und setzte je
Zeile ein eigenes fetch() ab. Jetzt eine Abfrage mit setVarsFromFetchObj(),
zusätzlich mit Entity-Filter (fehlte bisher ganz). Nachgemessen über
SHOW SESSION STATUS: 46 Geräte + 7 Messungen brauchen statt 55 Abfragen
noch eine.
- Standort aus der Kundenadresse vorbelegen, wenn der Techniker nichts
eingetragen hat; eine vorhandene Angabe wird nie überschrieben. Über die
echte API geprüft.
Offen bleibt aus Phase 5 nur der Vergleich zweier Protokolle (Geräte-Diff
nach MAC) — eigenes Feature mit eigener Ansicht.
Vorab: drei Punkte der Roadmap-Liste waren Fehlannahmen. Eine Analyse mit
anschließender Gegenprüfung (jeder Befund musste einen Widerlegungsversuch
überstehen) hat sie ausgeräumt, bevor Code geändert wurde:
- "ab Seite 2 alles nach rechts verschoben" existiert nicht. Nachgemessen am
Prod-PDF ND2026-0015 mit pdftotext -bbox: Seite 1 und Seite 2 beginnen beide
bei 16,0 mm. Die echten Umbruchfehler waren andere.
- measure_status validieren war seit Phase 1 erledigt.
- Werkzeug-IDs / Teilnetz-Gruppierung / TCPDF-Fußzeile: verworfen, die
vorgeschlagenen Änderungen hätten das PDF verschlechtert.
PDF (alle Punkte am mehrseitigen Dokument nachgeprüft):
- Tabellenkopf der Geräteliste wird auf Folgeseiten wiederholt. Vorher standen
ab Seite 2 unbeschriftete Spalten — bei leeren MAC/Hostname-Feldern vier
namenlose Spalten.
- Messungs-Titelzeile und Ergebnis werden zusammengehalten. Vorher blieb die
Überschrift samt Ampel am Seitenende allein zurück, darunter ein leerer,
unten offener Rahmen; in einem Testlauf über 61 Umbruchlagen 5-mal (~8 %).
- Spalte "Gerätetyp" hatte 15 mm, ließ aber 10 Zeichen zu — "Chromecast/TV"
lief bis 199,0 mm bei 195 mm Tabellenkante über den Rahmen in den Druckrand.
- Deutsche Bezeichnungen mit Einheiten statt roher JSON-Schlüssel: aus
"VerlustProzent: 0 | MinMs: 4.4 | UptimeSek: 8123456" wird "Paketverlust: 0 %
| Kürzeste Antwortzeit: 4.4 ms | Betriebszeit: 94 Tage 1 Std". Als Whitelist
(netdiagKundenfelder(), gemeinsam für Karte und PDF) — interne Felder wie
arpAvailable, mdnsOk, probed, answered fallen damit automatisch heraus.
- "ARP-Tabelle nicht lesbar (/proc/net/arp) — braucht Root" wird beim Drucken
zu einem kundentauglichen Satz. Altdaten stehen so in der DB, deshalb
Ersetzung beim Drucken statt nur in der App.
Gerätemerkmale (der eigentliche Roadmap-Punkt): Der Techniker sah in der App
"Drucker HP, Port 9100", im Kundenprotokoll stand nur die IP. Die Felder
fehlten dabei nicht in der Übertragung, sondern durchgängig — ein Fix allein
in der API wäre folgenlos geblieben, weil Dolibarrs setSaveQuery() nur
deklarierte $fields schreibt. Ergänzt über die ganze Kette:
sql/llx_netdiag_device.sql + neue Migration llx_netdiag_device_v2.sql
(ADD COLUMN IF NOT EXISTS, wiederholbar, läuft bei jedem Modul-Update),
NetDiagDevice::$fields + Properties, api/protocols.php POST und GET,
Kartenansicht und PDF.
Neu: netbios_name, mdns_name, mdns_services, custom_name, open_ports,
found_via, last_seen. Im PDF steht jetzt statt "192.168.178.20" die Zeile
"Brother HL-L2350DW · Brother · Drucker · 80,443,9100" — der Name kommt aus
mDNS, obwohl der Hostname leer ist.
Sprachschlüssel Vendor -> NetDiagVendor: Die Gegenprüfung hielt den Punkt für
falsch (Translate::load() ist first-wins, im CLI-Test kam "Hersteller"), im
Browser stand in der Kartenansicht aber "Lieferant" — im HTTP-Kontext lädt
Dolibarr vorher andere Sprachdateien als im CLI. Statt der Ursache nachzugehen
jetzt ein eigener, kollisionsfreier Schlüssel; im Browser gegengeprüft.
Nebenbei: doppeltes "OK OK" beim Status 0 im PDF.
Gegen das Test-Dolibarr geprüft: Sync über die echte API (Login, POST, GET),
Felder in der DB kontrolliert, Kartenansicht im Browser, mehrseitiges PDF
gerendert und angesehen, Migration zweimal ausgeführt (idempotent).
Die App kann WLAN-Netze zum Ansehen/Vorführen simulieren (Emulator und Geräte
ohne Empfang zeigen sonst nichts). Solche Momentaufnahmen tragen demodaten:true
im Ergebnis — Kartenansicht und PDF weisen das jetzt als eigene Zeile aus.
Im PDF besonders wichtig: das Dokument geht zum Kunden, dort darf eine
Vorführung nie wie eine echte Messung am Standort aussehen.
Die App legt eine WLAN-Momentaufnahme jetzt als Messung ab (tool='wifikanal'),
damit sie beim Kunden aufgenommen auch im Protokoll auf dem Server ankommt —
bisher lag sie nur lokal auf dem Handy.
- netdiagFormatWifiKanal(): Zusammenfassung (Anzahl Netze, eigenes Netz mit
Kanal/Pegel/Bewertung, störungsärmster 2,4-GHz-Kanal), Hinweisliste und
vollständige Netztabelle. Eigener Zweig wie beim Dauertest, weil die
generische Darstellung das Netz-Array per dol_trunc(...,200) mitten im Satz
abschneiden würde.
- netdiagPdfWifiKanal(): dieselbe Aufbereitung als PDF-Tabelle.
- Nebenbei: PDF zeigte bei Status 0 doppelt "OK OK" (Zeichen + Label).
Gegen das Test-Dolibarr geprüft: Kartenansicht rendert Zusammenfassung, beide
Warnhinweise und alle 12 Netze; PDF-Erzeugung ebenfalls verifiziert.
Der Dauertest liefert seit App-Phase 2 deutlich mehr Ergebnisfelder
(Zeitreihe in Minuten-Buckets, Ausfallsegmente, p95, laengster Ausfall).
netdiagFormatResult() (Web-Karte) und netdiagPdfFlattenResult() (PDF) wuerden
das zu einem einzigen Fliesstext zusammenkleben — die Web-Karte kuerzt jeden
Wert zusaetzlich per dol_trunc(...,200), eine Ausfallliste mit mehreren
Eintraegen waere also mitten im Satz abgeschnitten.
- netdiagFormatResult($json, $tool='') bekommt einen optionalen zweiten
Parameter; fuer $tool==='stresstest' greift netdiagFormatStressTest() statt
der generischen Kuerzung: Kennzahlenzeile (Ziel, Dauer, Takt, Proben,
Verlust, Oe/Min/Max/p95, laengster Ausfall) + eine echte <ul>-Ausfallliste,
ungekuerzt. netdiagprotocol_card.php uebergibt jetzt $m->tool.
- netdiagPdfStressTest() im PDF-Generator macht dasselbe mit TCPDF-Zellen:
Kennzahlenzeile + Ausfalltabelle als eigene Zeilen. Die Zeitreihe
(`verlauf`) wird bewusst NICHT gedruckt — als Diagramm in der App nuetzlich,
als Fliesstext auf Papier nicht.
- Beide Formatierer nutzen dieselben vorformatierten Ausfall-Zeilen
("HH:MM:SS – HH:MM:SS (Xs)"), die auch die App in ihrer Messungen-Liste
zeigt — eine Quelle der Wahrheit statt mehrfacher Formatierung.
Lokal verifiziert (Test-Dolibarr, Modul manuell deployt): Web-Karte zeigt
Kennzahlenzeile + Ausfaelle-Liste mit echten Uhrzeiten statt Rohschluessel,
PDF ebenso (2 Seiten, TCPDF-Ausfalltabelle je Lauf lesbar).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die App kennt seit Phase 1 eine vierte Bewertung: der Test konnte gar nicht
durchgefuehrt werden (Switch antwortet nicht auf SNMP, kein Netz, Gegenstelle
fehlt). Ohne diesen Zustand musste sich ein fehlgeschlagener Test als ok, warn
oder fail ausgeben — in der Praxis meist als Gruen.
- protocols.php nimmt nur noch Bewertungen 0-3 an. Ein unbekannter Wert landete
bisher ungeprueft als Array-Index in Karte und PDF und lief dort ins Leere;
jetzt wird daraus eine Warnung, nie ein OK.
- Protokollkarte und PDF stellen Status 3 grau dar ("Nicht messbar") — weder
gruen (waere gelogen) noch rot (waere eine Aussage ueber das Kundennetz, die
die Messung nicht hergibt).
- Das PDF zeigt die Ampel zusaetzlich als Zeichen (OK / ! / X / ?), damit sie im
Schwarz-Weiss-Ausdruck beim Kunden lesbar bleibt.
- Sprachschluessel NetDiagMeasureUnmeasurable in de_DE und en_US.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Netzwerk-Diagnose-Modul mit JSON-API für die NetDiag-App:
- 3 Tabellen (protocol/device/measurement), generisches JSON-result
- JSON-API: auth, customers, orders, protocols (idempotenter Sync), pdf
- JWT-Auth (HS256), CORS für die Capacitor-App
- Tabs an Thirdparty + Auftrag, Protokoll-Card, PDF-Generator
- QR-Code zum App-Download in der Modul-Konfiguration
- de_DE + en_US, Rechtesystem netdiag->protocol read/write/delete
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
