eibd(war bcusdk) Fork -> knxd

[timowi]

Das "Telegrammwiederholungs-Problem" dürfte Dank Timo&Co mit https://github.com/Makki1/knxd/tree/...art-duplicates gefixed sein, ich teste noch.. (ja, nur zur Info: das dauert mal 6-8h sowas..)

Ich habe nochmal darüber nachgedacht. Dieser Lösungsversuch könnte zu Telegrammverlust führen. Nach dem Senden wird der Empfang blockiert bis entweder die Sendebestätigung oder ein timeout kommt. Ich denke aber in dieser Zeit könnten auch echte Telegramme vom Bus kommen. Die würden dann auch ignoriert.

EDIT: Das ist ein gutes Beispiel weshalb ich es nicht möchte das Änderungen an "Kernkomponenten" direkt in master commited werden. Ich habe eine einfach erscheinenden Änderung an einer state-machine eingefügt und hätte dadurch einen schwer zu lokalisierenden (timing abhängigen) Bug eingefügt... Der absolute GAU wäre wenn bei sowas ein nicht mehr verlassbarer Zustand erreicht wird.

[do13]

Ich habe nochmal darüber nachgedacht. Dieser Lösungsversuch könnte zu Telegrammverlust führen. Nach dem Senden wird der Empfang blockiert bis entweder die Sendebestätigung oder ein timeout kommt. Ich denke aber in dieser Zeit könnten auch echte Telegramme vom Bus kommen. Die würden dann auch ignoriert.

Genau. Das sehe ich auch so und zusätzlich würdest Du das ursprüngliche trotzdem wieder empfangen

Da wird wohl kein Weg daran vorbeiführen es mit dem letzten zuvor gesendeten aus der inqueue zu vergleichen und wenn der Inhalt (ohne Checksumme) gleich ist zu verwerfen. Oder siehst Du eine andere Möglichkeit?

Dirk

[makki]

Ich habe nochmal darüber nachgedacht. Dieser Lösungsversuch könnte zu Telegrammverlust führen. Nach dem Senden wird der Empfang blockiert bis entweder die Sendebestätigung oder ein timeout kommt. Ich denke aber in dieser Zeit könnten auch echte Telegramme vom Bus kommen. Die würden dann auch ignoriert.

Genau deswegen betrachte ich das auch eher kritisch.. Einzig die perfekte Lösung dafür versteckt sich bei mir noch in der Glaskugel

EDIT: Das ist ein gutes Beispiel weshalb ich es nicht möchte das Änderungen an "Kernkomponenten" direkt in master commited werden.

Wiegesagt: da sind wir im Prinzip d'accord! Und ab jetzt: mind. 4 Augen, wenn eins davon nein sagt, wirds reverted, an oberster Stelle muss Stabilität&Zuverlässigkeit stehen.

Ich war evtl. anfangs etwas euphorisch und überschwänglich, habs aber angenommen: alles sauber in branches, für Experimente ist bei sowas essentiellem wie eibd/knxd (mein eigenes Haus würde tot umfallen!) ganz, ganz wenig Platz.

Makki

[timowi]

Genau. Das sehe ich auch so und zusätzlich würdest Du das ursprüngliche trotzdem wieder empfangen

Das denke ich eher nicht. Ich wieß nicht, ob es dann wirklich mal kommen könnte, halte das aber für sehr unwahrscheinlich. Der Packetverlust dagegen ist nur vom Zufall abhängig.

Da wird wohl kein Weg daran vorbeiführen es mit dem letzten zuvor gesendeten aus der inqueue zu vergleichen und wenn der Inhalt (ohne Checksumme) gleich ist zu verwerfen. Oder siehst Du eine andere Möglichkeit?

Wahrscheinlich läuft es genau da rauf hinaus. Ich möchte mir da aber vorher die Zusammenhänge mal genauer ansehen. Das scheint ja nur beim Routing zu passieren. Zumindest habe ich keinen hinweis das es mit tunneling auch so ist.

[swiss]

Mal ein anderer Gedanke...

