Systemstart und sendtcp()

[enertegus]

Den habe ich ja schon grundsätzlich analysiert, überarbeitet und sehe, dass z.B. die Debug-Outputs per UDP raus gehen, während die über TCP 20 Sekunden auf sich warten lassen.

Ich denke, dass auch die Anzahl der offenen Ports begrenzt sind.
3..4 Sekunden, bis der Socket komplett initialisiert ist, v.a. da ja erst der alte 100ms davor geschlossen wird, erscheinen mir da auch etwas langsam, aber 20 Sekunden sind sehr seltsam.
Begriffen habe ich aber eben noch nicht, warum CF da innerhalb von 100ms den Socket zu und wieder auf macht.
Andererseits steht im CF keine Zeit für die Antwort außer 3 Sekunden heartbeat - auch keine Zeit, wie lange die Antwort beim Connect brauchen darf. EDIT: Würde man z.B. per VPN darauf zugreifen, müsste CF sicher längere Zeiten erlauben.
Diese Telegramm ACK und Portwechsel sind ja nochmal bei T551 bis T555 der Fall. Auch sehr merkwürdig, warum da CF in T551 bei der laufenden Verbindung wie bei T240 diese schließt und gleich wieder öffnet. Soll das ok sein, oder woher kommt das?

Das erste Passwort muss aber trotzdem am Anfang in der Schlange stehen.

Wenn sie leer war, ja.

[saft6luck]

Ich denke, dass auch die Anzahl der offenen Ports begrenzt sind.
3..4 Sekunden, bis der Socket komplett initialisiert ist, v.a. da ja erst der alte 100ms davor geschlossen wird, erscheinen mir da auch etwas langsam, aber 20 Sekunden sind sehr seltsam.

Der Connect ist ja eigentlich schon gelaufen, die Daten kommen ja schon vom CF und die Antwort ist auch schon generiert, sie geht nur über TCP nicht raus, über UDP schon.

Begriffen habe ich aber eben noch nicht, warum CF da innerhalb von 100ms den Socket zu und wieder auf macht.
Andererseits steht im CF keine Zeit für die Antwort außer 3 Sekunden heartbeat - auch keine Zeit, wie lange die Antwort beim Connect brauchen darf. EDIT: Würde man z.B. per VPN darauf zugreifen, müsste CF sicher längere Zeiten erlauben.
Diese Telegramm ACK und Portwechsel sind ja nochmal bei T551 bis T555 der Fall. Auch sehr merkwürdig, warum da CF in T551 bei der laufenden Verbindung wie bei T240 diese schließt und gleich wieder öffnet. Soll das ok sein, oder woher kommt das?

Im ersten Fall sicherlich wegen des Timeouts. Dem CF fehlt die Geduld, nachdem er schon mehrere Alive geschickt hat (die ja sofort beantwortet werden sollten).

Später hat der Nutzer wahrscheinlich die App einfach in den Hintergrund geschickt und dann wieder vorgeholt. Hier wird der Connect (kann man einstellen) dann wieder erneuert.

Am Ende darf das den Server aber nicht stören und tut es ja auch nicht (bis auf den Glitch mit den falschen Ports beim Übergang, das kann der CF aber ab).

Für den CF gilt:
1. Auf Passwort kommt OK.
2. Generell: Sollte keine Antwort kommen, wird die Verbindung über ein Alive offen gehalten (auch wichtig für den eibPC, der die Verbindung ohne Kommunikation ja genauso schließen würde, allerdings erst nach 30 sek). Kommt keine Antwort auf das Alive wird neu Verbunden.
4. Anfragen können gebündelt werden, die Antworten (falls spezifisch) müssen (trotzdem) in der richtigen Reihenfolge kommen. Hier gilt nur der entsprechende Port, falsche Ports werden vom CF natürlich nicht beachtet.
5. Wird keine Antwort auf die jeweiligen Anfragen empfangen, wird der Connect gekillt und ein neuer Versuch gestartet.
6. Wenn der CF den Status updaten will, schickt er ein init.

Wenn sie leer war, ja.

