knxd (war: eibd) reloaded: Tester gesucht

[Tru]

mit welchen Optionen startest du den knxd?

normalerweise mit

-D -T -S -d -i --pid-file=$PIDFILE ipt:192.168.1.20

Ich habe keine Layer2 Schnittstelle.

(gdb) r ipt:192.168.1.20
Starting program: /sw/pkgs/knxd_multi_l2/bin/knxd ipt:192.168.1.20
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
EIBNetIPTunnel::EIBNetIPTunnel (this=0x68b820, dest=0x66a030 "192.168.1.20", port=3671, sport=3672, srcip=0x0, Dataport=-1,
    opt=0x666df4 <arg+52>, l3=0x67b0d0) at eibnettunnel.cpp:28
28        TRACEPRINTF (t, 2, this, "Open");
(gdb) where
#0  EIBNetIPTunnel::EIBNetIPTunnel (this=0x68b820, dest=0x66a030 "192.168.1.20", port=3671, sport=3672, srcip=0x0, Dataport=-1,
    opt=0x666df4 <arg+52>, l3=0x67b0d0) at eibnettunnel.cpp:28
#1  0x0000000000404823 in eibnetiptunnel_Create (dev=<optimized out>, opt=0x666df4 <arg+52>, l3=0x67b0d0) at b-EIBNETIPTUNNEL.h:89
#2  0x00000000004039e9 in parse_opt (key=<optimized out>, arg=0x7fffffffe912 "ipt:192.168.1.20", state=<optimized out>) at knxd.cpp:427
#3  0x00007ffff790563b in group_parse (arg=0x7fffffffe912 "ipt:192.168.1.20", key=0, state=0x7fffffffe4a0, group=0x67ac00)
    at argp-parse.c:257
#4  parser_parse_arg (val=0x7fffffffe912 "ipt:192.168.1.20", parser=0x7fffffffe430) at argp-parse.c:693
#5  parser_parse_next (arg_ebadkey=<synthetic pointer>, parser=0x7fffffffe430) at argp-parse.c:865
#6  __argp_parse (argp=<optimized out>, argc=<optimized out>, argv=<optimized out>, flags=<optimized out>, end_index=0x7fffffffe558,
    input=0x666dc0 <arg>) at argp-parse.c:921
#7  0x0000000000402e92 in main (ac=2, ag=0x7fffffffe6d8) at knxd.cpp:490

[Smurf]

ipt: ist heutzutage eine Layer2-Schnittstelle. ;-)

Der Fehler wird sogleich behoben.

[Smurf]

(Hoffentlich) repariert: e5f8001

[Tru]

(Hoffentlich) repariert: e5f8001

Ja, sieht sehr gut aus: kompiliert ohne jede Warning-Meldung und startet soweit problemlos. Via vbusmonitor1 bekomme ich auch die Telegramme angezeigt.
Mangels Bus-Schnittstellen und mangels Labor-Umgebung bin ich damit ausgeschossen. Vielleicht findet sich noch jemand anders, der diese Version in die Tiefe prüfen kann.

Tolle Leistung, du bist ausserordentlich fleissig. Ich hoffe andere wissen das auch zu würdigen.

[Smurf]

Danke für die Blumen.
Und ich bin noch nicht fertig … siehe TODO; ich hoffe ja, dass sich auch jemand anders ein bisschen anstrengt. :-P

Mein Elektriker turnt ab nächster Woche hier herum und pflanzt KNX in die Wände. Dann werde ich sicher noch das eine oder andere Problemchen finden.

Einen habe ich schon: Programmiermodus geht nur an einem Bus, weil ich mir merke, dass das Opfer mit seiner speziellen Adresse (alle Bits gesetzt) an Bus A ist, und findet dann das Gerät an Bus B nicht mehr.

Ach ja: ein bisschen Doku zu dem Ganzen wäre auch nicht schlecht …

[Tru]

Danke für die Blumen.

Vielleicht ein bisschen voreilig.
Ich habe heute sowohl den aktuellen master wie auch multi_l2 mal produktiv ausprobieren wollen. Leider sind beide Versionen unbrauchbar.

Bei beiden Versionen zeigt vbusmonitor1 den Verkehr auf dem Bus soweit noch korrekt an.
Anders, wenn ich mit groupswrite einen Befehl abschicke:
master: sofortiger unendlicher Loop, habe auch grosse Mühe den knxd Prozess zu stoppen
multi_l2: keine Reaktion, auch keine Anzeige eines Telegramms für den Befehl.

