Systemstart und sendtcp()

[enertegus]

Bei der Analyse die Ports beachtet? Sieht nicht so aus.

Wie? Sieht man doch am Bild, oder meinst Du was anderes? Siehe auch oben den Filter.
Der EibPC beachtet ja eh nur was auf 4809 am ihn geschickt wird.

Der CF darf weitere Daten schicken, der "Server" authentifiziert und wenn das OK nicht rechzeitig kommt, wird der CF neu starten.

Damit die Verbindung zustanden kommen kann, muss der EibPC das OK schicken. Wenn schon nach 18ms nach Passwortanfrage bereits Daten kommen, stört das aber sicher das Makro.

Der Server darf die Daten bei fehlgeschlagener Authentifizierung natürlich verwerfen.

Ja, aber wenn dann der Eingangspuffer voll läuft, muss der EibPC doch erst schauen, was da drin steht. Daher dauert dann die Anmeldung sicher länger.

Wieso ist der Abbruch der Übertragung "spezifikationskonform"?

Weil der EibPC nicht während einer laufenden Übertragung der Zustände (das sind die 250 Nachrichten nach dem OK) wieder mit dem Passwort befragt werden darf. Dann müssen nämlich lt. Protokoll die Zustände der Joins neu geschicht werden - so war das mal. GGf. ist das aber auch geändert oder man könnte es hier vereinfachen. Grundsätzlich wird CF schon alle Joins initialisieren müssen.

Welche Version des CFs setzt ihr denn ein, die es "richtiger" macht?

Das muss was uraltes sein. Ist halt seit Jahren auf dem iPad.

Das Problem, dass der Aufbau der Verbindung leider 1-30!!! Sek dauern kann, ist das eigentliche Übel, nicht die beschriebenen "Mängel", denn die kann man ja alle abfangen.

Die 30 Sekunden sicher dann, wenn die Warteschlange "vollgemüllt" wird.
Von der EibPC Seite aus, kann man ggf. die eigene Sendewarteschlange löschen (was lt. meiner Erinnerung nicht gemacht wurde). Ggf. würde da sich was verbessern. KNX-User-Forum - Enertex EibPC und Command Fusion erklärt das prinzipielle Vorgehen. Ich bin der Meinung, dass da auf der CF Seite was scheps läuft. Wieso wird nicht gewartet, bis der EibPC antwortet.
Mittlerweile kann man auch das Protokoll umdefinieren. Nicht dass da was falsch konfiguriert wurden. Man muss das auf den Standard lassen - inkl. Heartbeat.

[saft6luck]

Wie? Sieht man doch am Bild, oder meinst Du was anderes? Siehe auch oben den Filter.
Der EibPC beachtet ja eh nur was auf 4809 am ihn geschickt wird.

Kurz: Das ist TCP, da wird EIN Port für die Kommunikation verwendet. Wenn du das nicht beachtest ist die Analyse wertlos.


Zum Rest: Das Makro kann man fixen, die lange Zeit für den Verbindungsaufbau muss man im EibPC fixen, die ist nicht normal.

Inhaltlich: Der CF bekommt die Antwort nicht, daher schickt er ein alive und verwirft dann den Verbindungsaufbau. Er startet einen neuen Versuch am NEUEN Port.

[enertegus]

Kurz: Das ist TCP, da wird EIN Port für die Kommunikation verwendet. Wenn du das nicht beachtest ist die Analyse wertlos.

Die Sendeports des iPad interessieren überhaupt nicht. M.W. sind die auch nicht spezifiziert. Nur der Empfangsport 4809 im EibPC muss stimmen und der stimmt.
Das Makro überprüft auch nicht die Senderports des iPad.

Zum Rest: Das Makro kann man fixen, die lange Zeit für den Verbindungsaufbau muss man im EibPC fixen, die ist nicht normal.

