Also irgendwas stimmt mit dem Dienst in der aktuellen Version nicht.
Die Netzwerkprobleme werden immer massiver.
Ich habe jetzt mal parallel auf dem Server einen Dauer-Ping auf ein Gerät laufen lassen, was ständig Konnektivitätsprobleme hat. Wenn IPS läuft, habe ich immer wieder hohe Latenzen beim Ping und häufige Timeouts. Beende ich IPS ist der Ping völlig unauffällig. Keine Timeouts, alle Antworten < 1 ms, so wie es normalerweise immer der Fall ist. Das ist doch nicht normal…
Oh,
@paresy Das Problem habe ich auch auf meinem Debian basierten System! Ich hatte zunächst an ein Router- oder Switchproblem gedacht. Daher hatte ich die Kabel schon umgepatcht; ohne Erfolg. War schon kurz davor mir ein neues KNX Gateway zu kaufen. Das scheint dann ja doch kein physisches Problem zu sein. Die KNX Abbrüche stelle ich auch fest und konnte bisher nicht eingrenzen woran es liegen kann.
Außerdem wird auch dieses Log immer erst dann, also verzögert, angezeigt, wenn andere, nicht systemnahe Ereignisse diese in die Logdatei mitschleppen. Da hatte ich schon mehrfach in anderen Beiträgen drauf hingewiesen; aber bisher leider immer noch keine Antwort erhalten.
Ich ja habe bei KNX gestern auch eine Zeitüberschreitung im Log gehabt. Es sollte einfach nur ein Wert auf den Bus gesendet werden.
Ich habe die letzte verfügbare Stable Version.
Siehst du irgendwie, dass Symcon das Netzwerk mit etwas belastet? Oder woher könnten diese Latzenzen kommen?
paresy
Ich habe noch keine richtige Idee. Das scheint sich aber mit der Zeit aufzuschaukeln, je länger der Dienst läuft. Starte ich ihn neu, ist erst mal Ruhe und mit der Zeit nehmen die Verbindungsprobleme zu und treten immer häufiger auf, als ob IPS den Netzwerkstack mit der Zeit verstopfen würde.
Ich dachte zwischendurch schon an Nachwehen von dem DNS-Problem, da der lokale DNS-Server teilweise noch Probleme hatte, lokale Namen aufzulösen. Das ist aber seit einem Neustart des Routers weg.
Ich gucke später mal, ob ich was in Wireshark oder so sehe. Bin aber noch länger unterwegs.
Wäre interessant zu wissen, ob die alte Version vom Dienst jetzt auch die Probleme hat. Aber ich habe wie gesagt das Backup verpennt.
Ich habe die Beiträge mal rausgetrennt. Das andere Thema ist nur beim Symcon Start und da klemmt es beim DNS von cURL. Was auch immer mit den I/Os los zu sein scheint, muss irgendwas anderes ein. Soweit ich das verstanden habe, passiert das auch erst während der Laufzeit. → Könnt ihr das Problem provozieren oder nutzt ihr bei KNX über UDP oder KNX über TCP?
paresy
Ich nutze UDP für das KNX Gateway mit 9.0 und Rev ac13fd5faf31 auf Debian 13 ohne Docker. Die KNX Probleme sind sehr sporadisch. DNS ist bei mir die Fritzbox für diesen Server. Dennoch ist ein AdGuardHome im Netz für die Clients. Der Debian-Server hat aber eigentlich nichts mit dem AdGuardHome zutun - der ist für meine Server ausgenommen und sollte nicht dazwischen funken. Sonstige Probleme mit anderen Clients oder anderer Software habe ich bisher nicht feststellen können - alles andere läuft normal. Ich beobachte weiter.
Bei KNX habe ich aktuell einen UniFi Kunden, der ebenfalls UDP nutzt und dort sendet UniFi auf dem Port 52000 sporadisch irgendwelche Broadcast Pakete, die Symcon einsammelt und dadurch aus dem Tritt kommt. Wenn ihr den UDP Socket einmal mitloggt (Dort am besten in Datei), dann könnten wir prüfen ob rund um den Zeitstempel des Fehlers ggf. ein größeres Paket von einer andere IP-Adresse empfangen wurde.
Ein Fix dafür habe ich schon fertig → Sobald ich das Kundenfeedback habe, dass es gut ist, kommt der auch in die nächste 9.0er Beta rein.
paresy
Ich werde in meinem Netzwerk auf einem anderen Gerät einen Sniffer einbauen und den Port 52000 belauschen. Mal schauen wer da alles so sendet.
Ich zeichne jetzt auch mal Port 52000 auf.
Zusätzlich auch noch Modbus TCP. Denn bei mir sind ja verschiedene Protokolle (ICMP, TCP, UDP) und Ports betroffen.
Ich habe aber gerade das Gefühl, dass sich die Situation gerade etwas stabilisiert - warum auch immer…
Gestern über den Tag verteilt hatte ich einzelne Zeiträume, wo es mal zu vermehrten Verbindungsproblemen kam, aber wesentlich weniger und auch von der Dauer deutlich kürzer als die beiden Tage davor.
Die letzten Timeouts bzw. Verbindungsabbrüche bei KNX und Modbus TCP sehe ich gestern kurz vor Mitternacht. Auch ICMP (Ping) läuft gerade ohne irgendwelche Probleme durch.
Ein generelles Problem mit der 9.0 würde ich für mich ohnehin ausschließen, da die Probleme bei mir ja erst mit der Installation der aktuellen 9.0 Stable von dieser Woche auftraten. Davor lief die 9.0 ja schon bei mir seit dem Release ohne irgendwelche Probleme.
Vielleicht gab es doch noch irgendwelche Nachwehen durch das DNS-Problem diese Woche. Ich warte mal den Tag ab, was so passiert. Falls wieder ein KNX-Timeout auftreten sollte, hätte ich dann zumindest den Mitschnitt der entsprechenden UDP-Pakete zu dieser Zeit.
Also gestern und heute war alles weitestgehend unauffällig. Bei ICMP und KNX gab es überhaupt keine Probleme. Wirklich seltsam. Ich habe das System nicht mehr angefasst. Lediglich bei Modbus TCP gab es zwei Verbindungsabbrüche. Beide Male kam ein TCP Reset vom Server. In Symcon sehe ich in einem Fall vorher folgende Fehlermeldungen:
Kann Daten nicht zur Instanz weiterleiten: TransactionID stimmt nicht überein.
UDP-Pakete auf Port 52000, die nicht von KNX kamen, sehe ich bis jetzt keine, obwohl ich UniFi-Geräte im Netz habe.
Bei mir ist auch lange nichts mehr passiert. Aber vorhin dann doch wieder. Im Netz habe ich bisher keinen anderen Dienste vernehmen können die da rumfunken. Ich habe nun einen TCP Dump installiert, der beim nächsten Fehler reagieren sollte.
Beim tieferen Suchen im System bisherige Feststellung: Alles normal bis auf die Tatssache das viel Drops festzustellen sind. Ich berichte sobald ich mehr herausgefunden habe. Ihc muss nun auf den nächsten Fehler warten.
Ich habe nun einige Vorfälle gehabt:
Zeit ObjektID Meldungstyp Sender Meldung
09.05.2026 17:51:49 11557 ERROR TimerPool KNX Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Antwort
09.05.2026 17:25:39 11557 ERROR TimerPool KNX Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Antwort
09.05.2026 16:30:25 11557 ERROR TimerPool KNX Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Antwort
09.05.2026 14:46:01 11557 ERROR TimerPool KNX Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Antwort
Ich plage mich gerade auch mit ein paar FritzBox/Provider-Problemen rum. Da scheint es wohl Parallen zu geben. Der Symcon Debian Server bezieht seine DNS von der Fritzbox. Auch das Standardgateway ist die Fritzbox. Ich habe nun viel mitgeloggt und tiefere TCP-Dump mitgeloggt. Es scheint so, dass wenn die Fritzbox Internetprobleme, insbesondere mit DNS hat, dann ruckelt offensichtlich auf das KNX Gateway. Im Gateway ist allerdings nur IP eingegeben und keine interne Domain.
Die KNX-Probleme hängen vielleicht nicht direkt mit der KNX-IP zusammen, sondern indirekt mit DNS-/Netzwerkproblemen der Fritzbox. Genau vor einem KNX-Ausfall gab es im System einen DNS-Fehler („temporärer Fehler bei der Namensauflösung“). In den Mitschnitten sieht man anschließend, dass das KNX-Gateway mehrfach sendet, Symcon aber zeitweise nicht antwortet.
Zur Analyse wurden genutzt:
ip -s link, ethtool -S, ss, tcpdump mit Hexdump/pcap-Mitschnitt als systemd-Dienst, journalctl, ip neigh, nstat, top sowie Zeitkorrelation der Pakete mit den Fehlerzeitpunkten. Dabei zeigten sich keine CPU-, RAM-, NIC- oder Kernelprobleme und keine echten Paketverluste im Linux-Stack.
Jetzt läuft ein Praxistest mit externen DNS-Servern (1.1.1.1 / 8.8.8.8) statt Fritzbox-DNS.
Nachtrag:
Ich habe nun versucht das Fehlverhalten nachzustellen. Leider ohne Erfolg. Irgendwie verdichtet sich die Vermutung, dass bei DSL/WAN/IP/DNS Problemen der Fritzbox die Switch-Funktion der Fritzbox Probleme macht. Die Verbindung des KNX Gateway läuft zum Symcon Server bei mir unter anderen auch über die Fritzbox. Laut Internetrecheren wird von derartigen Problemen berichtet. Die UDP Verbindung ist auch wohl ziemlich empfindlich auf Layer2 Ebene.
@Slummi Nutzt du eine FritzBox und hast diese auch als Switch zwischen den KNX Gateway und Symcon? Hast die ein Eibmarkt Gateway?
Auch wenn das Switch der Fritzbox nicht immer sauber ist muss das ausgeschlossen werden. Ich habe umgepatcht und der Fehler ist nun noch 3 mal aufgetreten. Aber der TCP Dump zeigt nun etwas.
Gateway Symcon DisconnectRequest.
Danach antwortet Symcon jeweils später mit:
0610 0421 = verspätetes Tunneling ACK
0610 020a = DisconnectResponse
Das Gateway trennt aktiv, weil es vorher auf eine erwartete Antwort von Symcon wartet oder die Session für ungültig hält. WAN/DNS waren zu der Zeit sauber. KNX-Modul verarbeitet bestimmte Gateway-Tunnelpakete vermutlich nicht rechtzeitig oder nicht korrekt. Das Gateway wiederholt/timeoutet und beendet dann die Tunnelverbindung.
Gateway sendet 0610 0420, danach 0610 0209 DisconnectRequest; KNX Modul schickt das ACK erst viel zu spät und bestätigt dann den Disconnect.
Ablauf:
Gateway sendet 0610 0420 = TUNNELING_REQUEST
Symcon müsste zeitnah 0610 0421 = TUNNELING_ACK senden
ACK kommt offenbar zu spät / doppelt / nach Timeout
Gateway betrachtet die Session als gestört
Gateway sendet 0610 0209 = DISCONNECT_REQUEST
Symcon bestätigt mit 0610 020A = DISCONNECT_RESPONSE
Symcon verbindet neu
Nachtrag:
Nachdem ich vor zwei Tagen “ethtool -K ens18 gro off gso off tso off” das Netzwerkverhalten angepasst habe, habe ich bisher keinen Abbruch mehr gehabt. Evtl. ein Hinweis auf Fehler im KNX Modul.
Was macht die Einstellung:
eingehende kleine Pakete werden nicht mehr zu größeren Paketen zusammengefasst
große Pakete werden nicht mehr virtuell gesammelt und später segmentiert
TCP-Segmentierung Offload AUS
Besonders relevant war vermutlich: gro off
Also ich sehe weiterhin keine Netzwerk-Probleme mehr und gehe daher immer noch davon aus, dass dieser plötzliche Auftritt der Probleme und das Andauern über einige Tage auf den DNS-Ausfall zurückzuführen war. Anders kann ich es mir im Moment nicht erklären.