Bei KNX kann immer nur einer senden und die anderen müssen in der Zeit still sein und lauschen bis die Leitung wieder frei ist...

Könnte man nicht einfach den Empfangsbuffer im knxd für die Zeit in der auf dem TPUART gesendet wird blockieren? Oder kommt das Echo erst nach dem senden?

[timowi]

Bei KNX kann immer nur einer senden und die anderen müssen in der Zeit still sein und lauschen bis die Leitung wieder frei ist...
Könnte man nicht einfach den Empfangsbuffer im knxd für die Zeit in der auf dem TPUART gesendet wird blockieren? Oder kommt das Echo erst nach dem senden?

Nein. Das echo kommt während des Sendens auf den Bus (Datenblatte Seite 15). Der TPUART hat Sende- und Empfangspuffer. Beispielsituation: Es wird in den Sendepuffer geschrieben. Kurz bevor auf den Bus gesendet wird, kommt ein Telegramm vom Bus. Das geht wahrscheinlich an den Host bevor das eigene gesendet wird und würde mit der Änderung ignoriert...

Wiegesagt: da sind wir im Prinzip d'accord! Und ab jetzt: mind. 4 Augen, wenn eins davon nein sagt, wirds reverted, an oberster Stelle muss Stabilität&Zuverlässigkeit stehen.

Ich war evtl. anfangs etwas euphorisch und überschwänglich, habs aber angenommen: alles sauber in branches, für Experimente ist bei sowas essentiellem wie eibd/knxd (mein eigenes Haus würde tot umfallen!) ganz, ganz wenig Platz.

Ja. Das schlimmste wäre ein knxd den zufällig nach zu 40 Tagen Telegramme verliert... Das ist fast unmöglich zu testen und zu Debuggen.

Ich finde mit der momentanen Situation ist es sehr schwer zu verfolgen, ob jemand ein commit in die wichtigen Dateien gemacht hat.

Also dann folgendermaßen?:
Alles was in die Verzeichnisse
backend common libserver server usb
geht nur per branch mit review. Alles direkten commits werden ohne Rechtfertigung rückgängig gemacht. Bitte auch bei reinen Kommentaren und Umbenennungen. Ich habe es leider schone erlebt das bei so "einfachen" Änderungen irgendwo eine Klammer verschoben wurde, ein break, continue oder ähnliches irgendwo aufgetaucht ist.

Ich weiß das es nervig ist Änderungen kompakt zu halten und code reviews sind auch langweilig. Leider ist es aber viel zu einfach Fehler einzufügen.

Auch sollten wir uns mal Gedanken machen, wie wir das planen und koordinieren. Wenn jeder einfach irgendwo "hackt" wird das eher nichts. Ich würde gerne einige Teile (z.B. das cemi/emi... handling) kapseln (einiges scheint eher aus einem C Projekt) und dann auch Tests für schreiben.

[Tru]

Ich weiß das es nervig ist Änderungen kompakt zu halten und code reviews sind auch langweilig. Leider ist es aber viel zu einfach Fehler einzufügen.

Tja, könnte es sein, dass Fehler bereits passiert sind? Jedenfalls lässt sich bei mir der Master Branch nicht mehr kompilieren. Habe dazu einen Issue eröffnet.
Könnte das jemand überprüfen?

Gruss, Othmar

[do13]

Ich möchte mir da aber vorher die Zusammenhänge mal genauer ansehen. Das scheint ja nur beim Routing zu passieren. Zumindest habe ich keinen hinweis das es mit tunneling auch so ist.

So, habe mal geschafft meine Testumgebung aufzusetzen. Das ist die knxd version aus dem git (ohne die o.g. Änderung). Zugriff von der ETS5 über den Gruppenmonitor auf den knxd per Routing.
Folgendes zeigt der knxd-log:

Layer 0(02546640,54AEF4CB) Recv(018): 06 10 05 30 00 12 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 1(02546640,54AEF4CB) Recv(012): 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 8(02546160,54AEF4CB) Recv_Route L_Data low from 1.1.0 to 12/7/7 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 3(025253D0,54AEF4CB) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 2(02514C00,54AEF4CB) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 0(02514C00,54AEF4CB) Write(020): 80 BC 81 11 82 00 83 67 84 07 85 D2 86 00 87 80 88 00 49 60
Layer 0(02514C00,54AEF4CB) Recv(001): BC
Layer 0(02514C00,54AEF4CB) Recv(001): 11
Layer 0(02514C00,54AEF4CB) Recv(001): 00
Layer 0(02514C00,54AEF4CB) Recv(001): 67
Layer 0(02514C00,54AEF4CB) Recv(001): 07
Layer 0(02514C00,54AEF4CB) Recv(001): D2
Layer 0(02514C00,54AEF4CB) SendAck 10
Layer 0(02514C00,54AEF4CB) Recv(001): 00
Layer 0(02514C00,54AEF4CB) Recv(001): 80
Layer 0(02514C00,54AEF4CB) Recv(001): 00
Layer 0(02514C00,54AEF4CB) Recv(001): 60
Layer 1(02514C00,54AEF4CB) Recv(010): BC 11 00 67 07 D2 00 80 00 60
Layer 2(02514C00,54AEF4CB) Recv L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 3(025253D0,54AEF4CB) Recv L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 8(02546160,54AEF4CB) Send_Route L_Data low from 1.1.0 to 12/7/7 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 1(02546640,54AEF4CB) Send(012): 29 00 BC C0 11 00 67 07 02 00 80 00
Layer 0(02546640,54AEF4CB) Send(018): 06 10 05 30 00 12 29 00 BC C0 11 00 67 07 02 00 80 00
Layer 0(02514C00,54AEF4CB) Recv(001): 8B
Layer 2(02514C00,54AEF4CD) Watchdog Reset(001): 01
Layer 2(02514C00,54AEF4CD) Watchdog Status(001): 02
Layer 0(02514C00,54AEF4CD) Recv(001): 00
Layer 0(02514C00,54AEF4CD) Remove 00
Layer 0(02514C00,54AEF4CD) Recv(001): 03
Layer 0(02514C00,54AEF4CD) Remove 03

Da ist schön zu sehen wie das Echo als neues Telegramm interpretiert wird.
Und das gleiche per Tunneling:

Layer 0(01270640,54AEF9DF) Recv(024): 06 10 02 05 00 18 08 01 C0 A8 02 27 E9 16 08 01 C0 A8 02 27 E9 17 02 03
Layer 1(01270640,54AEF9DF) Recv(018): 08 01 C0 A8 02 27 E9 16 08 01 C0 A8 02 27 E9 17 02 03
Layer 1(01270640,54AEF9DF) Send(012): 02 00 08 01 C0 A8 02 24 0E 57 02 03
Layer 0(01270640,54AEF9DF) Send(018): 06 10 02 06 00 12 02 00 08 01 C0 A8 02 24 0E 57 02 03
Layer 0(01270640,54AEF9DF) Recv(017): 06 10 03 10 00 11 04 02 00 00 FC 00 00 01 53 10 01
Layer 1(01270640,54AEF9DF) Recv(011): 04 02 00 00 FC 00 00 01 53 10 01
Layer 8(01270160,54AEF9DF) CONFIG_REQ
Layer 1(01270640,54AEF9DF) Send(004): 04 02 00 00
Layer 0(01270640,54AEF9DF) Send(010): 06 10 03 11 00 0A 04 02 00 00
Layer 8(01270160,54AEF9DF) TunnelSend 2
Layer 1(01270640,54AEF9DF) Send(012): 04 02 00 00 FB 00 00 01 53 00 01 00
Layer 0(01270640,54AEF9DF) Send(018): 06 10 03 10 00 12 04 02 00 00 FB 00 00 01 53 00 01 00
Layer 0(01270640,54AEF9DF) Recv(010): 06 10 03 11 00 0A 04 02 00 00
Layer 1(01270640,54AEF9DF) Recv(004): 04 02 00 00
Layer 8(01270160,54AEF9DF) CONFIG_ACK
Layer 0(01270640,54AEF9DF) Recv(014): 06 10 02 03 00 0E 08 01 C0 A8 02 27 E9 16
Layer 1(01270640,54AEF9DF) Recv(008): 08 01 C0 A8 02 27 E9 16
Layer 8(01270160,54AEF9DF) DESCRIBE
Layer 1(01270640,54AEF9DF) Send(062): 36 01 02 00 00 00 00 00 03 02 00 00 87 7F E0 00 17 0C 00 00 00 00 00 00 6B 6E 78 64 74 65 73 74 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 02 02 01 03 01 04 01
Layer 0(01270640,54AEF9DF) Send(068): 06 10 02 04 00 44 36 01 02 00 00 00 00 00 03 02 00 00 87 7F E0 00 17 0C 00 00 00 00 00 00 6B 6E 78 64 74 65 73 74 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 02 02 01 03 01 04 01
Layer 0(01270640,54AEF9DF) Recv(017): 06 10 03 10 00 11 04 02 01 00 FC 00 00 01 38 10 01
Layer 1(01270640,54AEF9DF) Recv(011): 04 02 01 00 FC 00 00 01 38 10 01
Layer 8(01270160,54AEF9DF) CONFIG_REQ
Layer 1(01270640,54AEF9DF) Send(004): 04 02 01 00
Layer 0(01270640,54AEF9DF) Send(010): 06 10 03 11 00 0A 04 02 01 00
Layer 8(01270160,54AEF9DF) TunnelSend 2
Layer 1(01270640,54AEF9DF) Send(012): 04 02 01 00 FB 00 00 01 38 00 01 00
Layer 0(01270640,54AEF9DF) Send(018): 06 10 03 10 00 12 04 02 01 00 FB 00 00 01 38 00 01 00
Layer 0(01270640,54AEF9DF) Recv(010): 06 10 03 11 00 0A 04 02 01 00
Layer 1(01270640,54AEF9DF) Recv(004): 04 02 01 00
Layer 8(01270160,54AEF9DF) CONFIG_ACK
Layer 0(01270640,54AEF9DF) Recv(014): 06 10 02 03 00 0E 08 01 C0 A8 02 27 E0 61
Layer 1(01270640,54AEF9DF) Recv(008): 08 01 C0 A8 02 27 E0 61
Layer 8(01270160,54AEF9DF) DESCRIBE
Layer 1(01270640,54AEF9DF) Send(062): 36 01 02 00 00 00 00 00 03 02 00 00 87 7F E0 00 17 0C 00 00 00 00 00 00 6B 6E 78 64 74 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 02 02 01 03 01 04 01
Layer 0(01270640,54AEF9DF) Send(068): 06 10 02 04 00 44 36 01 02 00 00 00 00 00 03 02 00 00 87 7F E0 00 17 0C 00 00 00 00 00 00 6B 6E 78 64 74 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 02 02 01 03 01 04 01
Layer 0(01270640,54AEF9DF) Recv(016): 06 10 02 09 00 10 02 00 08 01 C0 A8 02 27 E9 16
Layer 1(01270640,54AEF9DF) Recv(010): 02 00 08 01 C0 A8 02 27 E9 16
Layer 1(01270640,54AEF9DF) Send(002): 02 00
Layer 0(01270640,54AEF9DF) Send(008): 06 10 02 0A 00 08 02 00
Layer 0(01270640,54AEF9DF) Recv(022): 06 10 04 20 00 16 04 01 00 00 11 00 BC E0 00 00 67 07 02 00 80 00
Layer 1(01270640,54AEF9DF) Recv(016): 04 01 00 00 11 00 BC E0 00 00 67 07 02 00 80 00
Layer 8(01270160,54AEF9DF) TUNNEL_REQ
Layer 3(0124F3D0,54AEF9DF) Send L_Data low from 0.0.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 2(0123EC00,54AEF9DF) Send L_Data low from 0.0.1 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 0(0123EC00,54AEF9DF) Write(020): 80 BC 81 00 82 01 83 67 84 07 85 D2 86 00 87 80 88 00 49 70
Layer 1(01270640,54AEF9DF) Send(004): 04 01 00 00
Layer 0(01270640,54AEF9DF) Send(010): 06 10 04 21 00 0A 04 01 00 00
Layer 8(01270160,54AEF9DF) TunnelSend 1
Layer 1(01270640,54AEF9DF) Send(016): 04 01 0A 00 2E 00 BC D0 00 00 67 07 02 00 80 00
Layer 0(01270640,54AEF9DF) Send(022): 06 10 04 20 00 16 04 01 0A 00 2E 00 BC D0 00 00 67 07 02 00 80 00
Layer 0(01270640,54AEF9DF) Recv(010): 06 10 04 21 00 0A 04 01 0A 00
Layer 1(01270640,54AEF9DF) Recv(004): 04 01 0A 00
Layer 8(01270160,54AEF9DF) TUNNEL_ACK
Layer 0(0123EC00,54AEF9DF) Recv(001): BC
Layer 0(0123EC00,54AEF9DF) Recv(001): 00
Layer 0(0123EC00,54AEF9DF) Recv(001): 01
Layer 0(0123EC00,54AEF9DF) Recv(001): 67
Layer 0(0123EC00,54AEF9DF) Recv(001): 07
Layer 0(0123EC00,54AEF9DF) Recv(001): D2
Layer 0(0123EC00,54AEF9DF) SendAck 10
Layer 0(0123EC00,54AEF9DF) Recv(001): 00
Layer 0(0123EC00,54AEF9DF) Recv(001): 80
Layer 0(0123EC00,54AEF9DF) Recv(001): 00
Layer 0(0123EC00,54AEF9DF) Recv(001): 70
Layer 1(0123EC00,54AEF9DF) Recv(010): BC 00 01 67 07 D2 00 80 00 70
Layer 2(0123EC00,54AEF9DF) Recv L_Data low from 0.0.1 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 3(0124F3D0,54AEF9DF) Recv L_Data low from 0.0.1 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 8(01270160,54AEF9DF) TunnelSend 1
Layer 1(01270640,54AEF9DF) Send(016): 04 01 0B 00 29 00 BC C0 00 01 67 07 02 00 80 00
Layer 0(01270640,54AEF9DF) Send(022): 06 10 04 20 00 16 04 01 0B 00 29 00 BC C0 00 01 67 07 02 00 80 00
Layer 0(0123EC00,54AEF9DF) Recv(001): 8B
Layer 0(01270640,54AEF9DF) Recv(010): 06 10 04 21 00 0A 04 01 0B 00
Layer 1(01270640,54AEF9DF) Recv(004): 04 01 0B 00
Layer 8(01270160,54AEF9DF) TUNNEL_ACK

