Running the MicroTerkin Agent on Windows

clemens · July 10, 2019, 3:57pm

Windows restart … et voilà!

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware> python tools/terkin.py monitor
2019-07-10 17:46:06,379 [tools/terkin.py] INFO   : Local networks: ['169.254.0.0/16', '192.168.178.0/24', '127.0.0.0/8']
2019-07-10 17:46:06,379 [tools/terkin.py] INFO   : Waiting for device with MAC address prefix 80:7d:3a to appear on your local network
2019-07-10 17:46:06,903 [tools/terkin.py] INFO   : Sending an ARP ping to 169.254.0.0/16 to find devices already connected
2019-07-10 17:46:06,903 [tools/terkin.py] INFO   : Sending an ARP ping to 127.0.0.0/8 to find devices already connected
2019-07-10 17:46:06,903 [tools/terkin.py] INFO   : Sending an ARP ping to 192.168.178.0/24 to find devices already connected
2019-07-10 17:49:24,905 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:49:25,342 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:49:26,264 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:49:27,567 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:49:36,967 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:55:21,152 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:55:21,594 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:55:22,665 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 17:55:23,668 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}

Ich glaube so wars gedacht!

clemens · July 10, 2019, 5:22pm

Noch eine Beobachtung: Mein FiPy schläft aktuell ca. 6 Minuten. Zwei Sendezyklen bekommt tools/terkin.py monitor immer mit, den dritten aber nicht mehr:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware> python tools/terkin.py monitor
2019-07-10 18:58:50,034 [tools/terkin.py] INFO   : Local networks: ['192.168.178.0/24']
2019-07-10 18:58:50,035 [tools/terkin.py] INFO   : Waiting for device with MAC address prefix 80:7d:3a to appear on your local network
2019-07-10 18:58:50,536 [tools/terkin.py] INFO   : Sending an ARP ping to 192.168.178.0/24 to find devices already connected
2019-07-10 19:01:27,448 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:01:27,960 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:01:29,087 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:01:30,110 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:01:41,885 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:07:27,486 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:07:28,508 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:07:29,532 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}
2019-07-10 19:07:30,556 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}

Hier die Daten, wie sie bei swarm.hiveeyes.org ankommen: Wichtig ist eigentlich nur der timestamp, wie gesagt UTC+002, d.h. 19:01 und 19:07 und 19:13 oben tauchen aber nur die beiden ersten Übertragungen auf!

2019-07-10T17:01:42.421064Z,3.78,DE,22.0,22.0,21.75,181529,1009.73,0.981,0.981,15,,31722.0,2,78,181529.7,,9742.833,44.84,21.75,-22404.0,,,1,,35.56522,-84,2219360,22.47,21.4375
2019-07-10T17:07:42.751094Z,3.786,DE,21.8125,21.875,21.75,181891,1009.76,0.983,0.983,15,,31722.0,2,78,181891.8,,9705.334,43.46,21.75,-22404.0,,,1,,35.56522,-85,2217600,22.33,21.3125
2019-07-10T17:13:42.890994Z,3.786,DE,21.6875,21.75,21.5,182253,1009.71,0.982,0.982,15,,31722.0,2,78,182253.7,,9726.501,44.42,21.5,-22404.0,,,1,,35.56522,-85,2217600,22.16,21.1875

Andreas · July 10, 2019, 5:26pm

Hi Clemens,

schön dass es bei Dir nun grundsätzlich klappt und danke fürs Durchwurschteln.

Das sollten wir beobachten. Ich hoffe dass wir ggf. irgendwie nachlegen können. In der Zwischenzeit ist die Hauptsache, dass es gleich mit dem ersten klappt.

Viele Grüße,
Andreas.

clemens · July 10, 2019, 7:30pm

Ich habe das Monitoring mal weiterlaufen lassen. Es bricht nicht komplett ab, hat aber sporadisch Aussetzer. Hier wurden Datensätze übertragen:

2019-07-10T17:13
2019-07-10T17:19
2019-07-10T17:25
2019-07-10T17:31

beim Monitoring fehlen hier aber Einträge und tools/terkin.py monitor liefert keine records.

Dann werden wieder Daten übertragen und auch das Monitoring registriert Aktivität:

2019-07-10T17:37
2019-07-10T17:43
2019-07-10T17:49
2019-07-10T17:55
2019-07-10T18:01
2019-07-10T18:13

Hier sind alle Daten da! Nun fehlen wieder loggings beim Monitoring:

2019-07-10T18:19
2019-07-10T18:25
2019-07-10T18:31

Danach passt es wieder eine Zeit lang:

2019-07-10T18:37
2019-07-10T18:43
2019-07-10T18:49
2019-07-10T18:55

Hier wieder nicht:;