Weil das iPad da Nachrichten zwischenschiebt. Das ist doch im Wiresharklog mehr als offensichtlich. Warum soll das dann ein Problem im EibPC sein?
Zudem ist ja der EibPC der TCP Server. Bis die erste Text-Nachricht ausgetauscht wird, wird da auf der unteren Ebene schon was hin und her geschoben. Auch das braucht Zeit (ich habe das nun nicht genauer angeschaut, wer da für was wie lange braucht, schau ich gerne später).

Inhaltlich: Der CF bekommt die Antwort nicht, daher schickt er ein alive und verwirft dann den Verbindungsaufbau. Er startet einen neuen Versuch am NEUEN Port.

Ja wegen mir am Anfang (wobei eben überhaupt nicht die Antwort abgewartet wird). Aber ab Paket ca. 250 bekommt der die Antwort richtig und der EibPC schickt über 10 Sekunden 200 Nachrichten hin. Dann mag aber CF/iPad nicht mehr und startet die Verbindung neu.

[enertegus]

Auch das braucht Zeit (ich habe das nun nicht genauer angeschaut, wer da für was wie lange braucht, schau ich gerne später).

Anbei noch der Auszug aus dem Protokoll inkl. der ACKs auf der unteren TCP Ebene. Der EibPC antwortet da stets innerhalb von 0,5 -1 ms.

[saft6luck]

Die Sendeports des iPad interessieren überhaupt nicht.

kurz: der sendeport ist der wesentliche port für die kommunikation auf dieser tcp-verbindung. falscher port= andere verbindung! darum merkt sich das makro diesen port ja auch!

wenn du das nicht beachtest ist die analyse sinnfrei.

-> verbindungsorientiert analysieren und so die aktionen des cfs richtig deuten und verstehen.

dann können wir weiter fachsimpeln

[enertegus]

kurz: der sendeport ist der wesentliche port für die kommunikation auf dieser tcp-verbindung. falscher port= andere verbindung! darum merkt sich das makro diesen port ja auch!

Ah, jetzt hab ich dich. Aber warum wechselt das iPad munter den Port? Welche andere Verbindungen wollen denn auf den EibPC was schicken und warum? Das bleibt das Geheimnis von CF.
Bisher schickt das Makro die Daten zurück an den Port, von dem es kommt (bezogen auf die p=CF Anfrage).

wenn du das nicht beachtest ist die analyse sinnfrei.

[OT: Kannst Du Dich bitte um etwas Freundlichkeit bemühen?]
Du willst mir sagen, dass es völlig ok ist, dass CF bei einer bestehenden Clientverbindung munter die Ports durchwechselt? Naja, aber das ist beim ersten Versuch noch nicht mal das Problem:
CF meldet sich jedenfalls mit Port 51874 (in Log) und der EibPC antwortet schön brav darauf.
Es steht im Log, dass das iPad auch nach der Anfrage des Passworts bereits auf diesen Port Joins sendet, bevor überhaupt der EibPC was tut. Ich kann Dir auch gerne den Wiresharkmittschnitt schicken.
Nun wäre aus meiner Sicht mal eine Frage an den OP: Wie ist das CF überhaupt eingestellt? Wir haben lt.http://www.commandfusion.com/docs/Co...anual-v1.3.pdf in jedem Fall die Control System Protocoll Type.
Da heisst es auch

Once  the  password  has  been  authenticated,  the  Viewer  will send  the  following initialization  message:
i=1h03

Fakt ist aber, dass das p=ok nicht abgewartet wird und i=1 ebenso nicht gesandt wird, es kommt hingegen nur ein d311=0. Also stimmt das nicht.
Und das auch auf dem selben Port. Das dann weiter unten noch anderes Ports beteiligt sind, ist ein weiteres Problem.

[saft6luck]

Ah, jetzt hab ich dich. Aber warum wechselt das iPad munter den Port?

weil er einen neuen versuch startet, ansonsten würde er den port weiter verwenden.

die anleitung sagt nicht, dass "nur" ein alive folgen wird, sondern dass die verbindung nicht ständig authentifiziert wird. es reichen dann alives.

[edit: es ging ums init: bei mir schickt er immer ein init, wenn dies so konfiguriert wurde (siehe standby/disconnect)]

