Connectionstate_response

[MiCon]

Hallo,
ich habe schon im allgemeinen KNX-Forum eine ähnliche Frage gestellt, aber leider keine Antwort bekommen. Vielleicht kann man mir ja hier weiter helfen.

Ich betreibe Wiregate als IP-Tunnel für KNX. Beim Tunnel muss laut KNX-Spezifikation wohl ein Heartbeat gesendet werden ("State_connection_request"). Diese Anfrage wird von Wiregate auch mit einem Connectionstate_response beantwortet. In 50% der Fälle wird alllerdings kein Status 0 gesendet, was wohl soviel bedeuten würde wie "Alles OK", sondern ein Status 15. Hier mal das IP-Telegramm:

Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 02 15 192.168.178.32:3671 ChID : 2 SeqCntIN : 72 SeqCntOUT : 97 msgCode : [object Object]

So sieht das Telegramm aus, wenn alles OK ist:

Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 02 00 192.168.178.32:3671 ChID : 2 SeqCntIN : 234 SeqCntOUT : 97 msgCode : [object Object]

Kann mir jemand sagen, was der gesendete Status 15 bedeutet? Wenn das Gateway eine Macke hat, tausche ich es auch aus. Ich würde nur schon gerne wissen, was die "Fehlermeldung" denn überhaupt bedeutet. Im Netz konnte ich hierzu nichts finden und leider habe ich auch keinen Zugriff auf die KNX-Spezifikation.

Ich weiß auch, dass Wiregate eibd einsetzt und nicht knxd. Da knxd aber aus eibd entstanden ist und die Spezifiaktion wohl gleich sein dürfte, hoffe ich, dass hier jemand die Lösung weiß.

Vielen Dank!

[Smurf]

Das ist nicht 15 sondern 21 (weil hex). E_CONNECTION_ID bedeutet, dass es eine Verbindung mit der angegebenen ID nicht gibt. Abhilfe wäre wohl erstmal, den Heartbeat öfters zu schicken.

[MiCon]

Vielen Dank für Deine Antwort. Wenn ich diese richtig verstanden habe, bricht der Tunnel also zwischendurch zusammen. Mein Client (knx-Adapter vom iobroker) sendet dann einen Heartbeat und Wiregate antwortet, dass der Tunnel (in meinem Fall 2) nicht existiert.

Der Heartbeat wurde vom Adapter wie folgt gesendet:

08:01:53.168	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:04:03.473	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:05:03.462	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:06:30.563	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:08:39.948	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:10:28.220	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:10:46.745	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:12:28.012	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:12:44.045	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:14:08.231	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:16:13.389	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:18:23.386	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:20:35.371	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:22:47.358	knx.0 (6844) checkConnectionState 192.168.178.32 State : true
08:23:03.345	knx.0 (6844) checkConnectionState 192.168.178.32 State : true

Orange markiert sind die Anfragen, die zu einem negativen Ergebnis führten. Diese sind alle mehr als zwei Minuten vom letzten Heartbeat entfernt. Das ist für eibd dann also zu lange und er schließt den Tunnel?

Habe ich das so richtig verstanden?

[Smurf]

Jau, der knxd-Timeout ist (seit Urzeiten) fest auf 2 Minuten eingestellt.

Dein Log sieht nach Paketverlust aus.

[MiCon]

Super, vielen Dank!

An Paketverlust glaube ich weniger. Ich habe den ioBroker auf zwei unabhängigen Maschinen installiert und bei beiden das gleiche Phänomen. Das oben dargestellte Log kommt auch aus dem ioBroker und nicht vom Wiregate. In dem Log sollten ja alle gesendeten Heartbeats enthalten sein. Von daher glaube ich eher, dass der Adapter in ioBroker das Problem verursacht. Zumindest kann ich es mir jetzt erst einmal sparen, einen neuen IP Router zu kaufen. Der würde bei dem fehlenden Heartbeats ja vermutlich auch die Verbindung trennen.

[Smurf]

Hängt davon ab wann er loggt. Egal, in deinem Fall würde ich einfach mal die 120 Sekunden im knxd hochsetzen. Findest du in Zeile 137 von src/libserver/eibnetip.h und unsinnigerweise außerdem in Zeile 459 src/libserver/eibnetserver.cpp (uppsi, gleich mal korrigieren).

