Ich habe wie angekuendigt in den letzten Tagen ein paar Versuche mit dem GW1100 hinsichtlich der Netzwerkkonnektivitaet gemacht.
Tatsaechlich war es etwas komplizierter, als ich mir das vorgestellt hatte. Immerhin wollte ich meine normale Infrastruktur hier nicht behindern und meine Beobachtungen nach Setzen von spezifischen Filtern auf der Produktiv-Fritzbox waren nicht vertrauenswuerdig.
Testaufbau 1:
- GW1100 sendet per Ecowitt-Protokoll im 16-Sekunden-Intervall zu einem Host im lokalen Netzwerk
- Host und GW1100 sind mit einer Fritzbox verbunden, die physisch keinen Zugang zum Internet hat
- auf dem entgegennehmenden Host laeuft ein kleiner Webserver, um die Daten vom GW1100 entgegenzunehmen (wichtig ist da primaer das 200er ACK) sowie Wireshark
- auf der Fritzbox laeuft der Paketmitschnitt auf der Netzwerkschnittstelle lan (das funktionierte auf der alten 7390 nicht so richtig - der Mitschnitt brach immer wieder unvermittelt ab und die Daten waren verloren)
Zu beachten ist, dass das GW1100 somit auch keinen Zugang zu einem NTP-Server hat - im realen Leben waere dies fuer das Zuruecksetzen der Tageswerte etwa fuer Regen/Tag oder Blitze/Tag oder max. Windboee/Tag also mehr als hinderlich.
Die Uhrzeit startet bei einem GW1100 nach jedem Start des Geraetes mangels RTC/Batterie jeweils mit 01.01.2021 00:00:00, was einen Abruf der tatsechlichen Zeit per NTP erforderlich macht.
Um die Inhalte der versandten Pakete zu verifizieren, musste ich die Tests aber nochmal in einem anderen Testaufbau durchfuehren:
Testaufbau 2:
- GW1100 sendet per Ecowitt-Protokoll im 16-Sekunden-Intervall zu einem Host im lokalen Netzwerk
- Host und GW1100 sind mit einer Fritzbox verbunden, die physisch Zugang zum Internet hat, der jedoch per Filterregeln auf NTP beschraenkt ist
- auf dem entgegennehmenden Host laeuft FOSHKplugin, um die Daten vom GW1100 entgegenzunehmen (wichtig ist da primaer das 200er ACK)
- auf der Fritzbox laeuft der Paketmitschnitt auf der Netzwerkschnittstelle lan (das funktionierte auf der 7490 tadellos)
Beobachtungen:
Beim GW1100 wird nicht mehr der chinesische NTP-Server cn.pool.ntp.org genutzt sondern pool.ntp.org.
Es gibt (erwartbare) Zugriffe vom GW1100 zu rtpdate.ecowitt.net und ota.ecowitt.net. Zusaetzlich versuchte das GW1100 direkt die IP-Adresse 47.102.253.116 zu erreichen (hardcoded um etwaige DNS-Probleme zu umgehen).
Zumindest innerhalb des Beobachtungszeitraums von jeweils ca. 15 Minuten erfolgte kein erneuter Aufbau der WLAN-Verbindung, obwohl die o.a. Hosts nicht erreichbar waren.
Somit wuerde ich im Moment davon ausgehen, das die Firmware dahingehend geaendert wurde:
Das erneute Verbinden mit dem WLAN inkl. DHCP-Abfrage im 10-Minuten-Intervall wenn Ecowitt.net von der Wetterstation aus nicht erreichbar ist, tritt beim GW1100 mit Firmware v2.0.3 NICHT auf.
Aergerlich ist der Zugriff auf rtpdate.ecowitt.net sowie 47.102.253.116 obwohl das Senden zu Ecowitt deaktiviert ist.
Hier erfolgt ein http/POST auf /data/ip_api/ seitens des GW1100, der MAC-Adresse, Station Type und Anfragen nach Zeitzone, UTC-Offset, DST, Sonnenauf- und Untergang enthaelt.
Ich vermute, dass die MAC-Adresse zur Zuordnung der Anfrage zu der auf ecowitt.net registrierten Station dient, um dort die hinterlegten Einstellungen fuer Zeitzone, Sommerzeit, UTC-Offset abzufragen. In der neuen Ecowitt-App wird auch Sonnenauf- und untergang angezeigt - diese Zeiten erhaelt das GW1100 wohl ebenfalls hier.
Ist die Station nicht bei Ecowitt registriert, sollte es also auch kein Ergebnis geben - die Abfrage selbst wird jedoch gestellt.
Die Abfrage von ota.ecowitt.net ist grundsaetzlich nachvollziehbar. Hier fragt das GW1100 ein verfuegbares Firmware-Update am Ecowitt-Server an.
Gesendet wird per http/GET neben der MAC-Adresse die Modellnummer (GW1100A) die aktuelle Zeit und die aktuelle Version (V2.0.3) an /api/ota/v1/version/info.
Die MAC-Adresse muesste dafuer aber eigentlich nicht in den Daten enthalten sein.
Vorstellbar ist, das Ecowitt so Steuerungsmoeglichkeiten hinsichtlich des Firmware-Updates plant, etwa Ausschluss von irgendwelchen Geraeten oder das Ausliefern der Updates in Wellen, um die Serverlast zu minimieren.
Aber natuerlich koennte man auch einer "Sperrliste" besondere Updates angedeihen lassen, etwa um geklaute Geraete ausser Betrieb zu setzen oder Betaversionen gezielt auf einzelne Geraete zu senden.
Per UDP-Broadcast auf Port 59387 wird alle 3 Sekunden mitgeteilt, das das GW1100 mit MAC ... und Firmware-Version ... im Netzwerk verfuegbar ist.
Im Beobachtungszeitraum (immer mal wieder fuer 11-30 Minuten) konnte ich keine weiteren "seltsamen" Verbindungsversuche feststellen.
Fazit:
Nachdem, was ich in meinen Tests gesehen habe, sollte das GW1100 mit einem gefilterten Internet (etwa ausschliesslich NTP erlaubt oder DNS-seitige Umlenkung von pool.ntp.org auf einen Host im lokalen Netz) sehr gut klarkommen koennen.
Ein wiederholter Neuaufbau der WLAN-Verbindung war nicht feststellbar. Die volle Funktionsfaehigkeit ist also auch bei ausschliesslich lokalen Betrieb gegeben. Einzig der noch immer nicht konfigurierbare NTP-Server spricht gegen den Einsatz in lokaler Umgebung out-of-the-box ohne weitere Anpassungen der Infrastruktur.
Das "Nach Hause telefonieren" haelt sich beim GW1100 mit v2.0.3 sehr in Grenzen. Nur der nicht ganz nachvollziehbare Versand der eindeutigen und zuordbaren MAC-Adresse bei der Firmware-Update-Abfrage ist kritikwuerdig. Es sind aber Szenarien denkbar, die das Mitsenden der MAC-Adresse erfordern. Insofern bin ich da mit einer abschliessenden Kritik zurueckhaltend.
Es waren keine "seltsamen" Verbindungsversuche feststellbar.
Zu beachten ist aber, dass diese Aussagen nur auf einige wenige zeitlich befristete Beobachtungszeitraeume basieren und nur fuer das GW1100 mit v2.0.3 zutreffen.
Gruss, Oliver