es steht in der anleitung, dass der cf seine anfragen bündeln darf/kann/wird und der server dies beachten muss.

wenn du die kommunikation nun verbindungssorientiert analysiers, wirst du sehen, dass dem cf die erste antwort nicht gefällt. entweder ist es nicht das p=ok oder es dauert schlicht zu lange, bist es rausgeht. ersteres habe ich gefixt, zweiteres passiert leider regelmäßig.

bzgl. ot, sorry, so war das nicht gemeint!

[KNXFan1970]

Analyse
.... Ich würde mal beim Support von Command Fusion mit diesem Log vorstellig werden. Vielleicht kann ein Update von CF helfen (?) oder man kann im CF-Manager was einstellen.
Wir haben hier eine ältere CF-Version am Laufen, die macht das zumindest so, wie sie es soll....

Hallo enertegus,

vielen Dank erst einmal für die Analyse des wireshark-Files. Leider hilft mir deine Analyse noch nicht so richtig weiter, aber das liegt wohl an der Komplexität des Themas.

Was mich verwundert ist, dass du generell auszuschließen scheinst, dass der TCP-Verbindungsaufbau mit dem eibPC teilweise sehr lange - manchmal über 10 sek dauert. Dies wurde hier im Forum schon öfter angesprochen, aber wird scheinbar von euch für völlig ausgeschlossen gehalten - zumindest macht es den Eindruck.

Bevor ich mich mit meinem Mitschnitt an den Support von CF wende, wäre es hilfreich, wenn ihr mal von der - von euch bisher eingesetzten älteren - CF-Version auf die neueste Version wechseln könntet. Dann könnte man zumindest sehen, ob sich dort CF auch anders verhält als bei älteren Versionen - also ob ein generelles Problem in der Kommunikation mit den eibPC-Makros vorliegt.
Wäre das möglich?

Gruß Frank

[enertegus]

die anleitung sagt nicht, dass "nur" ein alive folgen wird, sondern dass die verbindung nicht ständig authentifiziert wird. es reichen dann alives.
es steht in der anleitung, dass der cf seine anfragen bündeln darf/kann/wird und der server dies beachten muss.

das sollte beides kein Problem sein. Im Protokollmitschnitt von oben ist aber klar erkenntlich, dass das iPad schon nach 18 ms eine Anfrage eines Buttons schickt. Ich denke da schon müsste man das Makro anpassen, wenn das möglich sein soll.
Zudem steht klar
"Once the password has been authenticated, the Viewer will send the following initialization message"
d.h. CF muss mit einer weiteren Nachricht warten, bis die Verbindung bestätigt wurde. Dann muss die Initialisierung erfolgen, dann erst kommen Stati vom iPad.
Wenn das schon nicht stimmt, braucht man doch hier erst gar nicht weiter suchen. Und wenn CF da munter auf unterschiedlichen Ports an das gleiche Gerät funkt, stimmt da einfach was nicht.

wenn du die kommunikation nun verbindungssorientiert analysiers, wirst du sehen, dass dem cf die erste antwort nicht gefällt. entweder ist es nicht das p=ok oder es dauert schlicht zu lange, bist es rausgeht. ersteres habe ich gefixt, zweiteres passiert leider regelmäßig.

im vorliegenden Fall aber nicht, und das ist es ja, worum es dem Poster geht. Alle anderen Fälle müssten wir halt erst mal sehen, bevor ich sagen kann, es liegt hier oder dort.

Was mich verwundert ist, dass du generell auszuschließen scheinst, dass der TCP-Verbindungsaufbau mit dem eibPC teilweise sehr lange - manchmal über 10 sek dauert. Dies wurde hier im Forum schon öfter angesprochen, aber wird scheinbar von euch für völlig ausgeschlossen gehalten - zumindest macht es den Eindruck.

