eibd(war bcusdk) Fork -> knxd

[Jockel]

Nachdem ich länger flach gelegen habe bin ich heute endlich mal dazu gekommen OSX 10.10 in einer VM zu installieren und dort den knxd noch einmal zu übersetzen.

Ich dokumentiere das gerne, wie und wo wäre das denn am zweckmäßigsten, zur Zeit habe ich nur eine Stichwortliste? Da wäre dann auch die Frage, in welcher Granularität dokumentiert werden soll. Reicht z.B. $PATH muss "/opt/local/bin" enthalten oder soll das detailliert beschrieben werden?

Außerdem schlage ich zwei kleine Änderungen am Code vor, damit er unter OSX ohne Änderungen übersetzbar ist:

1. bootstrap.sh

#!/bin/sh

LIBTOOLIZE="libtoolize";

if [[ $OSTYPE == *"darwin"* ]]
then
  LIBTOOLIZE="glibtoolize";
fi

$LIBTOOLIZE --copy --force --install && \
	aclocal --force && \
	autoheader && \
	automake --add-missing --copy --force-missing && \
	autoconf

2. src/libserver/eibnetserver.cpp

#include <malloc.h> durch folgenden Code ersetzen:

#ifdef __APPLE__
#include <malloc/malloc.h>
#else
include <malloc.h>
#endif

[timowi]

Kleiner Tipp: 1) Das "Echo" vom TP-UART ist die Basis für die L_Data.conf, also die Information darüber, was aus einem L_Data.req am Ende auf dem Bus geworden ist (abweichende Definition der Crtl Field (1/2) Flags für L_Data.conf im Gegensatz zu L_Data.req beachten).

Ich halte den TPUARTS Code im knxd eh für problematisch. Da wird meiner Meinung nach einiges nicht so richtig behandelt. Ich möchte da aber fürs erste nicht viel ändern.
Über das Control field hab ich mir für den Fix auch schon gedanken gemacht. Eigentlich sollte das etwas unschärfer verglichen werden, oder? Bitmaske müsste wohl 0xFC sein. Sonst sollte das ursprüngliche Problem damit behoben sein, ohne das Verhalten sonst zu beeinflussen.

Nicht allzu schwierig, das. Ich könnte ein solches Testsystem an meinem Test/Build-Rechner anklemmen und dem Ganzen einmal Netzteil+Drossel und einen busware-Adapter spendieren. Und Microcontroller liegen hier auch zur Genüge herum.

Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)

Ich könnte bei mir in der Firma auch so einen Testaufbau machen. ... Haben auch noch einiges an andere KNX Hardware herumliegen.

Ich könnte auch ein Testsystem zur Verfügung stellen. Netzteil, Drossel, FT12-Interface, TPUARTS Interface und ein sparsammer Server hab ich hier. Ich kann das gerne so einrichten, dass ihr da über ssh dran arbeiten könnt.

Wir sollten nur planen wie das umgesetzt werden soll. Für unit tests sollte ein entsprechendes framework verwendet werden. Ich bin da offen für alles. Hab mal boost für verwendet und sonst verschieden wo ich nicht mal mehr die namen kenne. Eines war speziell zum testen von IP basierten Protokollen. Vielleicht kennt da ja jemend was passendes.

[p3root]

Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)

Ich könnte bei mir in der Firma auch so einen Testaufbau machen. Wir haben 4/5 USB Adapter da liegen. Ich bekomme auch bald ein USB-TPuart adapter. Mit welchem man schöne Fehler am Bus generieren kann. Haben auch noch einiges an andere KNX Hardware herumliegen.

[Smurf]

Stresstests

Aber für banale Dinge/Fehler wären automatische Tests schon hilfreich..

Hmm. Man nehme drei (verschiedene) KNX/USB- oder KNX/Seriell-Adapter und schreibe ein Testprogramm, das jeweils einen mit Nachrichten bombardiert und verifiziert, dass diese bei den beiden anderen ankommen. (Mit Bestätigungen.) Zusätzlich generiere man mit einem µC ein paar zufällige Busstörungen.

