ich habe am Wochenende meine Symcon-Installation (Windows Server) auf die 7.1 aktualisiert. Seither spinnt bei mir mehrmals am Tag der Zugriff auf den KNX-Bus. Im Prinzip reagieren dann keinerlei KNX-Geräte (andere Geräte wie Unify, Videos, Plugins machen keine Probleme) mehr. Erst ein Neustart des Symcon-Dienstes behebt das Problem wieder.
Ich habe einmal den Debug mitlaufen lassen und habe festgestellt, dass irgendwann Einträge mit „unknown Service“ kommen (siehe Screenshot).
Danach habe kommen im Log nur noch Einträge im Status „Transmit“ und Waiting. Bis zu dem Unknown Service-Eintrag lief alles ohne Probleme.
Hat da irgendwer eine Idee, was das sein kann? Irgendwie habe ich das Gefühl, dass da ein Gerät aus dem Netzwerk einen connect auf dem KNX-Port des Symcon-Servers macht und dadurch das KNX-Gateway zum Absturz bringt.
Es scheint sich bei dir irgendein Datenpaket auf dem UDP Port vom KNX Interface zu verirren. Wir hatten das schon einmal bei einem Kunden bei dem die PenTests der Firewall alle Ports gescannt hatten und IP-Symcon dann dadurch durcheinander gekommen ist.
Hängt die IP-Adresse von Symcon System irgendwie offen im Internet, sodass solch eine Anfrage von extern kommen könnte?
vielen Dank schon mal für die Infos. Ich habe mittlerweile mit Hilfe von Wireshark und Chat-CPT noch ein paar Dinge heraus gefunden:
Das Problem trat eindeutig ab Version 7.1 auf. Vorher hatte ich keinerlei Probleme (Symcon läuft jetzt schon - ich glaube - 2 Jahre stabil). Direkt 30 Minuten nach dem Update hatte ich das erste Mal das Problem, dass Symcon überhaupt keine Daten mehr vom KNX-Bus, bzw. zum KNX-Bus senden konnte.
Ein Deaktivieren des UDP-Sockets und anschließendes Aktivieren brachte nichts. Nur ein Neustart des Symcon-Dienstes hatte funktioniert.
Ich habe das relevante Datenpacket Chat-CPT zur Analyse gegeben. Die relevante Antwort dazu: „Die Hex-Kette, die du zur Verfügung gestellt hast, scheint Teil eines DNS-Response-Pakets zu sein. Dies wird deutlich durch die Struktur, in der du Fragen (Queries) und Antworten (Responses) mit spezifischen Details wie IP-Adressen, TTL (Time to Live) und anderen DNS-spezifischen Informationen siehst.“
=> Das bestätigt auch schon eine meiner Vermutungen. Symcon läuft bei mir auf einem Windows Domain-Controller zu Hause mit aktiviertem DNS.
Der Server ist von außen druch Router und Firewall abgeschottet. Es ist nur der Port 3777 für die App frei.
Leider sieht man im Debug-Modus des KNX-Gateways keine Ports und IPs der Quelle. Daher habe ich Wireshark parallel zum KNX-Gateway mit Filter auf dem Quell- und Ziel-Port des UDP-Sockets (3671 und 52000) mit laufen lassenlaufen. Interessant war, dass zum relevanten Zeitpunkt als das Datenpacket ankam auf keinem der beiden Ports im Wireshark etwas dokumentiert wurde.
=> D.h. die Anfrage kam nicht über das KNX-Gateway. Warum wurde das dann dort dokumentiert?
=> aktuell lasse ich den Wireshark ohne Portfilter nur mit Fitlter auf die IP des Servers laufen und warte einmal auf den Fehler im KNX-Gateway. Mal sehen, ob ich da mehr sehe.
=> außerdem lasse ich dank des Tipps von Dir auch noch den Debug des UDP-Sockets mit laufen. Da sieht man dann auch die IPs samt Port.
Ich hatte die Echo- und Fire-TV-Geräte bei mir im Netzwerk auch schon im Verdacht, da in den DNS-Anfragen die Domänen AWS und Amazon häufig vor kamen und ich Echo mit Symcon verbunden habe. Ich denke aber mittlerweile nicht mehr, dass es daran liegt.
Allgemein solltet Ihr trotzdem das Gateway so umprogrammieren, dass verirrte Datenpakete gefiltert werden. So könnte ich das Gateway wahrscheinlich ziemlich leicht durch Socket-Anfragen zum Absturz bringen. Die Frage ist auch, ob es nicht sogar an Anfragen an den Port 3777 der nach außen gemappt wird liegt, damit ich auf die App zugreifen kann.
Nun habe ich den eindeutigen Nachweis.
Leider schreibt das UDP-Socet-Debug-Protokoll nicht in eine Datei, obwohl ich „an Datei schicken“ aktiviert habe. Ist aber egal, ich habe Wireshark parallel laufen lassen:
Heute um 13:15 und 39 (lt. Debug-Protokoll KN X-Gateway) hatten wir wieder einen Absturz der Verbindung zum KXN. Dieses Mal konnte ich über Wireshark auch die IP identifizieren. Das ist einer unserer Firmen-DNS-Server gewesen, der per VPN mit mir zu Hause verbunden ist. Warum der über den Port 52000 mit meinem Server zu Hause kommuniziert hatte ist mir ein völliges Rätzel:
Somit wissen wir, dass diese DNS-Anfrage der Grund für den Absturz ist / war. Ich werde auf dem Server die Firewall so konfigurieren, dass Anfragen an den Port 52000 von allen anderen Geräten außer dem KNX-Gateway selbst geblockt werden.
@parsey: Wäre praktisch, wenn Ihr im UDP-Socket eine Art Firewall einbauen könnt. Also am einfachsten etwas, dass Anfragen nur von bestimmten Geräten angenommen werden. Eigentlich würde es reichen, wenn nur Anfragen von dieser IP …
Ne das geht nicht.
Andere Systeme nutzen den UDP Socket um mit mehreren Geräten zu sprechen.
Dann würden die nicht mehr funktionieren.
Die Logik müsste schon in der KNX Gateway Instanz stattfinden.
Michael
Wenn man das aber optional löst? Ich könnte mir vorstellen, dass es ähnliche Probleme auch bei anderen Diensten gäbe, die Socket-Kommunikation nutzen. Im Prinzip wäre hier tatsächlich eine kleine Firewall nicht schlecht.
Könnt Ihr auch mal das Debug-Log vom Socket prüfen. Das hat mir nur ein paar Datensätze nach dem Klick auf Download angezeigt, ob wohl es mehrere Stunden gelaufen ist. Beim KNX Gateway Log hat es ohne Probleme funktioniert auch mehrere Stunden Log in die Datei zu speichern. Ich hatte bei beiden Logs diese Schaltfläche aktiviert:
Wenn man hier eine Firewall-Logik integriert, macht das eher sinn in der Socket-Komponente. Oder man baut gleich eine eigene Firewallkomponente ein. Das wird dann aber für unbedarfte User wieder schwierig.
Idee wäre, dass man aus dem Socket heraus automatisiert Firewall-Komponenten generiert.
