eibd(war bcusdk) Fork -> knxd

[lustigerpinguin]

Hallo Zusammen,

vorweg: ich kann nicht programmieren

Bei meinem Arbeitgeber arbeiten wir mit gitlab für die Versionsverwaltung.
Die Daten aus dem Git gehen dann zum Bauen direkt an unseren internen Jenkins (z.B. würde das verm. auch hier gehen: https://www.cloudbees.com/resources/...rogram-details).
Alternativ auch noch hier mit: https://travis-ci.org

Was testen angeht: mit einer Anleitung/makefile bekomme ich auch den Sourcecode gebaut (den Dreisatz ./configure && ./make && ./make install schaffe ich normalerweise auch )

Testen geht bedingt, mir fehlt die KNX - Hardware; die kann ich evtl. noch auf der Arbeit testen; tcpdump würde aber z.B. gehen, solange keine Rückmeldung kommen muss.

Ich hoffe die Info hilft etwas.

Gruß

lustigerpinguin

[timowi]

Jep, das wäre fatal und geht garnicht. Genau deswegen wird das auch seit Jahren immer - teils wochenlang! - live getestet, weil nur so bekommt man das mit (Licht geht an Tag 39 im Bad nicht an..)

na, dann sind es halt 160Tage (auch nicht viel besser). Vielleicht auch nur in einer Konstellation die nicht geststet wird... Daher min Fazit: Praktisch nicht testbar.

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.
Also Änderungen, wo "nebenbei" 400 Tabs oder spaces befummelt werden gehen natürlich garnicht;
kleine Aufräumarbeiten (Comments, Idents) in hübsch segmentierten commits schon.

Das sehe ich schon so "hart". Gerade auch "einfache" commits sollten erst in in branch und dann mergen nach review. Da habe ich einfach zu viel schlechte Erfahrungen. In whitespace changes und auch reinem dokumentieren verstecken sich zu leicht Änderungen, die man übersieht. Sei es mangels disziplin (ach das muss eh gemacht werden und ist ja einfach...), weil man im editor versehentlich was löscht/einfügt/verschiebt/dupliziert oder weil man nicht auf einen sauberen branch arbeitet (Mal was getestet und und dann vergessen). Und schon hat man eine Änderung sehr gut versteckt. Fürs review sollten dann tools ingesetzt werden. Sonst übersieht man das in vielen Zeilen einfach.

Für grobe Änderungen eine branch, wenn keiner Widerspricht kanns derjenige dann mergen.
Post-1.0 wirds dann eh "master"(bezeichne ich als "trunk", da darf man durchaus dann auch mal "fummeln") und release-x.y geben..

Ich finde man kann ruhig auf positive Rückmeldung warten. Sonst weiß man nicht ob stillschweigende Zustimmung ist, oder bloß niemand Zeit hatte...
Auch nach dem Release sollte nicht gefummelt werden. Wir sollten da schon mehr auf Entwicklungprozesse setzten als haufenweise gebastel am code. Knxd hat ein Haufen Zustandsautomaten und viele unterschiedliche Codezweige. Da wird viel zu einfach was kaputt gemacht. Und "vor dem nächsten release finden wir alle Fehler und dann wird das schon" funktioniert einfach nicht.


100% Ack: Das hat schon seine Richtigkeit, ob nervig oder nicht! Ich habe selbst schon 99x zuviel irgendeinen "Quickfix" gemacht.. (die letzten 4J u.a. mit patches am eibd..)

Obwohl ich bei der Entwicklung kaum viel beitragen kann und meine Meinung deshalb nicht besonders relevant ist, möchte ich sie trotzdem kurz äussern, zumal ich jetzt auch meine ersten Erfahrungen mit Github gemacht habe:
[LIST][*]Jede Änderung soll in einem spezifischen Branch im eigenen Fork gemacht und verifiziert werden.
...
Ich finde der Master Branch in Makki's Repository sollte nach Möglichkeit dauernd auf Produktivlevel gehalten werden.

Genau so sollte es sein (Meiner Meinung nach). Branching und Merging ist sehr schnell und leicht mit git. Das sollte ausgiebig genutzt werden. Die Verzögerung dadurch spielt eigentlich keine Rolle. Wenn jeder einfach in master committed wird es schnell unübersichtlich. Diskussionen über Änderungen werden sehr schwierig. Dann wird es sehr schnell eher ein Gebastel als eine Zielgerichtete Entwicklung. Für die Client programm mag das nicht so schlimm sein, für den Kern halte ich das aber für den falschen weg.

[Tru]

Githup Änderungsprozess

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.

Obwohl ich bei der Entwicklung kaum viel beitragen kann und meine Meinung deshalb nicht besonders relevant ist, möchte ich sie trotzdem kurz äussern, zumal ich jetzt auch meine ersten Erfahrungen mit Github gemacht habe:

• Jede Änderung soll in einem spezifischen Branch im eigenen Fork gemacht und verifiziert werden.
• Der Merge soll mit einem Pull Request beantragt werden. Mindestens eine weitere Person muss es gutheissen. Bekanntlich übersieht man seine eigenen Fehler sehr leicht. Da macht es Sinn dass es eine, noch besser mehrere Personen anschauen oder sogar prüfen.
• Wenn eine Zustimmung vorliegt, kann jeder mit Schreibrecht den Merge durchführen. Im Trivialfall kann der Zustimmende den Merge ja gleich machen. So geschieht jede Änderung im Master im Mehraugenprinzip
• Der spezifische Branch im eigenen Repository kann zum Schluss wieder gelöscht werden, damit es übersichtlich bleibt.

Ich finde der Master Branch in Makki's Repository sollte nach Möglichkeit dauernd auf Produktivlevel gehalten werden.


Gruss, Othmar

[makki]

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

Leider ist es etwas komplizierter, aber ich habe seit Jahren das erste mal das Gefühl, das wir uns in der Sache einer wirklichen Lösung nähern.
Das Problem ansich ist mir ja seit langem bekannt! Das Verhalten des eibd ist da nicht richtig, aber wie bereits von vorpostern angemerkt, ist eine Telegramm-Wiederholung (hier) unnötig&lästig, sollte aber nicht zu einem echten Problem führen,
-> weil das kann & darf (im Einzelfall) immer mal vorkommen.
Will ich für mitleser nur dazusagen

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.

Jep, das wäre fatal und geht garnicht. Genau deswegen wird das auch seit Jahren immer - teils wochenlang! - live getestet, weil nur so bekommt man das mit (Licht geht an Tag 39 im Bad nicht an..)

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

Ich bin eigentlich eher angenehm überrascht, ich habs mir schlimmer vorgestellt

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.

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.
Also Änderungen, wo "nebenbei" 400 Tabs oder spaces befummelt werden gehen natürlich garnicht;
kleine Aufräumarbeiten (Comments, Idents) in hübsch segmentierten commits schon.
Für grobe Änderungen eine branch, wenn keiner Widerspricht kanns derjenige dann mergen.
Post-1.0 wirds dann eh "master"(bezeichne ich als "trunk", da darf man durchaus dann auch mal "fummeln") und release-x.y geben..

(kein Kommentar meinerseits zu manchem ist übrigens bitte keineswegs als abwertend oder Missbilligung zu sehen, sondern eher als stumme Zustimmung!)

Planung 1.0: ist hier Anfangs bereits beschreiben und in dem Milestone auch: 100% eibd 0.0.5 mit dringend notwendigen fixes;
danach: ist Diskussions-Sache, in Issues oder Milestone reinschreiben(?)

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.

100% Ack: Das hat schon seine Richtigkeit, ob nervig oder nicht! Ich habe selbst schon 99x zuviel irgendeinen "Quickfix" gemacht.. (die letzten 4J u.a. mit patches am eibd..)

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.

Planen/Koordinieren: momentan finde ich passt das mit Issues bei Github (kann man ja auch nen Assignee eintragen, Milestones), Diskussion dort oder eben hier (und das ganz bewusst öffentlich, da jeder - auch stille Mitleser daran teilhaben sollen!)
Mittelfristig sollte es aber auch wieder eine Mailing-Liste o.ä. geben, weil halt nicht jeder deutsch spricht.. Die bcusdk-devel tuts aber da für den Moment denke ich..

Es gibt auch das Angebot seitens der Admins dafür hier ein Unterforum einzurichten, nur sehe ich den Bedarf noch(?) nicht, bisher ist die Diskussion hier in diesem Thread (konzentriert!) und auf github IMHO sehr zielgerichtet und auch zielführend, oder?
(Die zig PN's und emails zum Thema "makki, sag mal, wie starte ich eibd auf meinem Raspi" streiche ich jetzt mal aus dieser Betrachtung Das machen wir wenn 1.0 steht&geht)

Makki

P.S.: ich freue mich übrigens echt über die rege Beteiligung! Und nochmal: Kein Kommentar zu etwas bedeutet im Regelfall schlicht Zustimmung.

[saft6luck]

Ich habe das bereits so implementiert, das der header verglichen wird und dann das packet ignoriert wird. Das muss jetzt halt getestet werden. Für Verbesserungsvorschläge bin ich natürlich offen.

Wenn du nur das darauffolgende Telegramm vergleichst, könnte gleichzeitiges Senden (insbesondere hohe Buslast) das Problem wieder zeigen.

[saft6luck]

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

Thema zeitgleiches Senden, genau. Dann habe ich aber nicht den gleichen Frame empfangen, also Fall 2.

Laut Diagramm empfängt der TPUART das zu sendende Telegramm zeitgleich wieder und überträgt es mit der Sendebestätigung (oder einem Fehlercode) an den Host. So kann man schon unterscheiden, ob es das eigene Telegramm war, dass man jetzt empfangen hat.

Für den 1. Schuß würde ich die Sendebestätigung prüfen und gut ist.

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.

Der zu sendende Frame bleibt also weiterhin im Host Puffer und wird beim nächsten Telegramm verglichen.

Natürlich kann man auch darauf verzichten das Echo zu prüfen, es würde sich aber anbieten, denn eine Checksumme kann die Übertragung nicht vollständig absichern.

[do13]

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

Bin noch kurz zu einem Test gekommen:

Layer 0(02501640,54B00F57) Recv(018): 06 10 05 30 00 12 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 1(02501640,54B00F57) Recv(012): 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 8(02501160,54B00F57) 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(024E03D0,54B00F57) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 2(024CFC00,54B00F57) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 0(024CFC00,54B00F57) Write(020): 80 BC 81 11 82 00 83 67 84 07 85 D2 86 00 87 80 88 00 49 60
Layer 0(024CFC00,54B00F57) Recv(001): BC
Layer 0(024CFC00,54B00F57) Recv(001): 11
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) Recv(001): 67
Layer 0(024CFC00,54B00F57) Recv(001): 07
Layer 0(024CFC00,54B00F57) Recv(001): D2
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 80
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 60
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 8B
Layer 0(024CFC00,54B00F59) Recv(001): BC
Layer 0(024CFC00,54B00F59) Recv(001): 15
Layer 0(024CFC00,54B00F59) Recv(001): 06
Layer 0(024CFC00,54B00F59) Recv(001): 29
Layer 0(024CFC00,54B00F59) Recv(001): 6B
Layer 0(024CFC00,54B00F59) Recv(001): C3
Layer 0(024CFC00,54B00F59) SendAck 10
Layer 0(024CFC00,54B00F59) Recv(001): 00
Layer 0(024CFC00,54B00F59) Recv(001): 80
Layer 0(024CFC00,54B00F59) Recv(001): 01
Layer 0(024CFC00,54B00F59) Recv(001): 2C
Layer 0(024CFC00,54B00F59) Recv(001): 7C
Layer 1(024CFC00,54B00F59) Recv(011): BC 15 06 29 6B C3 00 80 01 2C 7C
Layer 2(024CFC00,54B00F59) Recv L_Data low from 1.5.6 to 5/1/107 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 3(024E03D0,54B00F59) Recv L_Data low from 1.5.6 to 5/1/107 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 8(02501160,54B00F59) Send_Route L_Data low from 1.5.6 to 5/1/107 hops: 03 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 1(02501640,54B00F59) Send(013): 29 00 BC B0 15 06 29 6B 03 00 80 01 2C
Layer 0(02501640,54B00F59) Send(019): 06 10 05 30 00 13 29 00 BC B0 15 06 29 6B 03 00 80 01 2C

Damit bekommen wir das Problem in den Griff. Ob es noch irgendwelche Nebenwirkungen hat müssten jetzt weitere Tests zeigen.

Dirk

[timowi]

Ich habe das bereits so implementiert, das der header verglichen wird und dann das packet ignoriert wird. Das muss jetzt halt getestet werden. Für Verbesserungsvorschläge bin ich natürlich offen.

Wobei mir gerade einfällt dass bei einem Echo eigentlich als Absender die PA des TPUART im Adressfeld stehen müsste. Also wäre es auch möglich die Telegramme von der PA des TPUART auszufiltern.

Wie kommst du da drauf? Es kommt genau so zurück wie es dem tpuart übergeben wurde bzw wie es auf den bus gesendet wird. Erstellen der packete macht nicht der tpuart.

Irgend wie muss es ja eine Lösung für das Problem geben denn mit dem gleichen Phänomen müssen ja auch echte IP Router fertig werden (und werden sie auch...).

Müssen sie nur wenn ein tpuart verbaut ist. Dann muss die kommunikation mit den tpuart halt entsprechend umgesetzt werden.

Routing ist glaub ich noch gar nicht richtig implementiert. Es wird einfach alles weitergeleitet. Ich denke da sollte auch gefiltert werden, von wo nach wo eigentlich weitergeleitet wird.

[swiss]

Naja um das Echo zu erkennen kann man bei identischen Paketen auch den Routingzähler vergleichen... Kommt das gleiche Telegramm innerhalb einer gewissen Zeit mit identischem Routingzähler wie vom TPUART gesendet wurde, ist etwas falsch. Da alle Telegramme von TLN mit 6 Starten und beim passieren der Koppler um 1 reduziert werden...

Wenn also von oben (IP) ein Telegram mit z.B. Routingzäler 5 kommt und der TPUART das Telegramm mit Routingzähler 4 sendet, kann das gleiche Telegramm mit ebenfalls Routingzähler 4 nicht von einem Teilnehmer sein.

Wobei mir gerade einfällt dass bei einem Echo eigentlich als Absender die PA des TPUART im Adressfeld stehen müsste. Also wäre es auch möglich die Telegramme von der PA des TPUART auszufiltern.

Irgend wie muss es ja eine Lösung für das Problem geben denn mit dem gleichen Phänomen müssen ja auch echte IP Router fertig werden (und werden sie auch...). Gibt es da keine Vorgaben wie das nach KNX Standard zu lösen ist?

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

[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

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

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

[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

[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