Ankündigung

Einklappen
Keine Ankündigung bisher.

Zugriff mit NSLU2 + USB + eibd

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • EIBman
    antwortet
    Hallo,

    so, nach mehr als 1 Jahr bin ich zurück aus der Versenkung und kann Erfolge berichten:

    1. Gentoo, wegen unkomplizierterer Buildumgebung auf dem NSLU2 installiert (mit "schlankem" Portage) --> wer möchte, dem kann ich gerne ein Image zur Verfügung stellen... hat ewig gedauert und da ich nur an Wochenenden Zeit dazu habe, ...
    2. pthsem aus dem GIT-master-Branch auf dem NSLU2 kompiliert. Dabei gab es einige Steine aus dem Weg zu räumen:
    2.a Analog zu dem Fix in pth die Compilerflags auf dem ARM - also {C,CXX,F,FC}FLAGS - um "-U_FORTIFY_SOURCE" erweitert, sonst steigen Programme, die pthsem nutzen, mit "longjmp causes uninitialized stack frame" aus (siehe Bug 350815 – dev-libs/pth with fortify source breaks gnupg (longjmp causes uninitialized stack frame) on arm/sh). Eine weitere Diskussion zu dem Thema bzw. Details gibt es auch unter https://bugs.launchpad.net/ubuntu/+s...g2/+bug/599862.
    2.b entsprechendes ebuild geschrieben/korrigiert (dev-libs/pthsem-9999.ebuild):
    Code:
    EAPI=2
    
    inherit autotools git eutils flag-o-matic
    
    EGIT_REPO_URI="http://www.auto.tuwien.ac.at/~mkoegler/git/pthsem.git"
    
    DESCRIPTION="extended version of GNU pth (user mode multi threading library)"
    HOMEPAGE="http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth"
    
    LICENSE="LGPL"
    SLOT="0"
    KEYWORDS=""
    IUSE=""
    
    DEPEND=""
    RDEPEND=""
    
    src_configure() {
        cd "${S}"
        ( use arm || use sh ) && append-flags -U_FORTIFY_SOURCE
        eautoreconf
        econf || die "econf failed"
    }
    
    src_compile() {
        cd "${S}"
        emake || die "make failed"
    }
    
    src_install() {
        emake DESTDIR="${D}" install || die "install failed"
        dodoc ANNOUNCE AUTHORS ChangeLog NEWS README THANKS USERS
    }
    2.c pthsem installiert/kompiliert mit "emerge pthsem"
    Anm.: für den NSLU2 muss das USE-Flag "arm" gesetzt sein
    3. eibd aus dem GIT-bcusdk-master-Branch auf dem NSLU2 kompiliert. Dazu habe ich auch einige Steine aus dem Weg räumen müssen:
    3.a Der pthsem-Test funktioniert auch auf meinem Gentoo-NSLU2 nicht. Ich verstehe das zwar nicht, aber man kann ihn ruhigen Gewissens abdrehen mit "./configure --without-pth-test ..."
    3.b entsprechendes ebuild geschrieben/korrigiert (sys-apps/eibd-9999.ebuild):
    Code:
    # Copyright 1999-2007 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    # $Header: $
    
    inherit eutils autotools git
    
    DESCRIPTION="Provides an interface to the EIB / KNX bus (latest git)"
    HOMEPAGE="http://www.auto.tuwien.ac.at/~mkoegler/index.php/eibd"
    
    LICENSE="GPL-2"
    SLOT="0"
    KEYWORDS=""
    IUSE="eibd ft12 pei16 tpuart pei16s tpuarts eibnetip eibnetiptunnel eibnetipserver
    usb groupcache php python java tools"
    
    DEPEND="dev-libs/pthsem"
    
    EGIT_REPO_URI="http://www.auto.tuwien.ac.at/~mkoegler/git/bcusdk.git/"
    EGIT_PROJECT="bcusdk"
    
    src_compile() {
        eautoreconf || die "eautotooling failed"
    
        econf \
            --enable-onlyeibd \
            --without-pth-test \
            $(use_enable ft12) \
            $(use_enable pei16) \
            $(use_enable tpuart) \
            $(use_enable pei16s) \
            $(use_enable tpuarts) \
            $(use_enable eibnetip) \
            $(use_enable eibnetiptunnel) \
            $(use_enable eibnetipserver) \
            $(use_enable usb) \
            $(use_enable java) \
            $(use_enable groupcache) || die "econf failed"
    }
    
    src_install() {
        emake DESTDIR="${D}" install || die "install bcusdk failed"
    
        if use python; then
            einfo "Installing python module"
            cd ${D}/contrib/swig
            emake || die "could not compile python module"
            emake install
        fi
            
        einfo "Installing init-script and config"
        cd ${S}/contrib/gentoo/etc/
        exeinto /etc/init.d/
        doexe init.d/eibd
        
        insinto /etc/conf.d/
        doins conf.d/eibd
    
    }
    3.c leider reicht mein Verständnis dafür nicht, aber man muss zum installieren noch die "Sandkiste" abstellen, sonst schlägt die Installation fehl...
    3.d eibd installiert/kompiliert mit "FEATURES="-sandbox" emerge eibd"
    Anm.: bei mir sind folgende USE-Flags gesetzt: eibd eibnetip eibnetiptunnel eibnetipserver usb groupcache python java tools
    3.e noch schnell die /etc/conf.d/eibd angepasst: EIBD_OPTS="-d -R -D -S -T -i usb:"
    3.f eibd gestartet: /etc/init.d/eibd start
    3.g eibd auch beim nächsten Systemstart starten: rc-update add eibd default
    4. probiert, ob eibd auch auf den Bus kommt: /usr/bin/groupswrite ip:localhost x/y/z 1, wobei x/y/z die Gruppenadresse einer x-beliebigen Lampe ist
    5. Andere Programme wie z.B. LinKNX kompiliert/installiert (nicht Thema dieses Threads), ETS3 auf einem anderen PC, der im selben Netzt hängt zum Laufen gebracht, etc. ...

    Grüße,
    Stefan

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    war 3 Tage weg, deshalb erst jetzt.

    Den neuen Snapshot habe ich heruntergeladen und versucht zu kompilieren:
    pthsem 2.0.8 wurde beim ./configure aber gefunden (in /opt).

    Muss für pthsem noch eine Umgebungsvariable gesetzt sein?
    Wurde der pth-Test abgedreht?
    Ich würde gerne einmal config.log und config.status sehen, um mir die Einstellungen anzuschauen. Ansich sollte es ohne alle Tricks funktionieren.

    CrossCompiling ? BCU SDK with eibd zeigt, wie man Suchpfad an configure übergeben kann.

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    war 3 Tage weg, deshalb erst jetzt.

    Den neuen Snapshot habe ich heruntergeladen und versucht zu kompilieren:
    Code:
    Making all in usb
    make[3]: Entering directory `/root/bcusdk/eibd/usb'
    g++ -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -fno-rtti -fno-exceptions -MT usb.o -MD -MP -MF .deps/usb.Tpo -c -o usb.o usb.cpp
    mv -f .deps/usb.Tpo .deps/usb.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o core.c
    mv -f .deps/core.Tpo .deps/core.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT descriptor.o -MD -MP -MF .deps/descriptor.Tpo -c -o descriptor.o descriptor.c
    mv -f .deps/descriptor.Tpo .deps/descriptor.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT io.o -MD -MP -MF .deps/io.Tpo -c -o io.o io.c
    mv -f .deps/io.Tpo .deps/io.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT sync.o -MD -MP -MF .deps/sync.Tpo -c -o sync.o sync.c
    mv -f .deps/sync.Tpo .deps/sync.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT linux_usbfs.o -MD -MP -MF .deps/linux_usbfs.Tpo -c -o linux_usbfs.o linux_usbfs.c
    mv -f .deps/linux_usbfs.Tpo .deps/linux_usbfs.Po
    g++ -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -fno-rtti -fno-exceptions -MT dummy.o -MD -MP -MF .deps/dummy.Tpo -c -o dummy.o dummy.cpp
    mv -f .deps/dummy.Tpo .deps/dummy.Po
    rm -f libusb.a
    ar cru libusb.a usb.o core.o descriptor.o io.o sync.o linux_usbfs.o dummy.o 
    ranlib libusb.a
    g++ -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -fno-rtti -fno-exceptions -MT findknxusb.o -MD -MP -MF .deps/findknxusb.Tpo -c -o findknxusb.o findknxusb.cpp
    mv -f .deps/findknxusb.Tpo .deps/findknxusb.Po
    g++  -g -O2 -fno-rtti -fno-exceptions   -o findknxusb findknxusb.o libusb.a -lpthsem 
    /opt/armeb/lib/gcc-lib/armv5b-softfloat-linux/3.3.5/../../../../armv5b-softfloat-linux/bin/ld: cannot find -lpthsem
    collect2: ld returned 1 exit status
    make[3]: *** [findknxusb] Error 1
    make[3]: Leaving directory `/root/bcusdk/eibd/usb'
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/root/bcusdk/eibd'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/root/bcusdk'
    make: *** [all] Error 2
    pthsem 2.0.8 wurde beim ./configure aber gefunden (in /opt).

    Muss für pthsem noch eine Umgebungsvariable gesetzt sein?

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    Danke!

    pthsem-snapshot hat durchcompiliert und ich konnte es installieren, so dass es das ./configure vom bcusdk finden konnte.

    bcusdk-snapshot bricht wie folgt ab:
    Code:
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT linux_usbfs.o -MD -MP -MF .deps/linux_usbfs.Tpo -c -o linux_usbfs.o linux_usbfs.c
    linux_usbfs.c: In function `find_monotonic_clock':
    linux_usbfs.c:209: error: `CLOCK_MONOTONIC' undeclared (first use in this function)
    linux_usbfs.c:209: error: (Each undeclared identifier is reported only once
    linux_usbfs.c:209: error: for each function it appears in.)
    make[3]: *** [linux_usbfs.o] Error 1
    make[3]: Leaving directory `/root/bcusdk/eibd/usb'
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/root/bcusdk/eibd'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/root/bcusdk'
    make: *** [all] Error 2
    Sollte nach einem Google-Versuch in PREFIX/include/bits/time.h definiert sein. Die gibt es aber nicht. Die Unslung-Kompilierumgebung scheint irgendwie zu "stinken". Ich muss wohl noch mal googeln, um herauszubekommen, wie ich alle header-files auf den NSLU2 unter Unslung 6.1-beta bekomme... vielleicht gibt es ja ein entsprechendes libc6-dev - ipkg...
    Workaround: Definier CLOCK_MONOTONIC als irgend eine Zahl.

    Werde mir noch anschauen, ob ich da etwas den Sourcen machen kann.

    Update: Fix im GIT master/pu vorhanden

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    Danke!

    pthsem-snapshot hat durchcompiliert und ich konnte es installieren, so dass es das ./configure vom bcusdk finden konnte.

    bcusdk-snapshot bricht wie folgt ab:
    Code:
    Making all in usb
    make[3]: Entering directory `/root/bcusdk/eibd/usb'
    g++ -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -fno-rtti -fno-exceptions -MT usb.o -MD -MP -MF .deps/usb.Tpo -c -o usb.o usb.cpp
    mv -f .deps/usb.Tpo .deps/usb.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o core.c
    mv -f .deps/core.Tpo .deps/core.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT descriptor.o -MD -MP -MF .deps/descriptor.Tpo -c -o descriptor.o descriptor.c
    mv -f .deps/descriptor.Tpo .deps/descriptor.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT io.o -MD -MP -MF .deps/io.Tpo -c -o io.o io.c
    mv -f .deps/io.Tpo .deps/io.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT sync.o -MD -MP -MF .deps/sync.Tpo -c -o sync.o sync.c
    mv -f .deps/sync.Tpo .deps/sync.Po
    gcc -DHAVE_CONFIG_H -I. -I../..  -I../../eibd/libserver -I../../common -I/opt/include   -g -O2 -MT linux_usbfs.o -MD -MP -MF .deps/linux_usbfs.Tpo -c -o linux_usbfs.o linux_usbfs.c
    linux_usbfs.c: In function `find_monotonic_clock':
    linux_usbfs.c:209: error: `CLOCK_MONOTONIC' undeclared (first use in this function)
    linux_usbfs.c:209: error: (Each undeclared identifier is reported only once
    linux_usbfs.c:209: error: for each function it appears in.)
    make[3]: *** [linux_usbfs.o] Error 1
    make[3]: Leaving directory `/root/bcusdk/eibd/usb'
    make[2]: *** [all-recursive] Error 1
    make[2]: Leaving directory `/root/bcusdk/eibd'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/root/bcusdk'
    make: *** [all] Error 2
    Sollte nach einem Google-Versuch in PREFIX/include/bits/time.h definiert sein. Die gibt es aber nicht. Die Unslung-Kompilierumgebung scheint irgendwie zu "stinken". Ich muss wohl noch mal googeln, um herauszubekommen, wie ich alle header-files auf den NSLU2 unter Unslung 6.1-beta bekomme... vielleicht gibt es ja ein entsprechendes libc6-dev - ipkg...

    Danke und Grüße,
    Stefan

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    nun kommt:
    Ist der gcc-Parameter "-I. -I. -I." nicht etwas merkwürdig?
    Nein. Niemand sorgt sich darum, wenn im Include-Pfad etwas mehrfach aufgenommen wird.

    Das Problem ist, das noch eine Option fehlt. Am besten man setzt alle 3:
    --with-mctx-mth=sjlj --with-mctx-dsp=ssjlj --with-mctx-stk=sas

    Die Kombination sollte für alle aktuellen Linux Plattformen funktionieren.

    Für x86 mit glibc geht auch:
    --with-mctx-mth=mcsc --with-mctx-dsp=sc --with-mctx-stk=mc

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    nun kommt:

    Code:
    make  all-recursive
    make[1]: Entering directory `/root/pthsem'
    Making all in debian
    make[2]: Entering directory `/root/pthsem/debian'
    make[2]: Nothing to be done for `all'.
    make[2]: Leaving directory `/root/pthsem/debian'
    make[2]: Entering directory `/root/pthsem'
    /bin/bash ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -I. -I.   -g -O2 -MT pth_mctx.lo -MD -MP -MF .deps/pth_mctx.Tpo -c -o pth_mctx.lo pth_mctx.c
     gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT pth_mctx.lo -MD -MP -MF .deps/pth_mctx.Tpo -c pth_mctx.c  -fPIC -DPIC -o .libs/pth_mctx.o
    pth_mctx.c:246:2: #error "unknown mctx stack setup"
    pth_mctx.c:293:2: #error "unknown mctx stack setup"
    make[2]: *** [pth_mctx.lo] Error 1
    make[2]: Leaving directory `/root/pthsem'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/root/pthsem'
    make: *** [all] Error 2
    Ist der gcc-Parameter "-I. -I. -I." nicht etwas merkwürdig?

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    Das "Dumme" ist nur, dass das aktuelle bcusdk pthsem 2.0.8 benötigt (--> Fehlermeldung von bcusdk-"./configure ...").

    Also habe ich auch ein pthsem-snapshot heruntergeladen und versucht zu kompilieren (mit "make" nach "autoreconf -i" & "./configure --prefix=/opt"):
    Installiert ist "libc6-unslung - 2.2.5-r13".

    Ich denke nicht, dass keine andere verfügbar ist für Unslung.
    Das Problem ist nicht die Umgebung, sondern das die automatische Erkennung damit nicht nicht ganz zurecht kommt.

    Tu bitte beim configure folgenden Parameter noch dazu:
    --with-mctx-dsp=ssjlj

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    Das "Dumme" ist nur, dass das aktuelle bcusdk pthsem 2.0.8 benötigt (--> Fehlermeldung von bcusdk-"./configure ...").

    Also habe ich auch ein pthsem-snapshot heruntergeladen und versucht zu kompilieren (mit "make" nach "autoreconf -i" & "./configure --prefix=/opt"):
    Code:
    make  all-recursive
    make[1]: Entering directory `/root/bcusdk'
    Making all in debian
    make[2]: Entering directory `/root/bcusdk/debian'
    make[2]: Nothing to be done for `all'.
    make[2]: Leaving directory `/root/bcusdk/debian'
    make[2]: Entering directory `/root/bcusdk'
    /bin/bash ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -I. -I.   -g -O2 -MT pth_mctx.lo -MD -MP -MF .deps/pth_mctx.Tpo -c -o pth_mctx.lo pth_mctx.c
     gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT pth_mctx.lo -MD -MP -MF .deps/pth_mctx.Tpo -c pth_mctx.c  -fPIC -DPIC -o .libs/pth_mctx.o
    pth_mctx.c:480:2: #error "Unsupported Linux (g)libc version and/or platform"
    make[2]: *** [pth_mctx.lo] Error 1
    make[2]: Leaving directory `/root/bcusdk'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/root/bcusdk'
    make: *** [all] Error 2
    Installiert ist "libc6-unslung - 2.2.5-r13".

    Ich denke nicht, dass keine andere verfügbar ist für Unslung.

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Habe doch noch etwas vergessen zu beantworten:
    Zitat von EIBman Beitrag anzeigen
    Okay, das hatte ich auch schon gelesen. Habe es nur der Vollständigkeit halber nochmal erwähnt. GIT habe ich auf dem NSLU2 noch nicht am laufen; jedenfalls schaffe ich es nicht, das bcusdk-Repository auszuchecken. Das wird aber an meiner Unkenntnis bzgl. GIT liegen.
    Sourceforge bittet eine Web-basierten GIT Browser. Dort ist neben jeden Commit ein Link zum Download eines Snapshots als Archiv. Von den configure muss man nur noch autoconf/automake aufrufen:
    Code:
    aclocal -I m4
    autoheader
    automake -a --foreign
    autoconf
    Im bcusdk trac wiki sollte das auch stehen.

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    Ganz großen Dank!!!

    Jetzt mache ich mich an linknx und dann an knxweb oder knx@home...

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    Wie geschrieben läuft eibd samt USB-EIB-Verbindung auf dem NSLU2 mit "eibd -d -D -S -T -i usb:...". "-S" sollte ja den EIBnet/IP Server starten und per "-D" auch für andere auffindbar machen, oder nicht?
    Kann ich mir "-T" eigentlich sparen?
    Wofür wird eigentlich "-i" benötigt?
    -i ist für groupwrite & Co (EIBD Proktoll).
    -T aktiviert das KNXnet/IP Tunneling Protokol - du willst es garantiert nicht abdrehen.

    Zitat von EIBman Beitrag anzeigen
    Führe ich "eibnetsearch -" auf dem NSLU2 direkt durch, so erhalte ich folgendes: .....
    Ist OK.

    Zitat von EIBman Beitrag anzeigen
    Nun zurück zum Remote-/Desktop-PC (der also keine eigene direkte EIB-Verbindung hat und den NSLU2-EIBD KNXnet/IP Server für die Verbindung nutzen soll).

    Ist EIBD mit "-d -D -S -T -i ipt:192.168.1.77" gestartet also mit dem/obigen NSLU2-EIBD KNXnet/IP Server verbunden, so ergibt "eibnetsearch -" folgendes:
    ....
    Ist EIBD nicht auf dem Remote-/Desktop-PC gestartet, so ist die Ausgabe wie oben direkt auf dem NSLU2 ausgeführt. Ich gehe also davon aus, dass EIBD auf dem Remote-/Desktop-PC nicht gestartet sein darf, oder? Jedenfalls nicht mit den angegebenen Parametern (?).
    Auf OK. ipt (dh KNXnet/IP Client) und eibnetsearch auf einen Rechner schlagen sich, da beide das selbe Port als einen Defaultwert haben. Bei Bedarf könnte man es umstellen, ist hier unnötig.

    Jedenfalls ist damit festgestellt, das der EIBD korrekt ins Netzwerk eingebunden ist.

    Zitat von EIBman Beitrag anzeigen
    Muss ich EIBD dann mit anderen Parametern aufrufen? Wo muss EIBD dann laufen? Auf dem Linux Host (also dem eigentlichen OS auf dem Remote-/Desktop-PC) oder auf dem VirtualBox Windows XP Guest? Letzteres wäre zumindedt für mich leicht schwierig, da ich noch nie eine Compiler-Toolchain auf einem Windows-PC erstellt habe.
    Auf Windows brauchts du in deinen Fall keinen EIBD. EIBD PArameter passen.

    Zitat von EIBman Beitrag anzeigen
    NAT habe ich deaktiviert bzw. die Netzwerkverbindung auf Bridged umgestellt (Guest auswählen > "Ändern" > "Netzwerk" und dann uf Bridged gehen und den entsprechenden Adapter auf dem Host auswählen, der verwendet werden soll). Jetzt hat der VirtualBox Windows XP Guest eine eigene IP im lokalen Netzwerk und entsprechend das gleiche Subnetz. Linux Host und NSLU2 können auch per Kommandozeile angepingt werden.
    Damit hast du ein Problem besteitigt. NAT macht bei KNXnet/IP oft Probleme.

    Zu deiner Frage, was ich mit den Tunneling gemeint habe:
    Das "eibd auf 192.168.1.77 wird (nun) automatisch gefunden" geht.

    Bezüglich Busmonitor:

    Add (3.1.1) - Anfrage geht direkt ans NSLU (übers EIBD Protkoll)
    Add (3.1.2) - Anfrage geht an lokalen EIBD via EIBD Prokoll von von dort per KNXnet/IP zum NSLU
    Add (3.1.3) - wie oben erwähnt, eibnetsearch + eibd mit ipt: auf einen Rechner schlagen sich ohne Umkonfiguration. eibnetsearch auf dritten Rechner würde beide finden.
    Add (3.2.4) ETS geht als. EIBD nicht aus den GIT geht nur als Gruppenbusmonitor. EIBD aus den GIT unterstützt den Busmonitor Modus (Daten entsprechen aber nur den vbusmonitor vom EIBD)

    Ich hoffe ich habe keine Frage übersehen.

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    Zitat von mkoegler Beitrag anzeigen
    Nur ein Tip: Wenn sich der EIBD ein Interface aus den Output von findknxusb selbst aussuchen darf (zB weil nur eins angeschlossen ist), kannst du gleich
    Code:
    eibd -d -D -S -T -i usb:
    schreiben.
    Ja, danke; klappt auch!

    Einen Kommentar schreiben:


  • EIBman
    antwortet
    Zitat von mkoegler Beitrag anzeigen
    Danke für den Hinweis. Workaround ist im GIT. Meinen Nachforschungen nach zu Urteilen, deutet das auf ein Toolchain Problem hin.
    Toolchainproblem auf der NSLU2 ist gut möglich, die Definition steht normalerweise in der limits.h, die aber auf dem NSLU2 nicht zu finden ist (jedenfalls finde ich sie nicht...). Ein ifndef + define in der usbi.h wäre glaube ich gut.

    Unicast Test von der ETS wird nur vom EIBD aus den pu branch bestanden.
    Okay, das hatte ich auch schon gelesen. Habe es nur der Vollständigkeit halber nochmal erwähnt. GIT habe ich auf dem NSLU2 noch nicht am laufen; jedenfalls schaffe ich es nicht, das bcusdk-Repository auszuchecken. Das wird aber an meiner Unkenntnis bzgl. GIT liegen.

    Bezüglich ETS auf Virtual Box kann ich nur zu folgenden raten:
    * EIBD EIBnet/IP Server testen (zB indem man sich mit einen anderen EIBD dorthin verbindet und/oder mit "eibnetsearch -" danach sucht)
    Wie geschrieben läuft eibd samt USB-EIB-Verbindung auf dem NSLU2 mit "eibd -d -D -S -T -i usb:...". "-S" sollte ja den EIBnet/IP Server starten und per "-D" auch für andere auffindbar machen, oder nicht?
    Kann ich mir "-T" eigentlich sparen?
    Wofür wird eigentlich "-i" benötigt?

    Führe ich "eibnetsearch -" auf dem NSLU2 direkt durch, so erhalte ich folgendes:
    Code:
    Asking 224.0.23.12 at port 3671 from port 3672
    Answer from 192.168.1.77 at port 3671
    Medium: 2
    State: 0
    Addr: 0.0.0
    InstallID: 0
    Serial: 00 00 00 00 00 00
    Multicast-Addr: 224.0.23.12
    MAC: 00 00 00 00 00 00
    Name: eibd
    Service 2 Version 1
    Service 4 Version 1
    Keine Ahnung, was mir das konkret sagt, aber sieht erstmal für mich nicht fehlerhaft aus, oder?

    Nun zurück zum Remote-/Desktop-PC (der also keine eigene direkte EIB-Verbindung hat und den NSLU2-EIBD KNXnet/IP Server für die Verbindung nutzen soll).

    Ist EIBD mit "-d -D -S -T -i ipt:192.168.1.77" gestartet also mit dem/obigen NSLU2-EIBD KNXnet/IP Server verbunden, so ergibt "eibnetsearch -" folgendes:
    Code:
    Asking 224.0.23.12 at port 3671 from port 3672
    IP initialisation failed
    Ist EIBD nicht auf dem Remote-/Desktop-PC gestartet, so ist die Ausgabe wie oben direkt auf dem NSLU2 ausgeführt. Ich gehe also davon aus, dass EIBD auf dem Remote-/Desktop-PC nicht gestartet sein darf, oder? Jedenfalls nicht mit den angegebenen Parametern (?).

    Muss ich EIBD dann mit anderen Parametern aufrufen? Wo muss EIBD dann laufen? Auf dem Linux Host (also dem eigentlichen OS auf dem Remote-/Desktop-PC) oder auf dem VirtualBox Windows XP Guest? Letzteres wäre zumindedt für mich leicht schwierig, da ich noch nie eine Compiler-Toolchain auf einem Windows-PC erstellt habe.

    * Firewalls während der Fehlersuche abdrehen
    Alle Filter und Firewalls sind deaktiviert und alles ist zumindest intern offen wie ein riesen großes "Scheunentor".

    * Schauen, das die Netzeinbindung von der Virtual Box kein NAT macht (dh so ist, wie wenn der virtuelle Rechner direkt im LAN wäre)
    NAT habe ich deaktiviert bzw. die Netzwerkverbindung auf Bridged umgestellt (Guest auswählen > "Ändern" > "Netzwerk" und dann uf Bridged gehen und den entsprechenden Adapter auf dem Host auswählen, der verwendet werden soll). Jetzt hat der VirtualBox Windows XP Guest eine eigene IP im lokalen Netzwerk und entsprechend das gleiche Subnetz. Linux Host und NSLU2 können auch per Kommandozeile angepingt werden.

    Kann die ETS den EIBD EIBnet/IP Tunneling Server finden?
    Leider kann ich nicht mehr ganz folgen bzw. verstehe die Unterschiede nicht mehr (bin leider kein Netzwerk-Profi). Ich versuche deshalb mal zu erklären, was ich gemacht habe und was geht/nicht geht (sozusagen als HowTo wie es funktionieren könnte, für die Nachwelt...):

    (1) Lokales Netzwerk 192.168.1.0, Subnet-Mask 255.255.255.0, Clients sind entweder per Kabel oder aber per WLAN angeschlossen.

    (2) NSLU2 mit direkter EIB-USB-Anbindung und IP 192.168.1.77 im lokalen Netzwerk, OS Unslung 6.1-beta, EIBD 0.0.4, EIBD gestartet mit Parameter "-d -D -S -T -i usb:...", "groupswrite ip:192.168.1.77 x/y/z 0|1" sowie "groupswrite ip:127.0.0.1 x/y/z 0|1" direkt auf dem NSLU2 funktionieren, sprich grundsätzlich sollte der EIB-Zugriff also klappen. "eibnetsearch -" liefert oben angeführtes Ergebnis.

    (3) Remote-/Desktop-PC mit (W)LAN-Verbindung zum NSLU2 bzw. mit IP 192.168.1.198 im lokalen Netzwerk, OS Gentoo/Linux, EIBD 0.0.4, ...

    (3.1) ... EIBD gestartet mit Parameter "-d -D -S -T -i ipt:192.168.1.77",
    (3.1.1) "groupswrite ip:192.168.1.77 x/y/z 0|1" von hier funktioniert
    Ich nehme an, dass in diesem Fall direkt mit dem NSLU2-EIBD KNXnet/IP Server kommuniziert wird, korrekt?
    (3.1.2) "groupswrite ip:127.0.0.1 x/y/z 0|1" von hier funktioniert.
    Ich nehme an, dass in diesem Fall via lokaler EIBD-Instanz mit dem NSLU2-EIBD KNXnet/IP Server kommuniziert wird, korrekt?
    (3.1.3) "eibnetsearch -" schlägt mit o.a. Fehlermeldung fehl. Vielleicht weil nun 2 EIB-"Server" im Netz sind?

    (3.2) ... EIBD nicht gestartet,
    (3.2.1) "groupswrite ip:192.168.1.77 x/y/z 0|1" von hier funktioniert
    (3.2.2) "groupswrite ip:127.0.0.1 x/y/z 0|1" von hier funktioniert nicht bzw. führt zur Fehlermeldung, was aber m.E. auch nicht verwunderlich ist, denn schließlich läuft lokal ja auch keine EIBD-Instanz mehr.
    (3.2.3) "eibnetsearch -" liefert identisches Ergebnis zu "eibnetsearch -" auf dem NSLU2 (vgl. o.) -> funktioniert also (?).
    (3.2.4) VirtualBox Windows XP Guest mit Bridged Network und IP im lokalen Netzwerk 192.168.1.51, EIBD in Windows läuft nicht, keine TCP/IP-Paket-Filterung (alle Ports offen) und keine Firewall aktiv, ETS3 Professional Version 3.0f (Build 00990), Menü "Extras" > "Optionen..." > Tab "Kommunikation" > Button "Schnittstelle konfigurieren", neue "KNXnet/IP"-Verbidnung, eibd auf 192.168.1.77 wird (nun) automatisch gefunden, Port 3671, kein NAT-Modus --> mit OK bestätigt und dann im Optionen-/Kommunikation-Dialog auf Button "Test" --> Ergebnis: OK --> Gruppenmonitor, Gruppenadr.-Werte lesen/schreiben, etc. funzen... Jippie! Nicht funzen tut der Busmonitor mit der LAN-Verbindung.

    Einzig verbleibendes Probelm (habe aber irgendwo schonmal gelesen, dass das "normal" sein soll): Nach einiger Zeit bricht die Verbidnung zusammen. Healing: Menü "Extras" > "Optionen..." > Tab "Kommunikation" > Button "Test" (selbiges muss auch initial beim Starten von ETS einmal gemacht werden)

    Zu meinem besseren Verständnis würde ich das mit dem Tunneling auch gern noch verstehen :-D

    Danke und Grüße,
    Stefan

    Einen Kommentar schreiben:


  • mkoegler
    antwortet
    Zitat von EIBman Beitrag anzeigen
    Dabei gab es einen kleinen Fehler in usbi.h, der sich aber leicht korrigieren ließ. PATH_MAX war nicht definiert. Ein simples
    Code:
    #define PATH_MAX 4096
    schaffte Abhilfe.
    Danke für den Hinweis. Workaround ist im GIT. Meinen Nachforschungen nach zu Urteilen, deutet das auf ein Toolchain Problem hin.

    Zitat von EIBman Beitrag anzeigen
    Nicht funktionieren tut aber nach wie vor eine Verbindung in ETS3, welches auf dem Remote-PC in einer WinXP-VirtualBox läuft:

    (1)
    KNXnet/IP mit IP 192.168.1.77 (ist die IP des NSLU2s) oder 127.0.0.1 mit oder ohne NAT auf Port 3671 klappen nicht Unicast-Test und genereller Verbindungstest schlagen fehl.

    (2)
    KNXnet/IP Routing liefert beim generellen Verbindungstest ein OK, aber weder Busmonitor noch das Lesen/Schreiben von Werten funktioneren.

    Der Trace lauf der NSLU2 von EIBD liefert auch keinerlei Schreibanfragen auf die probierten Gruppenadressen.
    Unicast Test von der ETS wird nur vom EIBD aus den pu branch bestanden.
    Bezüglich ETS auf Virtual Box kann ich nur zu folgenden raten:
    * EIBD EIBnet/IP Server testen (zB indem man sich mit einen anderen EIBD dorthin verbindet und/oder mit "eibnetsearch -" danach sucht)
    * Firewalls während der Fehlersuche abdrehen
    * Schauen, das die Netzeinbindung von der Virtual Box kein NAT macht (dh so ist, wie wenn der virtuelle Rechner direkt im LAN wäre)

    Kann die ETS den EIBD EIBnet/IP Tunneling Server finden?

    Einen Kommentar schreiben:

Lädt...
X