KNX Instanz kriegt den Neustart des knxd nicht mit.

[eburkon]

Servus miteinander,

ich habe bei mir folgendes Problem: Auf einem Beaglebone Black läuft bei mir der knxd.
Auf einem zweit gerät läuft FHEM und der knxd ist folgendermassen eingebunden:

defmod KNX TUL knxd:192.168.1.10 0.0.2

Funktioniert seit langem super. Nur wenn ich den Beaglebone boote oder den knxd dort neu starte,
kriegt das FHEM das nicht mit. Der Status bleibt auf "initialized" aber es kommen keine Nachrichten mehr an.

Wenn ich FHEM neu starte ist wieder alles gut.

Was kann ich machen?

Gruss
   Ekkehard

[Andi291]

Servus Ekkehard!

Wann hast Du die TUL denn zuletzt geupdated? Seit ca. Dezember müsste das Problem dank docm gelöst sein:

https://forum.fhem.de/index.php/topic,78052.0.html

Code hatte ich eingechecked...

Grüße, Andi

[eburkon]

Hm das letzte Update der FHEM Instanzen hatte ich diese Woche gemacht und mir ist das Problem heute (erneut) aufgefallen.

Gruss
   Ekkehard

[docm]

Hallo,
Ich hatte ein anderes Problem gelöst, nämlich: beim Starten von FHEM prüft TUL, ob knxd funktioniert. Wenn nicht, hing FHEM früher. Das hatte ich gelöst. Hierbei liefen aber FHEM und KNXD auf demselben Rechner. Und das Problem entstand dadurch, dass die Socket Verbindung zwischen FHEM und KNXD sauber war, aber die Socket Verbindung zwischen KNXD und IP-Gateway nicht, was FHEM gar nicht mitbekommen hat.

In deinem Fall liegen die Dinge anders und möglicherweise ist hier noch ein weiterer Bug im TUL. Ich habe schon einen Verdacht und werde mal danach schauen. Eigentlich müsste TUL merken, dass die Socket-Verbindung zum KNXD nicht mehr besteht und entsprechend den Status wechseln zu "disconnected". Wenn KNXD dann wieder verfügbar ist, neu verbinden.

Viele Grüße
Andreas

[eburkon]

Hallo Andreas,

verstehe ich es richtig dass der TUL zum KNXD eine TCP Verbindung aufbaut?
Soweit meine rudimentären Kentnisse in der Socketprogrammierung gehen sollte
da ein Abreissen der Verbindung eigentlich gut zu erkennen sein.

Kann man den TUL eigentlich auch über das KNX Routing Protokoll (also UDP Multicast)
laufen lassen?

Danke &  Gruss
     Ekkehard

[docm]

Ich bin weit entfernt davon, ein Guru auf diesem Gebiet zu sein.
Ja, TUL öffnet einen TCP Port.
Wenn der Server (knxd) sich verabschiedet, schließt das OS des Servers den Socket und TUL kriegt es mit.
Wenn aber der Server stirbt oder die NW-Verbindung unterbrochen wird, bleibt der Socket bestehen und TCP versucht, die Verbindung auf ewig wieder herzustellen. Das kriegt TUL nicht mit.
Ich überlege noch, welche Strategie hier die beste ist. Timeouts mag ich eigentlich nicht besonders. Da passieren dan immer gerne Fehler "zweiter Ordnung", d.h. der Timeout triggert, obwohl sich die Kommunikation gleich darauf gefangen hätte.
Ich bleibe am Thema dran und mede mich demnächst.
Nur kann ich es bei mir nicht testen, da FHEM und knxd auf demselben Raspi laufen. Da ist dann nichts mit NW-Kabel ziehen.
Viele Grüße
Andreas

[Andi291]

Servus Ekkehard!

Ja, Multicast funktioniert - sogar hervorragend. Wann immer möglich nutze ich diesen Weg.
Das könnte in der Tat ein Workaround für Dein Problem sein. Das ich da nicht gleich drauf gekommen bin...

produktives Beispiel:

Code Auswählen Erweitern

DAEMON_ARGS="--allow-forced-broadcast -e 1.0.239 -c -u /tmp/knx -i -b ip:224.0.23.12"

Grüße, Andi

[eburkon]

Servus Andi


Jetzt muss ich leider ganz blöd fragen.