2019-07-10T19:01
2019-07-10T19:07
2019-07-10T19:13

clemens · July 10, 2019, 7:39pm

Mehrere devices werden nun auch erkannt und auch der WiPy mit dem anderen MAC-Anfang:

2019-07-10 21:34:53,397 [tools/terkin.py] INFO   : Found device at {'mac': '30:ae:a4:4f:fc:84', 'ip': '192.168.178.26'}
2019-07-10 21:37:34,643 [tools/terkin.py] INFO   : Found device at {'mac': '80:7d:3a:c3:37:b0', 'ip': '192.168.178.25'}

Der WiPy schickt gerade alle 10 Sekunden Daten:

2019-07-10T19:39:34.974497Z,11.262,DE,78,304.184,1,29.82608,295,2395168,-74,304,2
2019-07-10T19:39:44.927894Z,11.262,DE,78,315.346,1,31.73914,306,2395168,-72,315,2
2019-07-10T19:39:55.157607Z,11.262,DE,78,325.544,1,31.73914,316,2395168,-70,325,2
2019-07-10T19:40:05.393314Z,11.262,DE,78,335.799,1,31.73914,326,2395200,-72,335,2
2019-07-10T19:40:15.510306Z,11.262,DE,78,345.93,1,31.73914,336,2395168,-73,345,2
2019-07-10T19:40:25.418235Z,11.262,DE,78,355.835,1,31.73914,346,2395168,-70,355,2
2019-07-10T19:40:35.588002Z,11.262,DE,78,366.004,1,31.73914,356,2395296,-74,365,2
2019-07-10T19:40:45.560182Z,11.262,DE,78,375.957,1,31.73914,366,2395296,-71,375,2
2019-07-10T19:40:55.752087Z,11.262,DE,78,386.168,1,31.73914,377,2395296,-74,386,2

Allerdings sind keine externen Sensoren dran, d.h. der ist recht schnell mit dem Abfrühstücken und nur seeeeehr sporadisch im Monitoring auf, vielleicht doch zu schnell für die aktuelle Version oder das gewählte Verfahren!?

Andreas · July 10, 2019, 7:58pm

Hi Clemens,

vielen Dank für Deine Tests.

Das ist durchaus möglich. Könntest Du aber erst einmal versuchen, die Priorität des entsprechenden Prozesses höher zu setzen? Dafür gibt es verschiedene Tutorials im Netz:

Gerade im Kontext von Winpcap oder anderen Wekzeugen aus der Verwandtschaft ist das oft notwendig für eine maximale Ausbeute, hier z.B. bei Netsniff-NG:

Good luck.

Viele Grüße,
Andreas.

clemens · July 10, 2019, 8:11pm

Welchen Prozess muss ich denn genau höher setzen? Die Windows Power Shell oder Python oder Winpcap oder …?

clemens · July 11, 2019, 10:32am

3 posts were merged into an existing topic: Stabilität und längere Testzeiträume der neuen Micropython-Firmware

Andreas · July 11, 2019, 10:44am

Ja. Alles was Dir in dem Kontext relevant erscheint. Trial & Error.

Andreas · July 11, 2019, 10:36am

Das paradoxe ist ja, dass Daten in der Tat durchkommen – nicht? Trotzdem scheint der Eumel irgendwie mit Camouflage durchs Netzwerk zu fliegen…

SCNR; Ich tippe wie immer aufs Kabel.

Gedanken

… oder aber der ARP Monitor sampled nicht schnell genug unter Windows. So ein Workstation-Kernel (Windows NT) ist natürlich hochoptimiert für eine gute Responsiveness bei Benutzerinteraktionen. Da ist es sehr wahrscheinlich, dass man Prioritäten individueller Prozesse für andere Arten von Workloads anpassen muss. Zumindest wahrscheinlicher als unter Linux, das mittlerweile zwar superfair für verschiedenste Arten von Workloads scheduled, die Nase aber weiterhin eher in anderen Bereichen vorne hat.

Zwischenfazit

Natürlich kann es sein, dass die eben erschlossene Discovery-Schwummse nicht in allen Umgebungen und Lebenslagen ordentlich funktioniert. Ich hoffe aber natürlich gleichermaßen auf das Beste, dass wir etwaige Schluckaufs in den Griff bekommen.

clemens · July 12, 2019, 10:46am

Wir haben gestern noch etwas gedebuggt und ich konnte nun unter Windows auch den “schnellen” WiPy (da ohne Sensoren) mit tools/terkin.py monitor “einfangen” indem wir in der terkin.py den timeout verändert haben. Nun geht es auch ohne die Priorität einzelner Prozesses in Windows höher zu setzen:

Lasst uns die Änderung mal in den master branch übernehmen, vielleicht hilft das noch anderen:

Andreas · July 12, 2019, 10:50am

Hi Clemens,

schön, dass es nun auch bei Dir gut klappt. Ich hatte gestern bereits den Timeout beim ARP-Ping von 2 auf 5 Sekunden gestellt. Reichte das bei Dir noch nicht?

Viele Grüße,
Andreas.

clemens · July 12, 2019, 11:34am

Hatte gestern nur mit 10 Sekunden getestet, nun noch mal mit 5 Sekunden. Bei beiden Einstellunge in Zeile 129 der /tools/terkin.py(timeout=5 vs. timeout=10).funktioniert es gerade nicht 100% reliabel.

Habe den Eindruck, dass es mit 10 besser läuft als mit 5.

Andreas · July 12, 2019, 12:00pm

Dann müsste es mit 2 Sekunden oder gar einer Sekunde nochmals schlechter werden? Bem.: Ich will hier und auch generell nicht Mikrooptimierung betreiben, aber schnelle Konvergenzzeiten wären gerade an dieser Stelle sehr schick. Robustheit geht aber natürlich vor.

Nur: Falls die Ursache eine ganz andere ist, dass es bei Dir manchmal einfach nicht klappt, würde ich ungern die 10 Sekunden als Default drin haben, solange man den Wert noch nicht individuell konfigurieren oder er sich heuristisch der Umgebung ^[1] anpassen kann.

$RUNNING_IN_HELL

– Haben wir früher immer als Konstante zur Signalisierung verwendet, wenn wir FOSS Software unter Windows betreiben mussten. ↩︎

Andreas · July 22, 2019, 7:41pm

Detect operating system (Windows vs Linux) with a Makefile

Für Dinge wie

wollte ich gschwind fragen: Was ist denn in der Umgebungsvariable “OS” enthalten, wenn man aus unterschiedlichen Richtungen auf sie schaut? Also unter

a) Windows nativ

echo %OS%

b) Innerhalb des WSL

echo $OS

Das sollte hoffentlich reichen, die Systeme differenzieren zu können. Unabhängig davon würde mich noch die Ausgabe von "uname -a" innerhalb des WSL interessieren, wenn man – so wie @clemens und @MKO – zum Ubuntu-Flavour gegriffen hat.

Bei

ist das jetzt so drin wie bei

vorgemacht.

Bei Bedarf steht drüben bei os agnostic - OS detecting makefile - Stack Overflow, wie man es richtig macht – auch für weitere Betriebssysteme.

Andreas · July 22, 2019, 8:03pm

A post was merged into an existing topic: MicroPython-Firmware schmirgeln (240er)

clemens · July 22, 2019, 8:30pm

Was ist “nativ” hier? Die Eingabeaufforderung gibt zurück:

C:\>echo %OS%
Windows_NT

Die Windows PowerShell kennt die Variable nicht

PS C:\> echo %OS%
%OS%

root@XPS13-CGruber:/# echo $OS

gibt eine leere Zeile aus

root@XPS13-CGruber:/# uname -a
Linux XPS13-CGruber 4.4.0-18362-Microsoft #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

MKO · July 22, 2019, 8:41pm

a) Windows CMD

C:\Users\user>echo %OS%
Windows_NT

b) WSL gibt er gar nichts aus

c) uname -a

Linux Werkstatt 4.4.0-18362-Microsoft #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

im Make

echo %OS%
%OS%

Andreas · July 22, 2019, 8:45pm

Vielen Dank. Dann kann das gerne so bleiben und Ihr könnt die Konstante unter Windows ggf. ebenfalls verwenden, falls benötigt.

## Reset port or even USB subsystem
reset-port:
ifeq ($(RUNNING_IN_HELL),true)
	@echo "TODO: Reset USB subsystem on Windows"
else
	@echo "Restarting USB subsystem"
	systemctl restart usb
endif

Nix für ungut wegen dem Naming. Sieht ja niemand ;].

Andreas · July 29, 2019, 9:21pm

Die Betriebssystemerkennung innerhalb von mpy-mk haben wir jetzt endlich auf Basis Eurer Eingaben aufgemöbelt. Vielen Dank!

cc @clemens, @MKO

P.S.: Wir haben kürzlich die Kategorie Firmwareschmiede / Firmware development - Hiveeyes insofern umgestellt, dass neue Nachrichten nicht mehr automatisch bei “Latest” angezeigt werden. Der Grund dafür ist, dass auf diesem Kanal gerade viel zu viel Noise herrschte und wir das daher ein wenig einschränken wollten.

Wenn Ihr Euch für Inhalte aus dieser Kategorie interessiert, bitten wir Euch daher, ggf. die entsprechenden Topics aktiv zu abonnieren. Das klappt links unten am Beitrag bei