eibd anstatt knxd?

[umatz]

Hier die gdb Ausgaben, Stacktrace brachte keine neuen Erkenntnisse, daher mit fr 1; ins reg; disass: http://pastebin.com/QMZQaNkM

[Smurf]

Seufz. Nächster Versuch: knxd -t1022 …, dito in einen Pastebin.

[umatz]

Auf ein neues, vielen Dank für Dein Engagement.

http://pastebin.com/PAxBMrEh

[Smurf]

Damit loggst du nur den uninteressanten Teil der Unterhaltung, nämlich das was er an den Multicastport schickt. Bitte stell das "-t 1022" an den Anfang der Argumente.

[umatz]

Bitte schön: http://pastebin.com/MVNnJRwK

[Tru]

Vollständig (bild- und textlich) ist es nicht

Korrekturvorschläge: Der Teil "Port:6720" gehört unter das NIC neben das Multicast als "Unicast" Section. KNXTOOL kann auch über TCP/IP auf 6720 zugreifen, nicht nur über das Loopback-Interface. 4.3 (-T) gehört zur Unicast Section, nicht zu Multicast.

[umatz]

Smurf So ich war jetzt mal neugierig und habe mir Deine Änderungen von gestern gezogen.
Es gab Probleme mit dem Paket bauen, weil eibclient-int.h nicht mehr gefunden wurde, daraufhin habe ich mein knxd-Verzeichnis gelöscht und neu geklont.
Nun läuft knxd ohne Absturz! Super Arbeit!

[itarch]

Korrekturvorschläge: Der Teil "Port:6720" gehört unter das NIC neben das Multicast als "Unicast" Section. KNXTOOL kann auch über TCP/IP auf 6720 zugreifen, nicht nur über das Loopback-Interface. 4.3 (-T) gehört zur Unicast Section, nicht zu Multicast.

Korrekturvorschläge angenommen
siehe Schaubild-Update #109

[Smurf]

Hmm. Das Problem, das ich mit dem Schaubild habe, ist, dass die Pfeile für Netzwerk alle auf "NIC" gehen und es so aussieht, als wären das dann untereinander verbunden. Dem ist aber nicht so.