Klar, war sie im 1. Fall doch, oder?

[enertegus]

Der Connect ist ja eigentlich schon gelaufen, die Daten kommen ja schon vom CF und die Antwort ist auch schon generiert, sie geht nur über TCP nicht raus, über UDP schon. Vielleicht braucht man da eine Art flush. muss ich mal an die FW weitergeben.

Du schickst eine Debugmeldung per UDP, die kommt sofort an, aber die TCP nicht?

Im ersten Fall sicherlich wegen des Timeouts. Dem CF fehlt die Geduld, nachdem er schon mehrere Alive geschickt hat (die ja sofort beantwortet werden sollten).

nee, doch erst nach dem p=ok (so hab ich das verstanden). Vorher darf überhaupt kein heartbeat schicken.

[saft6luck]

Du schickst eine Debugmeldung per UDP, die kommt sofort an, aber die TCP nicht?

Genau.

nee, doch erst nach dem p=ok (so hab ich das verstanden). Vorher darf überhaupt kein heartbeat schicken.

Das Alive ist quasi autark. Die Verbindung wird durch das Alive aufrecht erhalten. Würde der eibPC antworten, käme es nicht dazu.
Daß der CF das macht ist ihm positiv anzurechnen, der eibPC kämpft ja noch mit dem Passwort und hätte andernfalls keine Chance zu antworten -> timeout nach 3 sek.

[saft6luck]

Ich muss mal nachfragen, ob noch etwas unklar ist oder schon eine Lösung existiert.
Für mich schaut es nachvollziebar aus, aber wenn es trotzdem noch ein Logfile von mir braucht, müsste ich wissen wo noch Fragen offen sind.

[enertegus]

Ich muss mal nachfragen, ob noch etwas unklar ist oder schon eine Lösung existiert.
Für mich schaut es nachvollziebar aus, aber wenn es trotzdem noch ein Logfile von mir braucht, müsste ich wissen wo noch Fragen offen sind.

Die Kollegen werden sich das in den nächsten Tagen auf der FW Seite anschauen. Das iPad hab ich nun schon auf 8.1 ge-updated und dann wird auch der aktuelle CF Client neu drauf gesetzt. Dann schaumer mal, wo die Probleme liegen, ob beim CF oder EibPC oder igrendwo in der Mitte.
Bei der Entwicklung der Markolib konnte ich damals jedenfalls keine 20-Sekunden connect Probleme beobachten. Ist das bei Dir schon immer der Fall?

[saft6luck]

Bei der Entwicklung der Markolib konnte ich damals jedenfalls keine 20-Sekunden connect Probleme beobachten. Ist das bei Dir schon immer der Fall?

Jein, war schon immer ein Problem. Anfangs war noch ein Bug beim Init drinnen, der regelmäßig den Reconnect blockiert hat. Nachdem ich das gefixt hatte, ging es besser, nur ab und an ging es nicht gleich. Gefühlt geht es mit der 3.x schlechter und daher habe ich mich damit intensiver beschäftigt.

Belegen kann ich es also erst seit der 3.x.

Jetzt sind die Zeiten im Makro optimiert und da fällt es stark auf, wenn es mal nicht gleich geht.

[KNXFan1970]

Die Kollegen werden sich das in den nächsten Tagen auf der FW Seite anschauen. Das iPad hab ich nun schon auf 8.1 ge-updated und dann wird auch der aktuelle CF Client neu drauf gesetzt. Dann schaumer mal, wo die Probleme liegen, ob beim CF oder EibPC oder igrendwo in der Mitte.
Bei der Entwicklung der Markolib konnte ich damals jedenfalls keine 20-Sekunden connect Probleme beobachten. Ist das bei Dir schon immer der Fall?

Gibt es hier schon Neuigkeiten?
Sorry - ist überhaupt nicht böse gemeint, aber seit Wochen lese ich hier, dass ihr euch das bei enertex "in den nächsten Tagen" ansehen wollt. Leider ist bisher dort scheinbar nix passiert. Das finde ich einfach schade...

[enertegus]