Im Anhang noch ein Screenshot vom ETS Gruppenmonitor.

[timowi]

@do13

ich hab den fix noch mal angepasst. Jetzt wird der header verglichen. So sollte das funktionieren.

Kannst du den selben Versuch noch mal mit dem branch https://github.com/Makki1/knxd/tree/...art-duplicates durchführen?

[do13]

Kannst du den selben Versuch noch mal mit dem branch https://github.com/Makki1/knxd/tree/...art-duplicates durchführen?

Kann ich machen, komme aber vermutlich erst morgen dazu.

Dirk

[l0wside]

Das hast du falsch verstanden. Das Problem tritt auf wenn knxd als router konfiguriert ist. KNXNET/IP <-> KNX TP
Das Packet kommt von knxnet/ip (routingzähler 6) -> wird per tpuart auf den Bus gesendet (routingzähler 5) -> Das Echo wird als eingehendes Packet vom Bus behandelt und wieder über knxnet/ip gesendet (routingzähler 4)

OK, verstanden. Das heißt in der Konsequenz ja, dass das Echo auf dem TPUART als solches erkannt werden muss. Wie vermeidet der eibd bei Frames aus einer anderen Quelle (z.B. über lokales Socket wie /tmp/eib) dieses Echo?
Meine Lösung (nur als Anregung verstehen): ich merke mir in einem Ringpuffer 16-bit-CRCs der letzen n Frames. Wenn ein empfangener Frame eine CRC hat, die im Ringpuffer vorhanden ist, verwerfe ich ihn.