Es gibt vier Arten "NIC": Multicast auf Port 6720 (-RS oder -b ip, die knxd-spezifische TCP-Verbindung (-i, TCP Port 3761), UDP-Server (Port 6720, -TS), und UDP-Client (auch port 6720, -b ipt. Diese vier sehen sich gegenseitig nicht; "-b ip:" und -RS aber sehr wohl. Deshalb wäre es sinnvoll, Letztere nebeneinander anzuordnen, und zwischen denen und allen anderen Methoden einen Trennstrich im NIC-Balken einzufügren.

Sobald wir sowas wie eine Konfigdatei haben, wird das Ganze ein bisschen anders (und hoffentlich auch verständlicher!) aussehen.

[smai]

Grundsätzlich finde ich das Schaubild sehr gut, es ist wirklich sehr anschaulich.

Ich würde die NIC im Bild einfach weglassen, weil sie IMHO keine Relevanz hat. Das TCP/IP stimmt ja eigentlich auch nicht, da Port 3671 UDP ist.

Noch zwei Sachen zu den Clients: Die Versionsnummern würde ich weglassen, weil diese ja auch ändern können. Und wenn du die CometVisu erwähnst, könntest du evtl. noch das viel genutzte SmartHome.py aufführen (bei Port 6720).

[Tru]

Es gibt vier Arten "NIC": Multicast auf Port 6720 (-RS oder -b ip, die knxd-spezifische TCP-Verbindung (-i, TCP Port 3761), UDP-Server (Port 6720, -TS), und UDP-Client (auch port 6720, -b ipt.

Da hast du wohl die Ports zwischen UDP und TCP verwechselt, oder? Zudem ist es 3671, nicht 3761.

Wäre es nicht sinnvoll die Schnittstelle ip: als Parameter generell gar nicht zuzulassen? Multicast kann ja mit -RS aktiviert werden. Gibt es eine Situation, welche nur mit der Angabe von -b ip: gelöst werden kann? Den Namen des IP-Interfaces aus ip:[multicast_addr[: port[:interface]]] könnte man ja auch bei -S implementieren, oder?

[itarch]

Hallo

@zum Schaubild (#109)
Die NIC ist als Bindeglied zwischen den KNXD Server Services (Routing; -b:ip; multicast [224.0.32.12] UND/ODER Tunneling; -b ipt:..; unicast [Ziel-IP:3671]) und ankommenden Kommunilationsanfragen zu verstehen.
Darüberhinaus weckt systemd den KNXD (soweit ich verstanden habe auch dann wenn er nicht gestartet ist) aus dem Tiefschlaf, wenn Anfragen auf Port 6720 ankommen. Dies kann entweder über die NIC erfolgen, will heißen die Anfrage stammt aus einer Anwendung aus dem Inter-/Intranet oder auch von einer Anwendung, die auf dem gleichen System läuft auf dem auch KNXD läuft.
Das Schaubild hat nicht die Aufgabe eine spezifische Konfiguration zu demonstrieren, eher allgemein KNXD Parameter und deren Beziehung zu der Peripherie (Software und Hardware) herzustellen.
Wer seine Installationsbasis über das Bild legen wird, wird wohl jede Menge aus-ixen.
Wie auch immer, ich versuche das was ich verstehe in ein Ordnungssystem zu packen. Daher bin ich auch über jeden Verbesserungsvorschlag froh. Unter anderem deshalb weil ich oft feststellte (bei den Vorschlägen, die bereits kamen), dass die Anmerkungen nicht nur zur schematischen Verbesserung führen sondern auch zum besseren Verständnis.

@smurf: deine Anmerkungen haben mich abgehängt... Ich sehe grad ich bin nicht der einzige...

@KNXD 0.12.4 und 0.12.5
INFO:
Bei mir verweigert der KNXD nach wie vor in beiden Releases in Kombination mit dem Weinzierl 730 nach 8 Reads die Arbeit. Ich kann einen Trace erstellen und hochladen.
Konfiguriere ich den KNXD gegen das Busware TPUART verbraucht er fleißig sein Adressen Pool ab und beginnt dann wieder von vorne.

Gruß@All

[Tru]

Konfiguriere ich den KNXD gegen das Busware TPUART verbraucht er fleißig sein Adressen Pool ab und beginnt dann wieder von vorne.

Ich konfiguriere meinen KNXD 0.12 auf einen IP-Tunnel ( -b ipt: ) und auch hier arbeitet er seinen Adressen Pool (gemäss -E) ab und beginnt dann wieder von vorne.

[itarch]

Ich konfiguriere meinen KNXD 0.12 auf einen IP-Tunnel ( -b ipt: ) ....

okay
ich starte Ihn mit -e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.1.11 (Weinzierl 730)
sende dann Reads mit knxtools groupread local:/run/knx 5/1/18. Sehe im Gruppenmonitor als Quell-Adresse erst 0.0.2 dann 0.0.3 ... und schließlich auch 0.0.9. Danach schmeißt knxtool den Fehler "connection refused" und das wars.

Jetzt ist ja so ein KNX IP Interface kein Päckchen Tabak. Sonst hätte ich eine paar hier auf Vorrat. Wenn ich dran denke, wie skeptisch ich monatelang auf das Busware TPUART war, jetzt froh bin, dass ich es habe, letztlich auch um mit der Gira HS (VM) zu spielen.

[smai]

Darüberhinaus weckt systemd den KNXD (soweit ich verstanden habe auch dann wenn er nicht gestartet ist) aus dem Tiefschlaf, wenn Anfragen auf Port 6720 ankommen. Dies kann entweder über die NIC erfolgen, will heißen die Anfrage stammt aus einer Anwendung aus dem Inter-/Intranet oder auch von einer Anwendung, die auf dem gleichen System läuft auf dem auch KNXD läuft.

<klugscheiss>
Das mit den lokalen Anfragen gilt nicht nur für Port 6720, sondern für alle Varianten per TCP oder UDP.
Ob die NIC physisch oder der virtuelle Loopback Adapter mit IP 127.0.0.1 ist spielt für KNXD und das Gesamtsystem keine Rolle.
</klugscheiss>