Sieht also nicht gut aus. knxd hatte ich seit Beginn erfolgreich verwendet. Ich bin jetzt wieder zurück auf Commit 3d3b1a5e8112397d297625d673a2a94507f9ebce gegangen und siehe da: hier funkioniert alles noch wunderbar. Ich denke es wäre dringend nötig den master wieder in Ordnung zu bringen.

[Smurf]

Hmm. Bitte schick mir die groupswrite-Befehlszeile, die du verwendest.
Mit welcher Gegenstelle verbindest du dich mit dem "ipt:"? Ich nehme an das ist ein knx-Gateway irgendwo auf einer Hutschiene?
Kannst du mal mit einem wireshark mittracen, was da passiert, wenn überhaupt? (Pakettrace in eine Datei schreiben und mir mailen)?
Kannst du die Experimente mit "-t 65535" wiederholen und mir die Resultate schicken (am besten als Mail)?

Mailadresse: matthias@urlichs.de

[Tru]

Kannst du die Experimente mit "-t 65535" wiederholen und mir die Resultate schicken (am besten als Mail)?
[/email]

Ich schicke den Befehl "groupswrite ip:localhost 1/0/24 0" und die Gegenstelle ist ein Siemens N350E. Mit dem Master wiederhole ich nicht, da läuft meine Wohnung Amok, aber mit dem multi_l2 Branch kann ich es versuchen.

[Smurf]

OK. Ich versuche das mal im Master und meinem enertex-Gateway (und/oder einem knxd) nachzustellen.

[Smurf]

Autsch.

Was passiert:
* groupswrite generiert per Default Pakete mit hopcount=7. Der wird nicht runtergezählt. Das ist so spezifiziert.
* knxd schickt das an deinen Gateway
* der schickt es auch auf den Multicast
* wo es der knxd liest (weil -S)
* … und weiterschickt (obwohl -nicht -R)
… was in der Summe einen Ring mit assoziiertem Paketsturm generiert.

Im multi_l2 trat das Problem nicht auf, weil ich da zwei Zeilen vergessen habe.

Erste Abhilfe: Mach das -D -T -S weg. Multicast wird bereits von deinem Siemensadapter bedient.

Zweite Abhilfe: ich werde mich (später) dahinterklemmen und nachsehen, wieso er das fehlende -R nicht mehr berücksichtigt. (Zumindest nehme ich an, dass das dein Problem ist, d.h. der Paketsturm sollte auch auftreten, wenn du einen "alten" knxd verwendest und -R mit angibst. Nein, ich fordere dich NOCH nicht auf, das nachzuprüfen.)

Dritte Abhilfe: ohne spezielles Flag-Argument sollte nichts und niemand auf die Idee kommen, Pakete mit Hopcount 7 zu generieren. (Wobei mir kein gutes Argument einfällt, wozu man das in einem normalen KNX-Netz überhaupt braucht, und ich ernsthaft überlege, diese Abfrage rauszuwerfen bzw. nur mit einem Spezialflag einzuschalten.)

EDIT: Die Analyse ist wohl unvollständig, irgendwas Anderes passiert da außerdem. Ich bin dran … muss jetzt aber erstmal ins Bett. :-/

[Smurf]

OK, Masterzweig ist geupdatet. Das Problem war viel simpler -- der Tunnel-Treiber hat die gesendeten Pakete einfach auch geechot, als ob er sie empfangen hätte.
(Der tpuart macht das ja von Haus aus. Anscheinend war jemand der Meinung, das müssten alle anderen Adapter gefälligst nachmachen. Wieso auch immer.)

[Smurf]

multi_l2 ist auch uptodate; das Hopcount-Verringern passiert jetzt da wo es hingehört.

Tru: ich habe das Ganze mit deinen Flags getestet, funktioniert.

[Tru]

OK, Masterzweig ist geupdatet.

multi_l2 ist auch uptodate

Das ging ja fix.
Du hast mein Vertrauen zurück Ich habe sowohl master wie auch multi_l2 heute frisch gebaut und in meiner Umgebung getestet. Beide funktionieren soweit wie gewohnt. Es gibt nur eine kleine Einschränkung: bei multi_l2 kann ich vbusmonitor1 nicht mehr dazu starten, ich erhalte "Open Busmonitor failed: Device or resource busy". Beim master hingegen geht das problemlos. Diesen Daemon lasse ich jetzt produktiv laufen.

