Autostart von EIBD auf Raspi2

[speedschmidt]

keine Erwähnung von knxd in:

Code Auswählen Erweitern


/var/log/messages

Anbei mal meine /var/log/messages als Dateianhang. Vielleicht siehst du Auffälligkeiten.
ich hatte im do_start eingebaut:

Code Auswählen Erweitern


echo "knxd wird gestartet"

Beim manuellen Start wird diese Meldung auch angezeigt.

[smurfix]

Da sind jetzt leider nur die Kernelnachrichten drin. Die allein helfen mir nicht weiter. (Unter Jessie ist das einfacher, "journalctl -b" spuckt dir einfach alles seit dem letzten Boot aus.)

Meine Frage ist eher, ob das Skript überhaupt ausgeführt wird oder ob der knxd aus irgendwelchen besonderen Gründen auf die Nase fliegt. Daher mein Hinweis in #29.

[speedschmidt]

ich habe den rpi2 ein paar mal booten lassen, aber nichts von knxd gesehen.
die argumente habe ich vorher eingetragen. die logdatei wird aber erst nach dem manuellen start angelegt.
der script scheint soweit in ordnung zu sein, da ich ja mit

Code Auswählen Erweitern


/etc/init.d/knxd start

manuell starten kann. der script wird einfach beim booten nicht beachtet.
was mir noch auffält, das der dienst mit

Code Auswählen Erweitern


/etc/init.d/knxd stop

nicht beendet wird. da bleibt er irgendwie hängen und der dienst läuft noch. sieht man mit

Code Auswählen Erweitern


/etc/init.d/knxd status

muss aber nichts bedeuten, da wir den dienst ja erstmal starten wollen.

ich bin jetzt kurz davor, alles ganz von vorne anfzufangen. die fhem.cfg sicher ich mir aber vorher.
es sieht ja so aus als ob es was system-technisches ist.

[smurfix]

Wenn du das eh neu aufsetzen magst, dann gleich mit Jessie ...

[speedschmidt]

uff geschafft -- jessie ist drauf und läuft soweit ich das beurteilen kann "stable".

der knxd startet meiner Meinung nach auch:

Code Auswählen Erweitern


pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - LSB: <knxd>
   Loaded: loaded (/etc/init.d/knxd)
   Active: active (exited) since Mi 2015-07-01 23:09:14 CEST; 11min ago
  Process: 485 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
pi@raspberrypi ~ $

23:09Uhr war Systemstart nach upgrade auf jessie.
ABER: groupswrite geht nicht und damit kein zugriff auf eib/knx

Code Auswählen Erweitern


pi@raspberrypi ~ $ groupswrite ip:127.0.0.1 0/2/9 0
Open failed: Connection refused
pi@raspberrypi ~ $


Noch Ideen???

[speedschmidt]

Update:

wenn ich via:

Code Auswählen Erweitern


/usr/local/bin/eibd -t 1023 -S -D -R -T -i --eibaddr=X.X.X --daemon=/var/log/eibd.log --no-tunnel-client-queuing ipt:192.168.XXX.XXX

den eibd starte, dann kann ich auch mit:

Code Auswählen Erweitern


groupswrite ip:127.0.0.1 0/2/9 0

auf den eib zugreifen.

ABER das ganze nicht mit knxd oder per AUTOSTART.

Was mache ich denn bloß verkehrt? Kann ich denn noch irgendwelche logs o.ä. zur Fehlersuche beitragen?

Ingo

[smurfix]

Das verstehe ich nicht wirklich; wenn ich den knxd (aktieller master-Branch) mit -i starte, dann macht er einen TCP-Socket auf Port 6720 auf und ein *write funktioniert.

Bitte vergiss nicht, dass du beim knxd das -DRT vor das -S stellen musst; dasselbe gilt für --eibaddr. An deinem aktuellen Problem sollte das aber nichts ändern. (Beim eibd ist die Reihenfolge egal. Ich baue da demnächst eine Warnung ein.)

Starte ihn bitte mal zusätzlich mit "-f 9" (Argument vorne angeben). Schicke mir den Inhalt von /var/log/eibd.log und den Output des Befehls "lsof -p PID-vom-KNXD".

PS: mal ne dumme Frage: Was bringt eigentlich der Obskurantismus bei lokalen IPs und der EIB-Adresse? Wenn sich wirklich jemand in dein lokales Netz einhacken kann, findet er beides sowieso sofort heraus ...

[speedschmidt]

high smurfix