Code Auswählen Erweitern

DAEMON_ARGS="--allow-forced-broadcast -e 1.0.239 -c -u /tmp/knx -i -b ip:224.0.23.12"

Das sind ja die Parameter für den KNXD. Aber wie muss die Definition vom TUL dann aussehen?

Code Auswählen Erweitern

define KNX TUL knxd:224.0.23.12 0.0.2

Kapiert das der TUL dann automatisch?

Gruss
   Ekkehard

[eburkon]

Hallo Andreas

Ich überlege noch, welche Strategie hier die beste ist. Timeouts mag ich eigentlich nicht besonders. Da passieren dan immer gerne Fehler "zweiter Ordnung", d.h. der Timeout triggert, obwohl sich die Kommunikation gleich darauf gefangen hätte.

Also evtl. kann ich da etwas helfen. Ich bin zwar ein mieser Coder aber Netzwerkereien sind eher meine Welt.

Bei einer offenen TCP Session besteht das Problem der halb offenen Verbindungen ja nur in einigen Fällen, die grob damit zu beschreiben sind
das das Ziel also der gesamt "Server" nicht erreichbar ist. Das muesste bei einer Verbindung vom TUL zum KNXD der Fall sein, da der TUL
ja nicht dauernd Nachrichten an den KNXD sendet.

Wenn der KNXD nur crasht oder der "Server" mit dem KNXD gebooted wird sollte dieser an den Client einen Packet mit gesetztem RST Flag
schickt und das sollte der IP Stack dann an die Applikation weitergeben.

Aktuell scheint es mir aber so das der TUL in beiden Fällen den Abbruch nicht mitbekommt.

Ich finde folgenden Artikel ganz hilfreich:

https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html

Gruss
   Ekkehard

[Andi291]

Hallo Ekkehard!

Zefix...Jetzt bin ich bei Dir.
Nein, eine UDP-basierte Verbindung zwischen TUL und knxd gibt es aktuell nicht...

Zu Deiner Anmerkung mit dem Reset Flag:
Mit Wireshark hab ich das schon so oder so gesehen. Java zum Beispiel schickt nie etwas - der bleibt stumm bis zum Sankt-Nimmerleinstag.

Kannst Du vielleicht mal einen PCAP-Trace vom fraglichen Event ziehen und posten?

[docm]

Hallo Ekkehard,

ich habe mir den TUL Code nochmals angeschaut. Hiernach müsste, wenn die knxd Seite den Socket schließt, sei es, dass der Dämon regulär beendet wird, oder dass das OS den Socket schließt, TUL dieses erkennen und in den Disconnected State gehen. So passiert es auch, wenn ich den knxd manuell stoppe. Starte ich ihn dann manuell wieder, so wird der Zustand "initialized" wieder hergestellt.

Das geht aber nur in der letzten Version des TUL mit meinen Modifikationen aus 2017-11-06.

Ein Trennen der NW-Verbindung kann ich nicht testen, da bei mir FHEM und knxd auf derselben Maschine laufen. Ich würde aber vermuten, dass dies nicht sauber erkannt wird, da der Socket nicht geschlossen wird.

Hier suche ich aktuell noch nach einer Möglichkeit, die Socket-Verbindung zu monitoren. Ein SO_KEEPALIVE bringt nichts, da er erst nach zwei Stunden aufgibt. Das Applikationsprotokoll "knxd frontend protocol" ist leider nicht gut dokumentiert, bzw. konnte ich noch nichts dazu finden. Es gibt wohl keine Heartbeat Message, über die man applikatorisch prüfen kann, ob der Link noch steht.

Ein Workaround könnte darin bestehen, dass man beim Senden von GAs aus FHEM heraus die TCP Send Queue prüft, ob Nachrichten vom knxd quittiert wurden oder noch auf TCP-Quittung warten. Ich habe aber noch keinen Perl-Befehl gefunden, der diese Info liefert. Entsprechend dem 'ss' Befehl in linux, der u.a. einen Wert send_q liefert. Ist jemandem hierzu etwas bekannt?

Viele Grüße
Andreas

[Andi291]

Servus!

Nochmal die Frage - kannst Du bitte einen Wireshark-Trace vom Abbruch der Verbindung ziehen?
Im Idealfall schickt der knxd bereits was durch - und es wird nur ignoriert...

Grüße, Andi