BTW: mein N350E unterstützt nur 1 Tunnel und kein Routing. Dafür würde ich ja knxd verwenden wollen. Ich würde erwarten, dass mit -R ein Listener auf der Default-Multicast-Adresse gestartet würde, kann aber mit netstat -anu nichts davon sehen.

[DerSeppel]

Bootstrap schmeißt das hier:

src/client/c/Makefile.am:5: warning: source file 'gen/getapdu.c' is in a subdirectory,
src/client/c/Makefile.am:5: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/client/c/Makefile.am:5: warning: source file 'gen/loadimage.c' is in a subdirectory,
src/client/c/Makefile.am:5: but option 'subdir-objects' is disabled
src/client/c/Makefile.am:5: warning: source file 'gen/mcpropertyread.c' is in a subdirectory,
src/client/c/Makefile.am:5: but option 'subdir-objects' is disabled

automake (GNU automake) 1.14.1

Aber danke für die Arbeit!

[eib1607]

Ich habe heute mal den multi_l2 ausprobiert und bei mir schmeisst der nen seg fault. Arbeite hier noch mit Debian 7 (Wheezy)

Hier mal die Debug Infos

root@Raspi-EIBBridge:/home/pi/eib/knxd/src/server# ./knxd -t 1023 -i ipt:192.168.3.229
Layer 3(00E39C18,5573DC64) Open
Layer 8(00E4A190,5573DC64) OpenInetSocket 6720
Layer 8(00E4A190,5573DC64) InetSocket opened
Layer 2(00E5A6A0,5573DC64) Open
Layer 0(00E5AB70,5573DC64) Open
Layer 0(00E5AB70,5573DC64) Close
Layer 0(00E5AB70,5573DC64) Openend
Layer 2(00E5A6A0,5573DC64) Opened
Layer 3(00E39C18,5573DC64) registerLayer2 00E5A6A0
Layer 3(00E39C18,5573DC64) registerLayer2 00E5A6A0 = 1
Layer 3(00E39C18,5573DC64) L3 started
Speicherzugriffsfehler
root@Raspi-EIBBridge:/home/pi/eib/knxd/src/server# gdb knxd
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/pi/eib/knxd/src/server/knxd...done.
(gdb) r -t 1023 -S -D -T -i ipt:192.168.3.229
Starting program: /home/pi/eib/knxd/src/server/knxd -t 1023 -S -D -T -i ipt:192.168.3.229
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Layer 3(00068C18,5573DD15) Open
Layer 8(00079190,5573DD15) Open
Layer 0(00079638,5573DD15) Open
Layer 0(00079638,5573DD15) Close
Layer 0(00079638,5573DD15) Openend
Layer 3(00068C18,5573DD15) L3 started

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x00017d74 in Thread::Run (this=<optimized out>, stop=<optimized out>) at threads.cpp:99
#2  0x00017d90 in Thread::ThreadWrapper (arg=0x79638) at threads.cpp:27
#3  0xb6fb22ec in pth_spawn_trampoline () at pth_lib.c:216
#4  0xb6d3c1a0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6
#5  0xb6d3c1a0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Ausserdem klappt bei mir die Sache mit dem Package nicht mehr.

root@Raspi-EIBBridge:/home/pi/eib/knxd# dpkg-buildpackage -b
dpkg-buildpackage: Quellpaket knxd
dpkg-buildpackage: Quellversion 0.10.0-1
dpkg-buildpackage: Quellen geändert durch Matthias Urlichs <matthias@urlichs.de>
dpkg-buildpackage: Host-Architektur armhf
 dpkg-source --before-build knxd
 debian/rules clean
debian/rules:18: *** missing separator (did you mean TAB instead of 8 spaces?).  Schluss.
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules clean war 2

bin nicht so wirklich fit mit diesen Dingen. Fange erst an in die Linux Entwicklung rein zu schnuppern ....

Vielleicht könnte mir ja einer die Kommandos geben die Ihr zum Abrufen der aktuellen Stände und zum übersetzten verwendet. Wäre echt hilfreich.

Danke schon mal :

Thomas