Leider ist bisher dort scheinbar nix passiert. Das finde ich einfach schade...

nun, die Kollegen arbeiten die Liste ab, das steht schon drauf. Allerdings weiss man vorher nie, was wie lange dauert.

[enertegus]

Was auch immer das Problem ist, wir wollen das nun mal genauer eingrenzen. Dazu ist es sehr hilfreich, wenn wir das Problem auf die minimale Konfiguration herunterbrechen können.
Der Verbindungsaufbau wird ja nur mit dem Basismakro CommandFusion(Name,IPSender, Pass) hergestellt.
Daher benötigt man noch nicht mal GAs etc.
Wir wollen daher so anfangen, dass wir dem EibPC nur dieses eine Makro zur Verfügung stellen. Ein PC, welcher die Verbindungsanfrage initiiert, soll das iPad simulieren. Hier können wir sicher stellen, dass der PC sich ordentlich verhält.
Das macht natürlich nur Sinn, wenn Ihr das Problem beim Aufbau der Verbindung gleichermaßen in einer Minimalkonfiguration nachvollziehen könnt. Falls nicht, können wir Schritt für Schritt diese Konfiguration erweitern, bis der Übeltäter ans Licht kommt. Daher die Frage: Wie ist dass in diesem Fall bei Euch, klappt es dann?

[saft6luck]

Was auch immer das Problem ist, wir wollen das nun mal genauer eingrenzen. Dazu ist es sehr hilfreich, wenn wir das Problem auf die minimale Konfiguration herunterbrechen können.
Der Verbindungsaufbau wird ja nur mit dem Basismakro CommandFusion(Name,IPSender, Pass) hergestellt.
Daher benötigt man noch nicht mal GAs etc.
Wir wollen daher so anfangen, dass wir dem EibPC nur dieses eine Makro zur Verfügung stellen. Ein PC, welcher die Verbindungsanfrage initiiert, soll das iPad simulieren. Hier können wir sicher stellen, dass der PC sich ordentlich verhält.
Das macht natürlich nur Sinn, wenn Ihr das Problem beim Aufbau der Verbindung gleichermaßen in einer Minimalkonfiguration nachvollziehen könnt. Falls nicht, können wir Schritt für Schritt diese Konfiguration erweitern, bis der Übeltäter ans Licht kommt. Daher die Frage: Wie ist dass in diesem Fall bei Euch, klappt es dann?

Das muss man dann aber mit WireShark tracen, denn Probleme wird man am CF nicht sehen. Es passiert ja nichts sichtbares.

Wenn man nur obiges Makro verwendet, sollte der eibPC auf die Passwort-Anfrage direkt (im Rahmen der Zykluszeit) antworten.

Meine Traces zeigen aber, dass diese Antwort verzögert kommt. Indiz bei längeren Verzögerungen ist der Heartbeat vom CF, der dann eingefügt wird.

Die restlichen Makros verursachen höchstens noch Glitches auf falschen Ports, die man so natürlich raus bekommt, nur sieht man dann am CF auch keine Reaktionen auf den Connect -> man kann nichts beurteilen.

Was man also machen muss, ist: den CF verbinden und dann eine Möglichkeit finden, um die Verbindung anzuzeigen, z.B. zählende Variable anzeigen.

Worauf es ankommt: die Zeit bis zur Antwort auf das Passwort prüfen, dann den Test wiederholen.

Für den Reconnect im CF den Init bei Standby aktivieren, dann kann man die Tests durch Homebutton und App auswählen auslösen.

[enertegus]

Das muss man dann aber mit WireShark tracen, denn Probleme wird man am CF nicht sehen. Es passiert ja nichts sichtbares.

Hmm, kommt da nicht mal ein "keine Verbindung möglich?

Wenn man nur obiges Makro verwendet, sollte der eibPC auf die Passwort-Anfrage direkt (im Rahmen der Zykluszeit) antworten.

Wenn dem so ist, wo vermutest Du das Problem? Dann also nicht beim Connect, dann macht es ja auch wenig Sinn, diesen zu checken, oder?