Nun, normal wäre es nicht. In Deinem Fall/Log ist es aber sicher nicht das Problem.
Kannst Du klären, welche Konfiguration genau Du im guiDesigner eingestellt hast?
Kannst Du auch nochmal genau beschreiben, wie der Log zu stande kam? Also Öffnen, Schlafen legen etc. etc.
Ggf. fehlt da was Entscheidendes im Log oder das Verhalten beim Schalfen legen ist anders etc. etc.
Das einzige, was ich mir hier denken kann, ist, daß irgendwie mehrere Verbindungen aufgemacht wurden, die nicht sauber beendet wurden. Dann können diese Zombies ggf. den TCP-IP Verkehr im EibPC ausbremsen. Aber das ist nun eher Raten, da man die gesamte Historie sehen muss.

[KNXFan1970]

Kannst Du klären, welche Konfiguration genau Du im guiDesigner eingestellt hast?
Kannst Du auch nochmal genau beschreiben, wie der Log zu stande kam? Also Öffnen, Schlafen legen etc. etc.
Ggf. fehlt da was Entscheidendes im Log oder das Verhalten beim Schalfen legen ist anders etc. etc.
Das einzige, was ich mir hier denken kann, ist, daß irgendwie mehrere Verbindungen aufgemacht wurden, die nicht sauber beendet wurden. Dann können diese Zombies ggf. den TCP-IP Verkehr im EibPC ausbremsen. Aber das ist nun eher Raten, da man die gesamte Historie sehen muss.

...ich werde noch einmal ein neues Log schreiben lassen. Vorher nehme ich alle JavaScripts aus dem CF raus. Also zumindest die, die Verbindung ins Netz halten/suchen, um z.B. Wetterinformationen zu ziehen.
Zusätzlich schicke ich dir die Einstellungen im guiDesigner, wobei hier ja nicht viel eingestellt werden kann (zumindest aus meiner Sicht). Wäre nett, wenn du dann noch mal drüber schauen könntest. Danke schon mal...

Gruß Frank

[saft6luck]

das sollte beides kein Problem sein. Im Protokollmitschnitt von oben ist aber klar erkenntlich, dass das iPad schon nach 18 ms eine Anfrage eines Buttons schickt. Ich denke da schon müsste man das Makro anpassen, wenn das möglich sein soll. [..]Wenn das schon nicht stimmt, braucht man doch hier erst gar nicht weiter suchen. Und wenn CF da munter auf unterschiedlichen Ports an das gleiche Gerät funkt, stimmt da einfach was nicht.

Das Makro benötigt doch kein "Init" vom CF. Es geht nur darum, dass die erste Antwort des Servers das "p=ok" sein muss, ansonsten versucht der CF einen neuen Verbindungsaufbau (natürlich auf einem neuen Port). Ob der CF schon weitere Anfragen schickt, oder nicht, ist nicht festgelegt und er macht es sicherlich auch nur, um schnell zu sein.

im vorliegenden Fall aber nicht, und das ist es ja, worum es dem Poster geht. Alle anderen Fälle müssten wir halt erst mal sehen, bevor ich sagen kann, es liegt hier oder dort.

Ist aber seltsam, das der CF wild auf unterschiedlichen Ports kommunizieren will. Kannst du (oder Frank) mir das Log-File schicken? Bei mir geht das exakt nach Vorgabe (wobei das Init nur kommt, wenn es auch konfiguriert wurde).

Ich erstelle die Tage mal ein paar Log-Files mit meinem CF-Makro, um die Connect-Probleme zu zeigen.

[KNXFan1970]

Ist aber seltsam, das der CF wild auf unterschiedlichen Ports kommunizieren will. Kannst du (oder Frank) mir das Log-File schicken? Bei mir geht das exakt nach Vorgabe (wobei das Init nur kommt, wenn es auch konfiguriert wurde).

Ja Marc - ich schicke dir das Log-File nachher via eMail rüber. Aber ich schreibe auch noch einmal ein neues am Wochenende, dann allerdings mit deinen Makros. Ich vereinfache auch die Javascript-Programmierung am CF, um Fehlinterpretationen zu vermeiden. Zum Beispiel ist d311=0 (siehe oben) aus meiner Sicht das Ergebnis von CF.setJoin("d311",0); in der Funktion CF.userMain, die beim Start der CF-App ausgeführt wird (d311 wird nur intern in der CF-App genutzt) - kann man natürlich nicht wissen, wenn man nur das Log-File hat.
Mein Fehler.