[MiCon]

Wow, das ist natürlich eine pragmatische Idee. Dann müsste ich mir aber erst einmal eine eigene Schnittstelle bauen. Zur Zeit nutze ich dafür ja ein Wiregate, welches eibd integriert hat. Da kann ich glaube ich nicht so einfach so tiefe Eingriffe vornehmen. Hätte auch den Nachteil, dass ich bei einem zukünftigen Update es immer wieder ändern müsste. Da hoffe ich glaube lieber entweder auf einen Fix vom Programmierer des Adapters in ioBroker (source ist leider nicht offen) oder ich schaue mich nach einem anderen System um, dass stabil läuft. Kannst Du etwas empfehlen, was stabil mit KNX läuft und ähnlich "kommunikationsfreudig" ist wie ioBroker?

[Smurf]

Du kannst genauso gut einen beliebigen Rechner nehmen und darauf einen aktuellen knxd laufen lassen, der die Pakete einfach durchreicht. Dafür braucht es natürlich für Sende- und Empfangsseite unterschiedliche Timeouts. Der Timer im Tunnelclient des knxd steht bei 30 Sekunden und ist einstellbar; für die 120 Sekunden des Servers werde ich das gleich mal nachrüsten.

[MiCon]

Ah, super! Dann könnte ich knxd ja einfach in einem Docker auf der Synology laufen lassen. IoBroker gebe ich dann knxd als Schnittstelle und in knxd gebe ich Wiregate als Schnittstelle an. Dann reicht knxd einfach alles in beiden Richtungen weiter. Richtig? Meinst Du mit „Nachrüsten“, dass ich das dann über eine config einstellen kann, ohne den Sourcecode zu ändern? Das wäre natürlich ein Traum!

[makki]

Ähm mit Verlaub ich habe 98% der Zertifizierung mit dem knxd auf WG durchgezogen, wenn das ned geht ist zu ca. 102% eher der Client oder etwas anderes im Netzwerk Schuld, kein Grund da am Source an Timeouts rumzufuddeln.. Besser: die Ursache reparieren..

Makki

[Smurf]

makki Das glaube ich dir aufs Wort, aber ich finde es trotzdem besser wenn man den Timeout auf Client- genauso wie auf Serverseite einstellen (d.h. auch: ganz abschalten) kann. Seitens des Clients geht das schon längst …

Wenn man einen Berg Geräte ohne Sourcen hat, muss man halt leider manchmal etwas pfriemeln, ansonsten könnte ich die Hälfte der Optionen vom knxd von vornherein entsorgen. Ich streng mich persönlich ziemlich an, dieses Problem von vornherein nicht zu haben, aber nicht jeder ist in derselben glücklichen Lage.

[MiCon]

Ähm mit Verlaub ich habe 98% der Zertifizierung mit dem knxd auf WG durchgezogen, wenn das ned geht ist zu ca. 102% eher der Client oder etwas anderes im Netzwerk Schuld, kein Grund da am Source an Timeouts rumzufuddeln.. Besser: die Ursache reparieren..

Makki

Das sehe ich auch so. Ich hoffe mal, dass der Entwickler des KNX-Adapters den Fehler behebt. Bis dahin bin ich für den nicht konformen Lösungsansatz aber sehr dankbar.

[makki]

Smurf ja schon, aber wenn man offenbar wie im vorliegenden Fall einfach ein Problem mit dem Netzwerk/Schnittstelle hat ist das herumfuddeln an Timeouts im Sourcecode bestenfalls ein schlechter Workaround den Standard zu "dehnen", keine wirkliche Lösung des Problems, neh..

Edit: wenn der IPT 120s keinen Keepalive bekommt wird das ja an irgendwas liegen..

Makki

[MiCon]

Ich meine nicht, dass es am Netzwerk oder an der Schnittstelle liegt. Wie bereits oben aufgeführt tritt das Verhalten an zwei unabhängig voneinander aufgesetzten Maschinen auf und der Heartbeat fehlt ja schon im Protokoll des KNX-Adapters im ioBroker. Ich denke daher, dass das Problem beim KNX-Adapter liegt.

[makki]

Ich bin bin jetzt mal böse: wer zum Henker ist ioBroker? hat ein KNX-Label? Nimm nen TP-UART 1/2 und geniesse das Leben Störungsfrei

Makki