eibd anstatt knxd?

[henfri]

Hallo,

ich bin noch nicht viel schlauer. Einerseits weiß ich immer noch nicht, wer oder was knx.socket ist, und was ich machen muss damit es existiert und genutzt wird.
Andererseits weiß ich nicht, ob ich stattdessen (sehe den Vorteil nicht) auch -i verwenden kann -wie bisher.

Gruß,
Hendrik

[itarch]

Ich versuch mal zu helfen...
KNXD, sobald gestartet (natürlich je nach KNXD_OPTS), kann angesprochen werden über
- Socket /var/run/knx was ein link ist auf /run/knx
- Port 6720 (in deinem Fall smarthome.py 127.0.0.1:6720)
- IP-Adresse:3671 wenn er Tunneling Dienste verrichtet
- 224.0.23.12 wenn er Routing Dienste verrichtet

Ich nutze Port 3671 um die ETS an den BUS zu bekommen, die chain sieht wie folgt aus:
ETS --- KNXD (IP-Adresse:3671) --- USB Busware TUL TPUART --- KNX BUS

Ich nutze bspw den Routing Dienst von KNXD um den Gira Home Server an den BUS zu bekommen, die chain sieht wie folgt aus:
GIRA-HS --- KNXD (Routing auf Multicast 224.0.23.12) --- USB Busware TUL TPUART --- KNX BUS

Den Dienst am Port 6720 (genauer gesagt 127.0.0.1:6720) nutzt linknx welches auch auf dem Rasp3B läuft

Den Socket nehme ich gerne wenn ich via "knxtools ..." Befehle auf dem Bus senden will.

Wenn ich falsch liege bei dem was ich sage, bitte ich drum korrigiert zu werden.

[Smurf]

Ich versuch mal zu helfen...
KNXD, sobald gestartet (natürlich je nach KNXD_OPTS), kann angesprochen werden über
- Socket /var/run/knx was ein link ist auf /run/knx

Genauer gesagt: /var/run ist ein Link auf /run.

Der Rest passt. Danke.

Das Wichtigste: all diese möglichen Chains dürfen sich nicht irgendwo wieder treffen. Beispiel: zwei knxd verwenden Multicast und reden parallel dazu beide über ipt: mit dem Busadapter. Dann kommt jedes Paket dort zweimal an; wenn man Pech hat und der Adapter die Daten intern auch weiterleitet, geht jede Nachricht sogar zehnmal über den Bus. Nicht gut, das.

[Smurf]

knxd.socket ist eine Datei für systemd. Die sagt ihm: die Ports 6720 und /run/knx macht der knxd nicht selber auf, sondern das erledigt der systemd für ihn.

Die Idee dahinter ist, dass der knxd beim Systemstart noch nicht mal laufen muss, man aber trotzdem schon Daten an ihn schicken kann. Er antwortet halt erst, wenn er gestartet ist. Das vermeidet einen Haufen Abhängigkeiten und "künstliche" Wartezeiten beim Systemstart.

Dem knxd kann man dann natürlich nicht sagen, dass er Port 6720 auch öffnen soll, denn der ist ja schon offen – zweimal unabhängig voneinander auf demselben Port zu lauschen geht nicht. (Weil das konfigurationstechnisch immer wieder zu Problemen führt, ignoriert der knxd in der aktuellen Version -i und -u, wenn sie ohne Argument daherkommen und das Öffnen der Ports fehlschlägt und er via systemd offene Ports bekommt.)

[Smurf]

So jetzt habe ich den Moment des Absturz auch im knxd Trace, passiert kurz (1s) nach dem Start von smarthome.py, wenn der beginnt, die KNX-Items vom knxd abzufragen:

sudo -u knxd /usr/bin/knxd --eibaddr=0.0.1 --client-addrs=0.0.2:8 --GroupCache --listen-local=/tmp/eib --trace=1023 --listen-tcp=6720 --layer2=ip:
k[…]
Segmentation fault (core dumped)

Autsch. Welche git-Version ist das, der aktuelle Master?

Bitte lass ihn unter gdb laufen und gib mir einen Stacktrace.

# cd ~/knx
# gdb src/server/knxd
# r --eibaddr=…
[ Crash ]
# whe

[itarch]

....

Die Idee dahinter ist, dass der knxd beim Systemstart noch nicht mal laufen muss, man aber trotzdem schon Daten an ihn schicken kann. ...

Exakt, hab ich auch beobachtet, super Erläuterung!

[umatz]

