eibd(war bcusdk) Fork -> knxd

[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]

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.

[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

[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.

[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]

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.

[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

[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

[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.

[makki]

.
Das liegt ja in der Hand des Package Maintainer. Ich habe jetzt die Configfiles und das Init-Script im Paket integriert. Das enable und start könnte mit postinst Anweisungen erledigt werden. Ich habe jedoch davon abgesehen, denn nach der Erstinstallation muss ja sowieso die Konfig angepasst werden und bei einem Upgrade ist es auch nicht mehr nötig.

zumindest KNXnet/IP, USB, USB-TPUART kann man problemlos & automatisch im init-script erkennen und dem User damit das unverständliche, lästige konfigurieren+aktivieren ersparen, oder ?
Computer sollen dem Menschen dienen, nicht umgekehrt, so sehe ich das..

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..)

Makki

[timowi]

Was ich nicht verstehe: warum sollte der eibd ein empfangenes Telegramm gleich noch mal rausschicken? Vor allem: wenn er das tut, müsste sich der Vorgang beim Senden des Echos doch wiederholen, d.h. ein unendlich oft wiederholtes Echo produzieren, oder?

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)

[Jockel]

Es wäre toll - damit das nicht untergeht(!!), wenn du das ins Github-Wiki schreiben würdest - oder in ein README.osx o.ä.

Sorry, hab das erst heute gelesen, liege schon seit Tagen flach! Sobald ich wieder auf den Beinen bin und etwas Zeit habe mache ich das gerne, in den nächsten Tagen wird das aber leider nichts. Hab es mir aber in den Kalender geschrieben, damit es nicht vergessen wird!

[l0wside]

Ich würde auch auf den TPUART tippen.
Im Datenblatt auf Seite 15 ist der Sendevorgang (TP-UART-IC sending telegram) erklärt. Der TPUART schickt den zu versendenden Frame als Echo wieder zum Host zurück (während er auf den Bus sendet). Der wird dann neu empfangen und per Routing ins Netz geschickt.

Ich verfolge eure Arbeit nur lesend, aber mit großem Interesse. Von mir jedenfalls:
Das Echo-Problem kenne ich aus meiner eigenen Stack-Entwicklung (ob die dortige Lösung toll ist, bezweifle ich gerade, deswegen spare ich mir erst mal die Beschreibung).

Was ich nicht verstehe: warum sollte der eibd ein empfangenes Telegramm gleich noch mal rausschicken? Vor allem: wenn er das tut, müsste sich der Vorgang beim Senden des Echos doch wiederholen, d.h. ein unendlich oft wiederholtes Echo produzieren, oder?

Gruß,

Max

[swiss]

Ich kann den fix leider selber nicht testen da ich 0,0 Ahnung habe wie ich das irgend wo instaliert bekommen würde. Zumal ich momentan nur 2 WG in Betrieb habe und ich dan mächtig Ärger bekommen könnte durch Abhängigkeiten im WG bzw bei Updates usw...

Also kann ich da leider momentan nicht helfen...

[timowi]

Der TPUART schickt den zu versendenden Frame als Echo wieder zum Host zurück (während er auf den Bus sendet). Der wird dann neu empfangen und per Routing ins Netz geschickt.

Ja, das ist wohl das Problem. Ich hab mal versucht das zu ändern: https://github.com/Makki1/knxd/tree/...art-duplicates Wenn jemand das Problem hat kann er gerne mal testen.