Running the MicroTerkin Agent on Windows

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!?

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.

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

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

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

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.

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:

1 Like

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.

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.

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.


  1. $RUNNING_IN_HELL

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

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.

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

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

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%

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 ;].

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

image

image