Wenn von beiden Seiten kurz nacheinander der gleiche Frame kommt, geht das natürlich schief. Allerdings darf das in einer vernünftigen Topologie nicht passieren.

Max

[timowi]

. Wie vermeidet der eibd bei Frames aus einer anderen Quelle (z.B. über lokales Socket wie /tmp/eib) dieses Echo?

Bisher wohl gar nicht. Doppelte Packete sollten aber eigentlich keine Nebenwirkungen haben.

Meine Lösung (nur als Anregung verstehen): ich merke mir in einem Ringpuffer 16-bit-CRCs der letzen n Frames. Wenn ein empfangener Frame eine CRC hat, die im Ringpuffer vorhanden ist, verwerfe ich ihn.

Es darf wirklich nur das Echo ignoriert werden. Ansonsten dürfen doppelte Telegramme natürlich auftreten.

Die Lösung sollte auf jeden Fall gut getestet werden. Wenn das TPUART backend dadurch in anderen Fällen Fehler macht ist das noch schlimmer.

[saft6luck]

Meine Lösung (nur als Anregung verstehen): ich merke mir in einem Ringpuffer 16-bit-CRCs der letzen n Frames. Wenn ein empfangener Frame eine CRC hat, die im Ringpuffer vorhanden ist, verwerfe ich ihn.

Üblicherweise prüft man das Echo. Es dient der Verifikation, dass die gesendeten Daten den übertragenen Daten entsprachen.

Da es zeitgleich empfangen wird und folglich auf jeden Fall das nächste Paket im Puffer sein muss, sollte der Vergleich auf identischen Inhalt auf jeden Fall durchgeführt werden. (3.2.3.1.5 U_L_Data-Service im PDF)

1. Wenn der Vergleich fehlschlägt, muss man das eignen Paket evtl. erneut verschicken.
2. Je nach Fehlerbild könnte das zeitgleich empfangen Paket aber ein gültiges neues Paket sein -> zeitgleiches Senden. Laut TPUART1_Datenblatt_20130806.pdf ist dann aber das Fehlerbit gesetzt.
   -> Falls ein gültiges (nicht identisches) Paket empfangen wurde, muss das natürlich bearbeitet werden.

[l0wside]

Da es zeitgleich empfangen wird und folglich auf jeden Fall das nächste Paket im Puffer sein muss, sollte der Vergleich auf identischen Inhalt auf jeden Fall durchgeführt werden. (3.2.3.1.5 U_L_Data-Service im PDF)

An diesem Punkt bin ich nicht einig. Der TPUART speichert den Frame mindestens teilweise zwischen, siehe Timing-Diagramm. Wenn der TPUART den Frame nicht sofort senden kann, speichert er ihn erst mal zwischen und wiederholt ihn ggf. bis zu drei Mal (lässt sich konfigurieren).

Es ist also nicht gesagt, dass der erste empfangene Frame nach dem Schreiben eines Frames in den TPUART das zugehörige Echo ist.
Einen Fehler meldet der TPUART nur dann, wenn du einen zweiten Frame senden willst, bevor der erste komplett gesendet wurde - jedenfalls lese ich so das Datenblatt.

Max

[timowi]

Das echo muss eigentlich nicht geprüft werden. Das backend wartet auf das signal vom TPUART dass das Telegramm gesendet wurde. Das ignorieren ist also schon ok.

Ich sehe es auch so, dass ein Telegramm empfangen werden kann, während eins in den Sendepuffer geschrieben wird (oder schon drinn ist). Bei hoher buslast könnte es auch etwas dauern, bis gesendet werden kann. Dann kommen einige Telegramm vor dem echo.