Nicht allzu schwierig, das. Ich könnte ein solches Testsystem an meinem Test/Build-Rechner anklemmen und dem Ganzen einmal Netzteil+Drossel und einen busware-Adapter spendieren. Und Microcontroller liegen hier auch zur Genüge herum.

Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)

[saft6luck]

Doch, erlaubt ist ein IP-Backbone mit durch IP-Router angekoppelten Linien 0.1 bis 0.15.

Das widerspricht aber irgendwie deinem Zitat von vorher, oder?

Je nun; "illegal" würde ich nicht direkt sagen. Mit Weltenkopplern verlässt man wohl den Bereich, der im KNX Standard definiert ist. Daher gibt es da auch unterschiedliche Ansichten, was das genau sein soll.

Also ist ein IP-Router bzw. sein Profil nicht für die 0.0.0 vorgesehen. Technisch kann er natürlich auf der 0.0.0 platziert werden, er muss dann aber ein "Weltenkoppler" oder was auch immer werden.

Was darf denn laut KNX Standard auf die 0.0.0? Ist das eine noch zu definierende Position in der Topologie oder ist nur nicht festgelegt, welches Gerät dort positioniert werden kann bzw. gibt es keines?

Aus meiner Sicht muss ein "Weltenkoppler" nicht nur Gruppenadressen filtern, sondern ggf. auch address translation machen - und unicasts und broadcasts keinesfalls weiterleiten - und den HopCount neu auf 6 setzen - und möglicherweise die Quelladresse ändern. In diesen Sinne ist seine Position in der Topologie eigentlich egal.

Ja, klingt schlüssig. (Egal heißt aber auch, 0.0.0 ist eigentlich ok?)

Die erweiterten Funktionen muss aber nicht notwendigerweise der Weltenkoppler erledigen, oder?
Auch ein nachgeschalteter PC kann diese Funktionen übernehmen, wie es die Hersteller der Router vorgesehen hatten.

Es gibt aber auch im Markt Geräte, die eigentlich IP-Router sind, sich zu einem "Weltenkoppler" wandeln, wenn sie die Adresse 0.0.0 bekommen.

Erfüllen die dann aber überhaupt eines deiner Kriterien an Weltenkoppler? Wird die Filtertabelle von der ETS5 überhaupt bedient?

[Klaus Gütter]

Einen Router auf 0.x.0 gibt es dann ja generell nicht.

Doch, erlaubt ist ein IP-Backbone mit durch IP-Router angekoppelten Linien 0.1 bis 0.15.

Sind dann Netzwerkkoppler (Weltenkoppler) "illegal" oder wird das am Namen festgemacht?

Je nun; "illegal" würde ich nicht direkt sagen. Mit Weltenkopplern verlässt man wohl den Bereich, der im KNX Standard definiert ist. Daher gibt es da auch unterschiedliche Ansichten, was das genau sein soll.

Aus meiner Sicht muss ein "Weltenkoppler" nicht nur Gruppenadressen filtern, sondern ggf. auch address translation machen - und unicasts und broadcasts keinesfalls weiterleiten - und den HopCount neu auf 6 setzen - und möglicherweise die Quelladresse ändern. In diesen Sinne ist seine Position in der Topologie eigentlich egal.

Es gibt aber auch im Markt Geräte, die eigentlich IP-Router sind, sich zu einem "Weltenkoppler" wandeln, wenn sie die Adresse 0.0.0 bekommen.

Gruß, Klaus

[saft6luck]

Aber ignorieren wir das mal. Die Sublinie eines IP-Routers mit Adresse 0.0.0 ist dann logischerweise der Backbone 0.0, mit Medientyp TP. Eine Hauptlinie gibt es nicht.

ok.

Einen Router auf 0.x.0 gibt es dann ja generell nicht.
Sind dann Netzwerkkoppler (Weltenkoppler) "illegal" oder wird das am Namen festgemacht?

0.0.0 ist Topologisch und in eibd/knxd schlicht falsch, es gibt auch bereits einen Issue dafür.

Daher ja die Frage.

[makki]

0.0.0 ist Topologisch und in eibd/knxd schlicht falsch, es gibt auch bereits einen Issue dafür.
@Jan: vielen Dank für die Hinweise!!