Du kriegst raus, was das Problem beim Start ist, wenn Du den knxd mal manuell mit den Parametern startest, die Du im knxd.conf angegeben hast (vorher alle laufenden Instanzen von knxd beenden).

In Deinem Fall dürfte --send-delay in Verbindung mit -b ip: das Problem sein. Lass das send-Delay mal weg.

[umatz]

Autsch. Welche git-Version ist das, der aktuelle Master?

Ja, ist der aktuelle Master (heute gepullt und gebaut).

Hier der Stacktrace:

knxd: Layer 7 [ 7:inet       12.504] CloseGroupSocket
knxd: Layer 2 [ 6:ip:        12.504] Send L_Data low from 0.0.1 to 1/3/2 hops: 05 T_DATA_XXX_REQ A_GroupValue_Read
knxd: Layer 1 [ 6:ip:        12.504] Send(011): 29 00 BC D0 00 01 0B 02 01 00 00

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) whe
#0  0x0000000000000000 in ?? ()
#1  0x00000000004513ba in GroupSocket::send_L_Data (this=this@entry=0x68c760, l=l@entry=0x68c6b0)
    at layer4.cpp:517
#2  0x00000000004219ed in Layer3real::trigger_cb (this=0x6833d0, w=..., revents=<optimized out>)
    at layer3.cpp:373
#3  0x00007ffff79b4d73 in ev_invoke_pending () from /usr/lib/x86_64-linux-gnu/libev.so.4
#4  0x00007ffff79b83de in ev_run () from /usr/lib/x86_64-linux-gnu/libev.so.4
#5  0x0000000000403736 in main (ac=8, ag=0x7fffffffe438) at knxd.cpp:714

[Smurf]

"-b ip:192.168.2.121" ist Unfug. ip: benötigt eine Multicast-Adresse. Oder gleich weglassen, denn die Standardadresse ist der Default. --send-delay geht nicht vor "ip:", weil der knxd davon ausgeht, dass ein Router einen ausreichenden Puffer besitzt.

[umatz]

(gdb) whe
#0 0x0000000000000000 in ?? ()
#1 0x00000000004513ba in GroupSocket::send_L_Data (this=this@entry=0x68c760, l=l@entry=0x68c6b0)
at layer4.cpp:517
#2 0x00000000004219ed in Layer3real::trigger_cb (this=0x6833d0, w=..., revents=<optimized out>)
at layer3.cpp:373
#3 0x00007ffff79b4d73 in ev_invoke_pending () from /usr/lib/x86_64-linux-gnu/libev.so.4
#4 0x00007ffff79b83de in ev_run () from /usr/lib/x86_64-linux-gnu/libev.so.4
#5 0x0000000000403736 in main (ac=8, ag=0x7fffffffe438) at knxd.cpp:714

Ich hab' jetzt mal ganz dreckig das "delete l" im layer4.cpp:517 auskommentiert und dann scheint es zu laufen?
Bin nicht mehr fit in C++, sehe nur dass das Objekt l bei Aufruf als Parameter instantiiert wird und dann in der aufgerufenen Funktion gelöscht wird.
Ist das sauber?

[Smurf]

Ja, ist der aktuelle Master (heute gepullt und gebaut).

Hier der Stacktrace:
[CODE]knxd: Layer 7 [ 7:inet 12.504] CloseGroupSocket
knxd: Layer 2 [ 6:ip: 12.504] Send L_Data low from 0.0.1 to 1/3/2 hops: 05 T_DATA_XXX_REQ A_GroupValue_Read
knxd: Layer 1 [ 6:ip: 12.504] Send(011): 29 00 BC D0 00 01 0B 02 01 00 00

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) whe
#0 0x0000000000000000 in ?? ()
#1 0x00000000004513ba in GroupSocket::send_L_Data (this=this@entry=0x68c760, l=l@entry=0x68c6b0)
at layer4.cpp:517

Seltsam. Kann ich nicht reproduzieren. Ist das x86? dann lass ihn bitte mal unter valgrind laufen.

# valgrind  src/server/knxd -t 1022 -e …usw…

und schick mir den gesamten Output (pastebin).

[itarch]

Smurf
können wir für die Doku das Schaubild gebrauchen.
Mir hilft so etwas immer wieder nach langen Pausen
Vollständig (bild- und textlich) ist es nicht
Darüberhinaus denke ich drüber nach ob nicht eine "Support-Matrix" hilfreich wäre.
... KNXD-COM.0.1.0.jpg

[umatz]

Unter valgrind läuft knxd im selben Szenario (Start von smarthome.py mit initialem Einlesen aller KNX-Objkete) ohne Absturz und nur wenig valgrind Meldungen:

==6913== Source and destination overlap in memcpy(0x70b2340, 0x70b2344, 128)
==6913==    at 0x4C32513: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6913==    by 0x4521FE: memcpy (string3.h:53)
==6913==    by 0x4521FE: RecvBuf::feed_out() (iobuf.cpp:116)
==6913==    by 0x5055D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x50593DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x403735: main (knxd.cpp:714)
==6913==
==6913== Conditional jump or move depends on uninitialised value(s)
==6913==    at 0x421AC3: Layer3real::trigger_cb(ev::async&, int) (layer3.cpp:319)
==6913==    by 0x5055D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x50593DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x403735: main (knxd.cpp:714)
==6913==  Uninitialised value was created by a heap allocation
==6913==    at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6913==    by 0x4401D2: CreateGroupCache(Layer3*, std::shared_ptr<Trace>, bool, unsigned short) (groupcacheclient.cpp:30)
==6913==    by 0x405CB0: parse_opt(int, char*, argp_state*) (knxd.cpp:485)
==6913==    by 0x590B816: group_parse (argp-parse.c:257)
==6913==    by 0x590B816: parser_parse_opt (argp-parse.c:755)
==6913==    by 0x590B816: parser_parse_next (argp-parse.c:867)
==6913==    by 0x590B816: argp_parse (argp-parse.c:921)
==6913==    by 0x40361C: main (knxd.cpp:673)
[...]
==6913== LEAK SUMMARY:
==6913==    definitely lost: 0 bytes in 0 blocks
==6913==    indirectly lost: 0 bytes in 0 blocks
==6913==      possibly lost: 0 bytes in 0 blocks
==6913==    still reachable: 79,064 bytes in 12 blocks
==6913==         suppressed: 0 bytes in 0 blocks
==6913== Reachable blocks (those to which a pointer was found) are not shown.
==6913== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6913==
==6913== ERROR SUMMARY: 222 errors from 2 contexts (suppressed: 0 from 0)
==6913==
==6913== 111 errors in context 1 of 2:
==6913== Conditional jump or move depends on uninitialised value(s)
==6913==    at 0x421AC3: Layer3real::trigger_cb(ev::async&, int) (layer3.cpp:319)
==6913==    by 0x5055D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x50593DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x403735: main (knxd.cpp:714)
==6913==  Uninitialised value was created by a heap allocation
==6913==    at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6913==    by 0x4401D2: CreateGroupCache(Layer3*, std::shared_ptr<Trace>, bool, unsigned short) (groupcacheclient.cpp:30)
==6913==    by 0x405CB0: parse_opt(int, char*, argp_state*) (knxd.cpp:485)
==6913==    by 0x590B816: group_parse (argp-parse.c:257)
==6913==    by 0x590B816: parser_parse_opt (argp-parse.c:755)
==6913==    by 0x590B816: parser_parse_next (argp-parse.c:867)
==6913==    by 0x590B816: argp_parse (argp-parse.c:921)
==6913==    by 0x40361C: main (knxd.cpp:673)
==6913==
==6913==
==6913== 111 errors in context 2 of 2:
==6913== Source and destination overlap in memcpy(0x70b2340, 0x70b2344, 128)
==6913==    at 0x4C32513: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6913==    by 0x4521FE: memcpy (string3.h:53)
==6913==    by 0x4521FE: RecvBuf::feed_out() (iobuf.cpp:116)
==6913==    by 0x5055D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x50593DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==6913==    by 0x403735: main (knxd.cpp:714)

Ich vermute, dass es etwas mit dem unter valgrind stark verzögerten Durchsatz zu tun hat; ohne valgrind lässt sich der segmentation fault im knxd bei jedem Start von smarthome.py reproduzieren. Vielleicht eine Nebenläufigkeit die zum Problem führt und beim langsameren Laufen unter valgrind nicht auftritt?

[umatz]

können wir für die Doku das Schaubild gebrauchen.

Das Bild finde ich super!

[Smurf]

Vielleicht eine Nebenläufigkeit die zum Problem führt und beim langsameren Laufen unter valgrind nicht auftritt?

Hmm. Ich liebe Heisenbugs.

Mach mal Folgendes:
in debian/rules: am Ende der configure-Argumente anhängen:

CFLAGS="-g -O0" CXXFLAGS="-g -O0"

dann neu bauen, unter gdb laufen lassen, Stacktrace wie gehabt. Wenn der genauso aussieht:
gdb> fr 1
gdb> inf reg
gdb> disass

und mir schicken (pastebin).