eibd antwortet nicht

[hausbau]

Hallo zusammen,

an meinen PC mit Ubuntu 13.10 (64 bit) habe ich ein MDT USB Interface angeschlossen und möchte dafür nun den eibd einrichten, allerdings reagiert dieser nicht.

Installiert habe ich die Pakete aus dem PPA von Martin Kögler (Version für Ubuntu 11.10, weil es keine neuere gibt). Eine udev-Regel habe ich angelegt, damit ich als normaler Benutzer auf das USB-Device zugreifen darf. "findknxusb" findet auch das MDT-Device (weshalb ich davon ausgehe, dass es nichts mit dem nicht vorhandenen usbfs zu tun hat, wie im Lexikon beschrieben):

device: 1:4:1:0:0 (MDT Technologies GmbH:KNX-USB Inteface)

Den eibd starte ich dann wie folgt:

eibd -d -D -S -T -i usb:1:4:1

Greife ich dann bspw. mit "groupswrite ip:localhost 1/1/1 1" darauf zu, so bekomme ich die Fehlermeldung "Open failed: Connection refused".

Sehr seltsam ist, dass "lsof -p nnnn" für den eibd kein IPv4 oder IPv6 Handle auflistet. Wenn ich den Daemon mit "eibd -u /tmp/eib usb:1:4:1" starte, müsste ich nach meinem Verständnis die Datei /tmp/eib vorfinden. Aber auch das ist nicht der Fall. "lsof -p nnnn" listet dementsprechend auch kein Handle dafür auf.

Hier nochmal die Daten:

$ eibd -d -D -S -T -i usb:1:4:1
$ lsof -p 2836
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
eibd    2836 martin  cwd    DIR    8,5     4096 2488062 /home/martin/MyProjects/Haus
eibd    2836 martin  rtd    DIR    8,5     4096       2 /
eibd    2836 martin  txt    REG    8,5   411160 2733869 /usr/bin/eibd
eibd    2836 martin  mem    REG    8,5    88408   67120 /lib/x86_64-linux-gnu/libgcc_s.so.1
eibd    2836 martin  mem    REG    8,5  1067424   65906 /lib/x86_64-linux-gnu/libm-2.17.so
eibd    2836 martin  mem    REG    8,5  1852120   65909 /lib/x86_64-linux-gnu/libc-2.17.so
eibd    2836 martin  mem    REG    8,5   975216 2733472 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
eibd    2836 martin  mem    REG    8,5    72272 2733865 /usr/lib/libpthsem.so.20.0.28
eibd    2836 martin  mem    REG    8,5   149312   65888 /lib/x86_64-linux-gnu/ld-2.17.so
eibd    2836 martin    0r  FIFO    0,8      0t0   16649 pipe
eibd    2836 martin    1w   CHR    1,3      0t0    6146 /dev/null
eibd    2836 martin    2w   CHR    1,3      0t0    6146 /dev/null
eibd    2836 martin    3r  FIFO    0,8      0t0   17537 pipe
eibd    2836 martin    4w  FIFO    0,8      0t0   17537 pipe
eibd    2836 martin    5w  FIFO    0,8      0t0   16649 pipe
eibd    2836 martin    6u   CHR  189,4      0t0   13226 /dev/bus/usb/001/004

Der Daemon scheint also irgendwo beim Initialisieren hängen zu bleiben. Und zwar, bevor er einen Unix-Socket oder IPv4-Socket öffnet.

Hat jemand eine Idee, was hier falsch laufen könnte?

Gruß,
Martin

[DiMa]

Das ist zwar auch keine Lösung, aber hast du meine Beiträge zum Thema eibd mit cEMI schon gelesen?

[toggle]

Schalte den Tracemodus ein (z.B. -t4 , ohne -d).

[hausbau]

Hallo zusammen,

der Hinweis auf den cEMI-Patch scheint wohl die entscheidende Information zu sein, die mir bisher gefehlt hat. Wenn man in diese Richtung sucht, findet man einige Posts, dass dieser Patch scheinbar zwingend notwendig ist für das MDT USB-Interface.