[saft6luck]

Ja Marc - ich schicke dir das Log-File nachher via eMail rüber.

Im Log-File sieht man:

1. Connect (183-240, Port 51874): der eibPC schickt im ersten Connect (Port 51874) 20 sek lang kein einziges Paket an den CF.
   Der CF wiederum schickt in dieser Zeit erst das Passwort, dann ein paar Daten, dann alle 4 - 6 sek ein Alive und dann beendet er die Verbindung.
2. Connect (241-551, Port 51876): hier schickt der CF das Passwort, ein Alive und erhält nach 5 sek das p=ok. Ab hier kommt dann das init und alles sieht gut aus.
3. Connect (552-823, Port 51878): Neue Verbindung, der CF fängt wieder mit Passwort und Alive an, dann schickt der eibPC aber eine Antwort (a205=0) an Port 51876 (->Fehler) und beendet die alte Verbindung auf Port 51874(!!!). p=ok kommt hier nach 3 sek und alles läuft gut weiter.
4. Connect (824-1152, Port 51879): Neue Verbindung, CF schickt Passwort und erhält das p=ok nach 400 ms. Dazwischen schickt der eibPC noch ein ACK und d3105=1 an Port 51878. Rest ok.
5. Connect (1153-, Port 51881): Neue Verbindung, CF schickt Passwort und erhält das p=ok nach 4 sek. Dazwischen schickt der eibPC noch ein ACK und s333=geschlossen an Port 51879. Rest ok.

...
Geht so noch mehrmals weiter. Im Querlesen habe ich bis zu 8 sek Delay gesehen.

Für mich macht der CF alles richtig. Beim 1. Connect könnte man evtl. streiten, aber auch hier sollte das p=ok kommen, es sollte ja immerhin vorne in der Schlange stehen.

[enertegus]

Sorry, war anderweitig unterwegs. Hab mir das nochmal angesehen:

Im Log-File sieht man:
Connect (183-240, Port 51874): der eibPC schickt im ersten Connect (Port 51874) 20 sek lang kein einziges Paket an den CF.
CF wiederum schickt in dieser Zeit erst das Passwort, dann ein paar Daten, dann alle 4 - 6 sek ein Alive und dann beendet er die Verbindung.

Der EibPC beantwortet auf der TCP/IP Ebene die Telegramme wohl innerhalb von 20..40 ms (Pakte 185,187 usw.). Muss ja auch so sein, auf dieser Ebene ist der EibPC der TCP Server.
Daneben scheint das iPad auch noch über andere Ports an den EibPC zu senden, das sind die Daten, von denen Du schreibst. Nun mag man sich über "ein paar Daten" streiten. [Irgendwie reden wir immer ein wenig aneinander vorbei, habe ich den Eindruck].
Aber wir haben ja im Makro eine Zustandsmaschine, die kann empfindlich gestört werden. Schließlich steht im Makro

if event(readtcp(Name_SenderPort,Name_SenderIPC,Name_Message)) and (IPSender==0u32 or Name_SenderIPC==IPSender) then

