Einbindung von Dash Buttons

[jonofe]

Es ist ja quasi eine dynamische IP, nur dass der dhcp Server dem Dash immer dieselbe zuordnet.
Und die Anfrage nach der IP kommt ja auch nur einmal an. Sehr seltsam.
Bei mir ist der dhcp Server allerdings nicht auf der Fritzbox. Kann es sein, dass durch das Blocken bei Euch der Dash gar keine IP bekommt und daher gar nicht versucht nach Hause zu telefonieren?

Ich habe jetzt nochmal neu aktiviert und kein Produkt ausgewählt. Es funktioniert zwar, aber mit genau demselben Verhalten.

Welchen Dash Button habt ihr denn? (Marke?) Ich habe Diadermin. Habe aber noch einen zweiten bestellt. Mal sehn ob der anders funktioniert.

[NetFritz]

Hallo
Ich habe auch den neuen DashButton von Ariel.
Ich habe Konfiguration im letzten Schritt abgebrochen, keine Bestellung angeklickt, App beendet.
Dann in der Fritzbox WLAN - Funknetz - Bearbeiten - Immer die gleiche IP zuweisen
und dann unter Internet - Filter - Kindsersicherung den DashButton gesperrt.
Gruß NetFritz

[Monti]

Mit

yum update

sollte die Mirrorlist aktualisiert werden.

Danke, muss ich heute Abend vesuchen.

Kommt dein Edomi Server grundsätzlich ins Inet?

Gute Frage. Ins lokale Netz auf jeden Fall.

[jonofe]

Gute Frage. Ins lokale Netz auf jeden Fall.

lokales Netz hilft nicht, da Pakete nachinstalliert werden müssen, die er von den CentOS Servern runterlädt.

[jonofe]

Habe jetzt bei mir nochmal auf meinem internen Rooter getraced was da so passiert:

root@wrt54gl:~# tcpdump  ether host ##:##:##:##:##:##
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
16:52:36.688610 ##:##:##:##:##:## (oui Unknown) > 01:40:96:ff:ff:00 (oui Unknown), ethertype Unknown (0x872d), length 60:
        0x0000:  0022 0202 0140 96ff ff00 50f5 dab2 02b3  ."...@....P.....
        0x0010:  50f5 dab2 02b3 000f f748 b860 0000 0000  P........H.`....
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
16:52:36.693837 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from ##:##:##:##:##:## (oui Unknown), length: 261
16:52:36.696313 arp who-has david.feld.home tell 192.168.0.150
16:52:36.700186 arp who-has wrt54gl tell 192.168.0.150
16:52:36.700368 arp reply wrt54gl is-at ##:##:##:##:##:## (oui Unknown)
16:52:36.711371 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:52:37.052535 IP 192.168.0.150.55878 > 54.239.38.223.https: S 1235808564:1235808564(0) win 4338 <mss 1446>
16:52:37.724023 IP 192.168.0.150.55878 > 54.239.38.223.https: S 1235808564:1235808564(0) win 4338 <mss 1446>
16:52:39.711543 IP 192.168.0.150.55878 > 54.239.38.223.https: S 1235808564:1235808564(0) win 4338 <mss 1446>
16:52:41.691666 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:52:43.711791 IP 192.168.0.150.55878 > 54.239.38.223.https: S 1235808564:1235808564(0) win 4338 <mss 1446>
16:52:46.691996 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:52:51.692328 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:52:51.712304 IP 192.168.0.150.55878 > 54.239.38.223.https: S 1235808564:1235808564(0) win 4338 <mss 1446>
16:52:56.693341 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:53:01.692984 IP 192.168.0.150.55877 > time-c.nist.gov.ntp: NTPv4, Client, length 48
16:53:06.695374 IP 192.168.0.150.55877 > time-d.nist.gov.ntp: NTPv4, Client, length 48

Dauert alles ziemlich genau 30 Sekunden. Das Zuweisen der IP läuft quasi in der ersten Sekunde nach Aufwachen ab. Danach versucht er wohl 5 mal nach Hause zu telefonieren (HTTPS) und 7 mal die Zeit zu synchronisieren via NTP mit time-c.nist.gov.

Schema scheint folgendes zu sein:

Mutterschiff kontaktieren (HTTPS)
1 Sekunde warten
Mutterschiff kontaktieren (HTTPS)
2 Sekunden warten
Mutterschiff kontaktieren (HTTPS)
4 Sekunden warten
Mutterschiff kontaktieren (HTTPS)
8 Sekunden warten
Mutterschiff kontaktieren (HTTPS)
Aufgeben.

Zusätzlich alle 5 Sekunden NTP Request.

Wenn der NTP request erfolgreich wäre, wäre ggf. die Kommunikation nach 15 Sekunden beendet.

Kann jemand von euch einen ähnlichen Trace machen oder geht das auf euren Routern nicht.
Falls ihr tcpdump dort habt, dann wäre der Aufruf:

tcpdump  ether host XX:XX:XX:XX:XX:XX

XX:XX:XX:XX:XX:XX ist dabei die MAC Adresse des Dash Buttons.

EDIT:
Auch bei erfolgreichem NTP Request (ich habe die DNS Auflösung von time-c.nist.gov über meinem internen DNS Server umgebogen auf meinen internen NTP Server) blinkt der Dash 30 Sekunden bevor er sich schlafen legt. In den letzten 15 Sekunden findet allerdings keine Kommunikation mehr statt.

[NetFritz]

Hallo
Hier mein tcpdum

root@netfritz-FUTRO-S900:/home/netfritz# tcpdump  ether host xx:xx:xx:xx:xx:xx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:08:38.143315 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx (oui Unknown), length 261
17:08:38.326719 ARP, Request who-has fritz.box tell DashButton.fritz.box, length 46

Gruß NetFritz

[jonofe]

Hallo
Hier mein tcpdum

root@netfritz-FUTRO-S900:/home/netfritz# tcpdump ether host xx:xx:xx:xx:xx:xx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:08:38.143315 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx (oui Unknown), length 261
17:08:38.326719 ARP, Request who-has fritz.box tell DashButton.fritz.box, length 46

Gruß NetFritz

Okay, das sind nur die Broadcast Pakete, die du auf jedem Device in deinem Netz siehst.
Die Kommunikationsversuche nach außen siehst du nur auf deinem Router. Die wären interssant.
Für mich sieht es so aus, als gäbe auch bei der v2 unterschiedliche Softwareimplementierungen.

[Monti]

lokales Netz hilft nicht, da Pakete nachinstalliert werden müssen, die er von den CentOS Servern runterlädt.

Gateway und DNS waren falsch. Muss mich bei der Installation verschrieben haben.

[junibart]

Version 3.0 ist nun verfügbar und funktioniert nachgewiesener Maßen mit meinem neuen Diadermine Dash Button.

Hi André,

in zwei Tagen Test ist es mehrfach vorgekommen, dass der LBS (bzw. die darunter liegenden Komponenten) nicht mehr auf die Pakete des Buttons reagieren. Es tritt erst nach mehreren Stunden auf. Einträge in den Log-Dateien, die auf Probleme deuten, habe ich nicht gefunden. Ein parallel im Netz mitlaufender Raspi, der als Sniffer mitläuft, erkennt die Pakete.
Nach einer Neuaktivierung des Projekts funktioniert alles wieder.... für ein paar Stunden.

Kann ich etwas zum Debuging beitragen?

Danke und beste Grüße,
Gunnar

[jonofe]

Hi André,

in zwei Tagen Test ist es mehrfach vorgekommen, dass der LBS (bzw. die darunter liegenden Komponenten) nicht mehr auf die Pakete des Buttons reagieren. Es tritt erst nach mehreren Stunden auf. Einträge in den Log-Dateien, die auf Probleme deuten, habe ich nicht gefunden. Ein parallel im Netz mitlaufender Raspi, der als Sniffer mitläuft, erkennt die Pakete.
Nach einer Neuaktivierung des Projekts funktioniert alles wieder.... für ein paar Stunden.

Kann ich etwas zum Debuging beitragen?

Hi Gunnar,

Ich glaube ich weiß woran es liegt. Hatte es auch schon während der Entwicklung bemerkt, dass der Aufruf

$packet = $simplePcap->get(); 

blockierend ist. D.h. es wird nur in der while Schleife weiter gemacht, wenn ein Paket kommt, was den Filterkriterien entspricht. Dadurch geht dann die DB Connection verloren, wenn 8h nichts passiert.

Daher muss einfach hinter der o.g. Zeile ein

sql_connect(); 

eingefügt werden. Werde das Update jetzt hochladen.
Danke für das Feedback ...

VG
André

[wintermute]

Und das hilft? Der Aufruf blockiert doch weiterhin, oder versteh ich grad was flasch?

[junibart]

Update ist installiert. Morgen um 7:23 wissen wir, ob es was gebracht hat.
Grüße, Gunnar

[jonofe]

Und das hilft? Der Aufruf blockiert doch weiterhin, oder versteh ich grad was flasch?

durch das sql_connect() wird dann die Verbindung zur DB wieder explizit aufgebaut. Ohne das sql_connect() funktionieren die "EDOMI-Befehle" nicht mehr, also z.B. logic_setOutput usw. Das Blocckieren ist also kein Problem, solange man danach prophylaktisch die DB connection neu aufbaut. Ansonsten geht nämlich auch das while (getSysInfo(1) >=1) in die Fritten und das Skript beendet sich.

[jonofe]

Update ist installiert. Morgen um 7:23 wissen wir, ob es was gebracht hat.

Und? Hat's funktioniert?

[wintermute]

Ahso, der sql_connect() ist ein RE-Connect, ich dachte das waer nur eine Art Keep-Alive... dann nehme ich alles zurueck und behaupte das Gegenteil