Nach einigem Trial & Error ist es mir nun auch gelungen, das bcusdk mit diesem Patch unter Ubuntu zu kompilieren. Bin schon gespannt, ob ich damit weiter komme. Testen kann ich erst morgen.

Gruß,
Martin

[hausbau]

Hallo zusammen,

leider bekomme ich den eibd mit der USB-Schnittstelle von MDT nicht zum Laufen.

Ich habe den aktuellen git-Stand genommen und den Patch "bcusdk-usb-cemi.patch" darauf angewandt. Nachdem das dann noch nicht funktioniert hat, habe ich auch noch einen zweiten Patch "read-within-callback.patch" angewandt, aber das Ergebnis ist das selbe:

Beim ersten Start sendet der eibd mehrfach Daten an die Schnittstelle ("Send") und erhält auch Antworten ("Recv"). Dann kommt es aber zu einem jähen Ende:

Layer 10(00999DD0,52C40643) USBLoop-Create
Layer 1(009AA460,52C40643) Detect
Layer 1(009AA460,52C40643) Using 1:5:1:0:0 (1:130)
Layer 1(009AA460,52C40643) Open
...
Layer 0(009AA460,52C40643) StartSend
Layer 1(009AC260,52C40643) CEMI
Layer 2(009AC290,52C40643) Open
Layer 2(009AC290,52C40643) Opened
Layer 3(009AC930,52C40643) Open
Layer 2(009AC290,52C40643) (CEMILayer2Interface) Open
Layer 8(009AB000,52C40643) OpenInetSocket 6720
Layer 8(009AB000,52C40643) InetSocket opened
Layer 8(009AD5B0,52C40643) Open
Layer 0(009ADA90,52C40643) Open
Layer 0(009ADA90,52C40643) Openend
Layer 0(009ADA90,52C40643) Close
initilization of the EIBnet/IP server failed

Starte ich den eibd mit identischen Parametern ("eibd --trace=65535 -D -S -T -i usb:1:5:1") erneut, so bleibt er schon deutlich früher bei der Initialisierung in einer Endlosschleife hängen:

Layer 10(009C8DD0,52C40A75) USBLoop-Create
Layer 1(009D9460,52C40A75) Detect
Layer 1(009D9460,52C40A75) Using 1:5:1:0:0 (1:130)
Layer 1(009D9460,52C40A75) Open
Layer 1(009D9460,52C40A75) Claimed
Layer 1(009D9460,52C40A75) Opened
Layer 1(009D9460,52C40A75) Send(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 10(009C8DD0,52C40A75) LoopStart
Layer 10(009C8DD0,52C40A75) LoopBegin
Layer 10(009C8DD0,52C40A75) LoopWait
Layer 0(009D9460,52C40A75) StartRecv
Layer 0(009D9460,52C40A75) Send(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(009D9460,52C40A75) StartSend
Layer 10(009C8DD0,52C40A75) LoopProcess
Layer 10(009C8DD0,52C40A75) LoopEnd
Layer 10(009C8DD0,52C40A75) LoopBegin
Layer 10(009C8DD0,52C40A75) LoopWait
Layer 0(009D9460,52C40A75) SendComplete 64
Layer 10(009C8DD0,52C40A93) LoopProcess
Layer 10(009C8DD0,52C40A93) LoopEnd
Layer 10(009C8DD0,52C40A93) LoopBegin
Layer 10(009C8DD0,52C40A93) LoopWait
Layer 10(009C8DD0,52C40A93) LoopProcess
Layer 0(009D9460,52C40A93) RecvError 2
Layer 0(009D9460,52C40A93) StartRecv
Layer 10(009C8DD0,52C40A93) LoopEnd
Layer 10(009C8DD0,52C40A93) LoopBegin
Layer 10(009C8DD0,52C40A93) LoopWait

Es geht dann endlos mit "RecvError 2" und dieser Loop weiter. Es kommt kein einziges Mal eine "Recv"-Meldung.

Gruß,
Martin

[hausbau]

Hallo zusammen,

nach etlichem Basteln möchte ich meinen aktuellen Stand zusammen fassen, um evtl. anderen, die auf der Suche nach "eibd mdt usb" sind, ein paar Anhaltspunkte geben zu können.

• Für das MDT USB Interface wird der cEMI-Patch benötigt. Da sich seit dem Release 0.0.5 des bcusdk der Zugriff auf Layer 2 etwas geändert hat, muss der Patch auf die aktuellen Quellen angewandt werden ("git clone git://bcusdk.git.sourceforge.net/gitroot/bcusdk/bcusdk").
• An anderer Stelle habe ich etwas von einem USB-Patch gelesen. Ob dieser benötigt wird, weiß ich nicht. Deshalb habe ich es jeweils mal mit und mal ohne diesen Patch versucht, wobei ich aber keine Unterschiede feststellen konnte.

Bei allen Tests war das Ergebnis gleich: Siehe mein Post vom 01.01.

Versucht habe ich das unter

• Ubuntu 13.04 64-Bit mit Kernel 3.8.*
• Debian 5 32-Bit mit Kernel 2.6.*
• Debian 6 32-Bit mit Kernel 2.6.*
• Ubuntu 10.04 32-Bit mit Kernel 2.6.*

Der Fehler hat also nichts mit der verwendeten Kernel- und Distri-Version zu tun. Eine Vermutung von mir war, dass sich der Kernel im USB-Code entscheidend geändert haben könnte, was aber nicht zutrifft.

Vielleicht finde ich noch die Lust, mich durch den Quellcode zu wühlen und den cEMI-Patch genauer anzuschauen. Im Moment tendiere ich aber eher dazu, ein Weinzierl 730 IP Interface zu kaufen, um das Problem dauerhaft abzuhaken.

Gruß,
Martin

[toggle]

So ein Verhalten hatte ich, als bei mir keine Default-Route gesetzt war. Ich konnte es gerade eben durch das Löschen der Default-Route reproduzieren (allerdings ohne eine USB-Schnittstelle).

fritz@sp2fritz:~$ route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.188.0   *               255.255.255.0   U     0      0        0 eth5
link-local      *               255.255.0.0     U     1000   0        0 eth5
default         fritz.box       0.0.0.0         UG    100    0        0 eth5
fritz@sp2fritz:~$ sudo route delete default
fritz@sp2fritz:~$

Und anschließend

fritz@sp2fritz:~$ eibd -t65535 -D -T -S -i --eibaddr=1.1.150 ip:
Layer 2(094D2668,52D4458B) Open
Layer 0(094D26F0,52D4458B) Open
Layer 0(094D26F0,52D4458B) Openend
Layer 3(094E2EE8,52D4458B) Open
Layer 8(094F3278,52D4458B) OpenInetSocket 6720
Layer 8(094F3278,52D4458B) InetSocket opened
Layer 8(095035E8,52D4458B) Open
Layer 0(09503658,52D4458B) Open
Layer 0(09503658,52D4458B) Openend
Layer 0(09503658,52D4458B) Close
initilization of the EIBnet/IP server failed

[hausbau]

Hallo zusammen,

So ein Verhalten hatte ich, als bei mir keine Default-Route gesetzt war. Ich konnte es gerade eben durch das Löschen der Default-Route reproduzieren

danke toggle, das war jetzt der Übertipp!

Ich habe meine ganze Versuchsreihe mit "-D -S -T -i" durchgeführt. Allerdings habe ich im neuen Haus noch kein Netzwerk und somit auch keine Default-Route.

Habe es gerade mit einem Unix-Socket erfolgreich probiert ("-u"): Wie erwartet habe ich die Datei "/tmp/eibd" erhalten. Danach habe ich eine Dummy-Default-Route gesetzt, den eibd mit "-D -S- T -i" gestartet und es hat tatsächlich geklappt: Eine in VMware laufende ETS4 hat den eibd gefunden, der auf dem Host lief :-)

Getestet habe ich jetzt mit Ubuntu 13.04 64-Bit und den beiden Patches (cEMI und USB).

Da ich nun erst mal kein KNX-IP-Interface kaufen muss, habe ich das zum Anlass genommen, einen Teil des gesparten Geldes an das Forum zu spenden. Die Spende ging gerade raus.

Gruß,
Martin