#Das verstehe ich nicht wirklich; wenn ich den knxd (aktieller master-Branch) mit -i starte, dann macht er einen TCP-Socket auf Port 6720 auf und ein #*write funktioniert.

Ich ehrlich gesagt auch nicht(aktieller master-Branch), aber dass hat nichts zu bedeuten. Ich google mal danach.

#Bitte vergiss nicht, dass du beim knxd das -DRT vor das -S stellen musst; dasselbe gilt für --eibaddr. An deinem aktuellen Problem sollte das #aber nichts ändern. (Beim eibd ist die Reihenfolge egal. Ich baue da demnächst eine Warnung ein.)

also hier mal die Args von

Code Auswählen Erweitern


/etc/default/knxd


Code Auswählen Erweitern


DAEMON_ARGS="-f9 -d -D -R -T --daemon=/tmp/knxd.log -t 1023 --eibaddr=1.0.255 --no-tunnel-client-queuing -i -S ipt:192.168.100.34"


#Starte ihn bitte mal zusätzlich mit "-f 9" (Argument vorne angeben). Schicke mir den Inhalt von /var/log/eibd.log und den Output des Befehls "lsof #-p PID-vom-KNXD".

folgt zeitnah.

PS: mal ne dumme Frage: Was bringt eigentlich der Obskurantismus bei lokalen IPs und der EIB-Adresse? Wenn sich wirklich jemand in dein lokales Netz einhacken kann, findet er beides sowieso sofort heraus ...

[speedschmidt]

high smurfi,

Mein Eibd.log ist ca. 60MB groß - zu groß zum posten. ich zerlege die mal und poste hier die letzten 10.000 Zeilen. Mit dem Befehl

Code Auswählen Erweitern


lsof -p 489

kann mein System nichts anfangen

Code Auswählen Erweitern


pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - LSB: <knxd>
   Loaded: loaded (/etc/init.d/knxd)
   Active: active (exited) since Sa 2015-07-04 22:03:57 CEST; 14min ago
  Process: 489 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
pi@raspberrypi ~ $ lsof -p 489
-bash: lsof: Kommando nicht gefunden.
pi@raspberrypi ~ $ Isof -p 489
-bash: Isof: Kommando nicht gefunden.
pi@raspberrypi ~ $ isof -p 489
-bash: isof: Kommando nicht gefunden.

ich hoffe ich stell mich nicht nur zu dumm an.

Ingo

[speedschmidt]

high smurfi,

anbei der Auszug (letzten Zeilen) meiner eibd.log

[smurfix]

Mein Eibd.log ist ca. 60MB groß - zu groß zum posten. ich zerlege die mal und poste hier die letzten 10.000 Zeilen.

Du sollst ja auch nicht alles posten, sondern nur den letzten Durchlauf ...

Mit dem Befehl

Code Auswählen Erweitern


lsof -p 489

kann mein System nichts anfangen

Dann installiere "lsof".

[Andi291]

Moinsen!

Bin jetzt der Diskussion nicht bis ins letzte gefolgt, daher vielleicht eine ein wenig unqualifizierte, banale Idee: hast Du vielleicht ein User / Rechteproblem? Probier doch mal nach Autostart ein sudo *write aus...

Grüße, Andi...

[smurfix]

eine ein wenig unqualifizierte, banale Idee: hast Du vielleicht ein User / Rechteproblem? Probier doch mal nach Autostart ein sudo *write aus...

Wir reden hier von einem TCP-Socket mit Port>1023. Daher: Nö.

[Andi291]

Abend!

Probier mal bitte die folgende variante:

1. Beim EIBD-Start von ip auf ipt ändern: eibd ... ipt:<ip_der_eibd_verbidnung>
2. Neu starten (Austostart)
3. route add 224.0.23.12 dev eth0
4. groupswrite ipt:224.0.23.12 0/2/9 0

Hatte mal ein ähnliches Phänoment, bei dem sich "unerlaubterweise" ein anderer Kommunikationspartner eingemischt hat. Der hat meinen Kanal belegt...

Grüße, Andi

[smurfix]

3. route add 224.0.23.12 dev eth0

das macht keinen Sinn. Multicastadressen gehören nicht in die Routingtabelle. Mal ganz abgesehen davon, dass deine Defaultroute im Zweifelsfall eh schon auf eth0 zeigt.

4. groupswrite ipt:224.0.23.12 0/2/9 0

Das kann auch nicht funktionieren, groupswrite et al. verstehen nur local:/pfad/zum/socket und ip:adresse-oder-hostname.