Für den Reconnect im CF den Init bei Standby aktivieren, dann kann man die Tests durch Homebutton und App auswählen auslösen.

OK, muss ich mal schauen, wie das zu machen ist.

[saft6luck]

Hmm, kommt da nicht mal ein "keine Verbindung möglich?

Man kann einen (internen) Join auf den Connect machen (-> Button -> Status wird angezeigt), der gilt aber auf TCP/IP-Ebene. Auf der Protokoll-Ebene wird dann das Passwort gesendet und die Antwort empfangen.

Ohne weitere Joins wird aber nicht mehr passieren.

Sollte auf Protokoll-Ebene keine Verbindung möglich sein, wird auf einem neuen Port weiter versucht.

Angezeigt wird nur etwas, wenn man ein p=nok schickt.

Wenn man nur obiges Makro verwendet, sollte der eibPC auf die Passwort-Anfrage direkt (im Rahmen der Zykluszeit) antworten.

Wenn dem so ist, wo vermutest Du das Problem? Dann also nicht beim Connect, dann macht es ja auch wenig Sinn, diesen zu checken, oder?

Das hatte ich als Erwartungswert gemeint. Der eibPC "sollte" im Rahmen der Zykluszeit das p=ok schicken. Er macht es aber nicht (oder nur selten) (obwohl das Passwort schon empfangen wurde und die Antwort auch schon generiert wurde).

IMHO ist das Problem auch nicht im Makro zu suchen, sondern bei der Verarbeitung von TCP-Verbindungen mit wechselnden Ports.

Den Connect anschauen ist schon richtig, man sieht das Problem ohne WireShark aber nicht ohne ein paar Joins.
Man könnte z.B. eine Zählvariable schicken oder die Zeit und die anzeigen. CF zu beobachten ist aber sehr ungenau.

[KNXFan1970]

Was auch immer das Problem ist, wir wollen das nun mal genauer eingrenzen.

Das klingt gut - sag, wenn ich irgendetwas tun, testen etc. soll.

[enertegus]

Das hatte ich als Erwartungswert gemeint. Der eibPC "sollte" im Rahmen der Zykluszeit das p=ok schicken. Er macht es aber nicht (oder nur selten) (obwohl das Passwort schon empfangen wurde und die Antwort auch schon generiert wurde).
IMHO ist das Problem auch nicht im Makro zu suchen, sondern bei der Verarbeitung von TCP-Verbindungen mit wechselnden Ports.

Nun wir haben hier seit ca. 2 Jahren eine CF-Demo am Laufen mit dem iPad. Das Problem des Re-connects habe ich da noch nicht "gefühlt" beobachtet. Immerhin lief die Demo auch 1 Woche bei der L&B durch. Daher war ich da immer eher widerwillig was zu untersuchen, da es damit augenscheinlich pefekt funktioniert hat. Dies hätte dann auf ein Problem beim CF hingewiesen, aber um das zu finalisieren, werde ich das nochmals genauer anschauen/tracen.

Ich möchte die alte Demo auch erst anfassen, wenn ich sicher bin, dass im EibPC was scheps läuft bzw. wenn da nicht, wo der Unterschied liegt.

Mein Ansinnen war eben, die Kommunikation mit einem PC nachzustellen, um gezielt ansetzen zu können. Es kann schon sein, dass wechselnde Ports den Ablauf erheblich stören. Der EibPC ist da ja der TCP Server, daher macht jeder neue Port auch einen neuen Socket auf. Das darf dann auch etwas brauchen oder vieleicht sind dann soviele offen, dass das Linux erst mal wartet, bis es eine neue Anfrage abarbeitet. Nach 30 Sekunden ohne Anfrage, schließt der Socket im EibPC automatisch. Vielleicht hängen da die Sekunden, die zu beobachten sind.

Das klingt gut - sag, wenn ich irgendetwas tun, testen etc. soll.

Wie oben beschrieben, das Programm abspecken (nur das Basismarko) und am besten wieder mit Wireshark aufzeichnen, wenn Du einen entsprechenden Switch hast.