d.h. das Senden auf einem unterschiedlichen Port (wie Du meinst eine "andere" Verbindung") wird hier gar nicht beachtet.
Mir ist aber auch rätselhaft, ob das denn überhaupt so sein kein -da kenn ich mich mit dem CF und dem darunterliegenden Design nicht aus. Der EibPC antwortet auch immer auf den Port, auf dem das CF die Passwortanfrage gestartet hat. Seinerzeit, als ich das Makro entwickelt habe, ging das jedenfalls so. In der Definition habe ich dazu auch nichts anders Lautendes finden können.
Problematisch könnte nun werden, wenn hier in der Messageque viele Nachrichten reingekommen sind, die nicht mehr abgearbeitet wurden, oder den TCP Server auf der unteren Ebene vollmüllen. Man könnte da das Problem der langen Antwortzeit vermuten - das Makro verarbeitet pro Durchlauf genau 1 Anweisung.
Dieser Initialisierungsprozess muss sauber und verstanden sein und solange das nicht der Fall ist, braucht man an anderer Stelle nicht suchen, das ist zumindest meine Erfahrung im Softwarebereich.

Für mich macht der CF alles richtig. Beim 1. Connect könnte man evtl. streiten, aber auch hier sollte das p=ok kommen, es sollte ja immerhin vorne in der Schlange stehen.

Nein, es wird an die Schlange hinten angefügt. Was sagt denn CF dazu? Haben die sich schon mal geäußert?
Das p=ok kommt auch, aber eben erst als Antwort auf T244 in T250. Aber auch hier sind irgendwelche Anfragen an den EibPC auf einen anderen Port dazwischen (T248) und schickt auf der TCP Pakete noch weitere ACK.
Erstaunlicherweise erkennt man, dass das iPad ein ACK auf einen Heartbeat der eigentlich schon bestehenden Verbindung in T240 und dann doppelt in T247 verschickt.
Ich helfe hier gerne, aber es muss schon klar sein, dass man sich erst mal um dieses Problem bei der Initialisierung kümmern muss. Ich komme leider nicht vor in 2 Wochen dazu, hier mal ein CF auf ein iPad zu aktualisieren, um das nachzuvollziehen. In jedem Fall muss der Connect-Zyklus sauber sein.
Vielleicht sollte man das Makro anschließend so erweitern: Falls eine TCP Anfrage von einem anderen Port als der bestehenden Verbindung kommt, die Messagequeue löschen und ab diesem Telegramm neu aufbauen.

[saft6luck]

Der EibPC beantwortet auf der TCP/IP Ebene die Telegramme wohl innerhalb von 20..40 ms (Pakte 185,187 usw.). Muss ja auch so sein, auf dieser Ebene ist der EibPC der TCP Server.

Ja, auf der TCP-Ebene zeigt das Logging, dass da anfangs alles ok ist.

Auf der Daten-Ebene aber leider nicht, denn es werden in der ersten Verbindung z.B. keine Daten an den CF gesendet. Und auch später vergeht viel zu viel Zeit, bis nach dem Passwort die Antworten kommen.

Daneben scheint das iPad auch noch über andere Ports an den EibPC zu senden, das sind die Daten, von denen Du schreibst.

Du musst das Logging nach der IP des CFs filtern, also "ip.addr==192.168.0.6". Andere Verbindungen, als die oben aufgeführten, sehe ich nicht. Beim Übergang gibt es häuftiger ein "Durcheinander", welches vom eibPC verursacht wird - auf einer geschlossenen Verbindung sollte/braucht man nicht zu kommunizieren - die Ports waren aber alle bereits in Verwendung.

Nun mag man sich über "ein paar Daten" streiten. [Irgendwie reden wir immer ein wenig aneinander vorbei, habe ich den Eindruck].
Aber wir haben ja im Makro eine Zustandsmaschine, die kann empfindlich gestört werden. Schließlich steht im Makro

if event(readtcp(Name_SenderPort,Name_SenderIPC,Name_Message)) and (IPSender==0u32 or Name_SenderIPC==IPSender) then

d.h. das Senden auf einem unterschiedlichen Port (wie Du meinst eine "andere" Verbindung") wird hier gar nicht beachtet.

Hier muss man aber das ganze Makro betrachten. Wo und wann Name_SenderPort dann für die Antwort verwendet wird und wie der Timeout bzw. ein neues Passwort behandelt wird, ist entscheidend. Hier ist sicherlich das Problem mit den "Überlappenden" Ports zu sehen.

Nur der Teil mit dem neuen Passwort speichert den Port und antwortet direkt auf die Anfrage. Warum das dann trotz aktivem Connect nicht raus geht ist die Frage.

Mir ist aber auch rätselhaft, ob das denn überhaupt so sein kein -da kenn ich mich mit dem CF und dem darunterliegenden Design nicht aus. Der EibPC antwortet auch immer auf den Port, auf dem das CF die Passwortanfrage gestartet hat. Seinerzeit, als ich das Makro entwickelt habe, ging das jedenfalls so. In der Definition habe ich dazu auch nichts anders Lautendes finden können.

Genau so soll es ja auch sein. Nur schnell muss es gehen.

Problematisch könnte nun werden, wenn hier in der Messageque viele Nachrichten reingekommen sind, die nicht mehr abgearbeitet wurden, oder den TCP Server auf der unteren Ebene vollmüllen. Man könnte da das Problem der langen Antwortzeit vermuten - das Makro verarbeitet pro Durchlauf genau 1 Anweisung.

Aus dem Logging könnte man das ja nachprüfen, ob da vorher alle Requests von CF abgearbeitet sind. Ob da noch eine Antwort irgendwo hängt habe ich nicht geprüft, da sind aber oft mehrere Sekunden ohne Kommunikation bzw. nur Alives, bevor dann ein neuer Connect beginnt. Und selbst wenn pro Durchlauf nur eine Antwort raus geht, sind es immer noch Welten wenn Sekundenlang nichts kommt.

Dieser Initialisierungsprozess muss sauber und verstanden sein und solange das nicht der Fall ist, braucht man an anderer Stelle nicht suchen, das ist zumindest meine Erfahrung im Softwarebereich.

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.

Nein, es wird an die Schlange hinten angefügt.

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

Was sagt denn CF dazu? Haben die sich schon mal geäußert?

Bisher hatte ich noch keine Notwendigkeit gesehen, dort wegen dieses Problems anzufragen. Meine Analysen und nun auch die von diesem Logging zeigen eigentlich kein Problem auf der CF Seite.

Das p=ok kommt auch, aber eben erst als Antwort auf T244 in T250. Aber auch hier sind irgendwelche Anfragen an den EibPC auf einen anderen Port dazwischen (T248) und schickt auf der TCP Pakete noch weitere ACK.
Erstaunlicherweise erkennt man, dass das iPad ein ACK auf einen Heartbeat der eigentlich schon bestehenden Verbindung in T240 und dann doppelt in T247 verschickt.

T240: CF schließt die Verbindung auf Port 51874
T241: CF öffnet die Verbindung auf Port 51876
T242: eibPC ACK auf Port 51876 -> Verbindung OK
T243: CF ACK auf Port 51876 -> Verbindung OK

Ab hier ist Port 51876 zu verwenden und wird vom CF verwendet

T244: CF schickt Passwort auf Port 51876
T245: eibPC ACK auf Port 51876
T246: eibPC ACK auf Port 51874 -> erst jetzt wird die alte Verbindung geschlossen (überflüssig?)
T247: CF bestätigt die geschlossene Verbindung auf Port 51874 noch einmal (Antwort auf überflüssiges(?) ACK)
T248: CF schickt Alive, da inzwischen 3 Sek keine Antwort auf das Passwort kam!
T249: eibPC ACK
Delay ~4 sec
T250: eibPC schickt p=ok
T251: CF ACK

Meine Analyse zeigt nur ein überflüssiges ACK und die "notwendige" Bestätigung des CFs

Ich helfe hier gerne, aber es muss schon klar sein, dass man sich erst mal um dieses Problem bei der Initialisierung kümmern muss. Ich komme leider nicht vor in 2 Wochen dazu, hier mal ein CF auf ein iPad zu aktualisieren, um das nachzuvollziehen. In jedem Fall muss der Connect-Zyklus sauber sein.
Vielleicht sollte man das Makro anschließend so erweitern: Falls eine TCP Anfrage von einem anderen Port als der bestehenden Verbindung kommt, die Messagequeue löschen und ab diesem Telegramm neu aufbauen.

Das Makro habe ich schon auf Vordermann gebracht, das Delay bekomme ich aber nicht weg. Meine Vermutung: Hier scheint der Connect auf Linux-Ebene zu funktionieren, die Daten werden aber aus dem Programm heraus nicht richtig verschickt.