Makki

[Klaus Gütter]

Hallo Marc,

mit der Adresse 0.0.0 bewegt man sich schon außerhalb des Standards.

Zitate:

In general a KNXnet/IP Router may be used as a Line Coupler or a Backbone Coupler. The Individual Address has the format x.y.0, with x = 1 to 15 and y = 0 to 15.

This is a Coupler with Individual Address.
This is a not allowed Situation.

Aber ignorieren wir das mal. Die Sublinie eines IP-Routers mit Adresse 0.0.0 ist dann logischerweise der Backbone 0.0, mit Medientyp TP. Eine Hauptlinie gibt es nicht.

Gruß, Klaus

[saft6luck]

2) Das Tunneling Interface eines Routers sitzt topologisch auf der Sublinie. Das heißt, dass a) der HopCount beim Schreiben auf die Linie nicht dekrementiert wird und b) Telegramm, die "nach oben" geroutet würden (auch an den Router selbst adressierte), dennoch erst einmal auf die Sublinie geschrieben und "selbst bestätigt" werden.

Klar.

Kannst du noch bei folgendem Problem helfen?
Wenn der Router die 0.0.0 hat, auf welche Linie geht dann ein Tunnel, welches Medium hat dann die Linie und welches die übergeordnete Linie?

[Elwedritsche]

Kleiner Tipp: 1) Das "Echo" vom TP-UART ist die Basis für die L_Data.conf, also die Information darüber, was aus einem L_Data.req am Ende auf dem Bus geworden ist (abweichende Definition der Crtl Field (1/2) Flags für L_Data.conf im Gegensatz zu L_Data.req beachten). 2) Das Tunneling Interface eines Routers sitzt topologisch auf der Sublinie. Das heißt, dass a) der HopCount beim Schreiben auf die Linie nicht dekrementiert wird und b) Telegramm, die "nach oben" geroutet würden (auch an den Router selbst adressierte), dennoch erst einmal auf die Sublinie geschrieben und "selbst bestätigt" werden. Gruß, Jan.

[makki]

Wir haben jetzt übrigens hier zwei Projekte, die sich knxd nennen. Das könnte zu Verwirrungen führen...
Siehe: https://knx-user-forum.de/forum/supp...wiregate/26135

Das war mir bewusst - und ich hatte seinerzeit schon darauf hingewiesen, das ich die Namensgebung vom ebus-knxd als fork vom wiregated nicht für sehr sinnvoll halte (der auf den eibd zugreift).

Nachdem ich ersteren geschrieben und zweiteren geforked habe, sehe ich das ziemlich entspannt:
Mal sehen, was sich unter der Bezeichnung "knxd" durchsetzt

Makki

P.S.: Soll heissen: der wiregated.pl-Fork muss einfach umbenannt werden

[ctr]

Wir haben jetzt übrigens hier zwei Projekte, die sich knxd nennen. Das könnte zu Verwirrungen führen...
Siehe: https://knx-user-forum.de/forum/supp...wiregate/26135

Teil 1- knxd:

Der knxd ist ein abgespeckter WiregateDaemon. Dieser wurde von sämtlichen Abhängigkeiten zum originalen wiregated.pl befreit und konfigurierbar gemacht. Dadurch kann dieser auch auf dem original WireGate neben dem wiregated.pl eingesetzt werden.

[JNK]

Ich bin gerne bereit den ein oder anderen Commit zu reviewen.

[makki]

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.

Klar, es ist niemals alles testbar - selbst in so einer banalen Umgebung wie KNX

Aber für banale Dinge/Fehler wären automatische Tests schon hilfreich..

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

So soll es denn wegen mir auch sein.

Wenn genug beisammen sind, klappt das vermutlich auch (wenn ich am Anfang allerdings auf eine dritte Meinung zu den auto*-changes von dir gewartet hätte, naja, dann würden wir vermutlich immernoch dastehen und warten ..)
Also es sollte den Entwicklungsprozess halt nicht behindern, ohne das die Qualität auf der Strecke bleibt.
Gratwanderung nennt man das glaube ich..

Makki