eibd(war bcusdk) Fork -> knxd

[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

[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

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

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

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?

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

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

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

[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

[Smurf]

#!/bin/sh
if [[ $OSTYPE == *"darwin"* ]]

Das Konstrukt mit "[[" ist nicht POSIX-konform. Du willst /bin/bash. Oder ein Konstrukt mit case…esac.

[Jockel]

Hast recht, auf dem MAC klappt das mit /bin/sh, daher ist es mir nicht aufgefallen.

Also z.B. so:

#!/bin/sh

case "$OSTYPE" in
*"darwin"*) LIBTOOLIZE="glibtoolize" ;;
* ) LIBTOOLIZE="libtoolize";;
esac

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

[timowi]

Ich dokumentiere das gerne, wie und wo wäre das denn am zweckmäßigsten, zur Zeit habe ich nur eine Stichwortliste?

Entweder im wiki oder im code z.B. doc/INSTALL.macos

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?

Ja, meiner Meinung nach reicht das. Es sollte ja eher eine Anleitung sein für jemeand der sich mit dem System schon auskennt und auf der Kommandozeile arbeiten kann. Wichtiger ist es eher auf typische Fehler (und deren Behebung) hinzuweisen. Z.B. was vorher installiert werden muss.

1. bootstrap.sh

das ist eigentlich nur als unterstützung für die Entwicklung gedacht. In einem Release wird configure schon enthalten sein. Man kann die tools auch einfach sirekt aufrufen, ist nur etwas aufwendig wenn man das häufiger macht (wegen änderungen an autoconf dateien, oder wenn man öffters auf einen sauberen branch wechselt). Falls vorhanden kann stattdessen auch einfach "autoreconf --force --install" verwendet werden. Es darf aber auch gerne jemand arbeit ins bootstrap.sh skript stecken ...

2. src/libserver/eibnetserver.cpp
#include <malloc.h> durch folgenden Code ersetzen:

Das ist der falsche weg. Wenn dann über configure auf header testen und entsprechend verwenden.
Hier halte ich das aber für einen Fehler. malloc.h sollte gar nicht verwendet werden. Einfach mal ganz rausnehmen. Falls da doch eine Funktion verwendet wird, sollte das geändert werden. Ich denke aber eher das der header versehentlich eingebunden wird.

[LittleKNX]

Hallo zusammen,

ich würde euch gerne unterstützen, beispielsweise testen auf Ubuntu. Einen für automake 1.14 notwendigen patch hab' ich schon auf Github in die Issues gestellt.

Grundsätzlich würde ich mir langfristig wünschen, wenn knxd client Verbindungen optional per SSL verschlüsseln würde.

Außerdem würde ich mir für die 'tools' wünschen, wenn sie immer wiederkehrende (und feststehende) Parameter aus einer config Datei lesen könnten:

groupreadresponse 8/0/1

wenn in der .knxdtools config folgendes eingetragen ist

# knxdtools config file, Jan 2015

url=ip:127.0.0.1

Viele Grüße,

Klaus

[l0wside]

Außerdem würde ich mir für die 'tools' wünschen, wenn sie immer wiederkehrende (und feststehende) Parameter aus einer config Datei lesen könnten:

Mir wäre eine entsprechende Umgebungsvariable lieber. Das lässt sich flexibler handhaben.

> export KNXURL=local:/tmp/eib
> knxgroupreadresponse 4/7/11

Max

[LittleKNX]

... ist auch ok, wenn so lange die Anzahl der Parameter gering bleibt.