Running the MicroTerkin Agent on Windows

Nun mecker er, weil “winpcap” nicht installiert ist:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware> python tools/terkin.py monitor
2019-07-10 17:02:10,115 [tools/terkin.py] INFO   : Local networks: ['192.168.178.0/24', '127.0.0.0/8']
2019-07-10 17:02:10,115 [tools/terkin.py] INFO   : Waiting for device with MAC address prefix 80:7d:3a to appear on your local network
Traceback (most recent call last):
  File "tools/terkin.py", line 262, in <module>
    run_monitor(mac_prefix, command)
  File "tools/terkin.py", line 256, in run_monitor
    boot_monitor(monitor)
  File "tools/terkin.py", line 240, in boot_monitor
    monitor.arp_monitor()
  File "tools/terkin.py", line 182, in arp_monitor
    sniff(prn=self.check_esp32, filter="arp", store=0)
  File "C:\Python37\lib\site-packages\scapy\sendrecv.py", line 836, in sniff
    *arg, **karg)] = iface
  File "C:\Python37\lib\site-packages\scapy\arch\windows\__init__.py", line 1352, in __init__
    raise RuntimeError("Sniffing and sending packets is not available: "  # noqa: E501
RuntimeError: Sniffing and sending packets is not available: winpcap is not installed
2019-07-10 17:02:10,633 [tools/terkin.py] INFO   : Sending an ARP ping to 127.0.0.0/8 to find devices already connected
2019-07-10 17:02:10,633 [tools/terkin.py] INFO   : Sending an ARP ping to 192.168.178.0/24 to find devices already connected
Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python37\lib\threading.py", line 926, in _bootstrap_inner
    self.run()
  File "C:\Python37\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "tools/terkin.py", line 118, in arp_ping
    ans, unans = srp(Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst=destination), timeout=2, verbose=self.VERBOSITY)
  File "C:\Python37\lib\site-packages\scapy\sendrecv.py", line 499, in srp
    s = conf.L2socket(promisc=promisc, iface=iface, filter=filter, nofilter=nofilter, type=type)  # noqa: E501
  File "C:\Python37\lib\site-packages\scapy\arch\windows\__init__.py", line 1352, in __init__
    raise RuntimeError("Sniffing and sending packets is not available: "  # noqa: E501
RuntimeError: Sniffing and sending packets is not available: winpcap is not installed

Exception in thread Thread-3:
Traceback (most recent call last):
  File "C:\Python37\lib\threading.py", line 926, in _bootstrap_inner
    self.run()
  File "C:\Python37\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "tools/terkin.py", line 118, in arp_ping
    ans, unans = srp(Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(pdst=destination), timeout=2, verbose=self.VERBOSITY)
  File "C:\Python37\lib\site-packages\scapy\sendrecv.py", line 499, in srp
    s = conf.L2socket(promisc=promisc, iface=iface, filter=filter, nofilter=nofilter, type=type)  # noqa: E501
  File "C:\Python37\lib\site-packages\scapy\arch\windows\__init__.py", line 1352, in __init__
    raise RuntimeError("Sniffing and sending packets is not available: "  # noqa: E501
RuntimeError: Sniffing and sending packets is not available: winpcap is not installed

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware>

@MKO musste es wohl nicht mehr separat installieren, weil es vermutlich bereits durch die Installation von Nmap selbst an Bord kam.

Bei Npcap: Windows Packet Capture Library & Driver bekommst Du Npcap (den Nachfolger von Winpcap) solo.

Direktlink

Npcap 0.996 installer for Windows Vista/2008, 7/2008R2, 8/2012, 8.1/2012R2, 10/2016 (x86 and x64).

Sehr viel Router sind so eingestellt, das sie die IP die sie mal für ein Gerät vergeben haben auch für eine gewisse zeit reservieren. Klappt meiner Erfahrung nach sehr gut.

Auf lange Sicht macht es sicher sinn eine .exe für Windows und diesen zweck zu Compilen. man sollte nicht, von Normalen Bob Usern erwarten das sie alle mit der Komandozeile per Du sind und sich auch noch mit Linux, Python und Co ins Bett gehen.

Aber wie ich weiß ja, das Du diesen weg auch beschreiten willst und aktuell die ersten schritte in diese Richtung gehst.
Dieser weg ist jedoch zwischendurch etwas holprig und ich glaube Jeder hier sollte bis dahin auch mal ein wenig auf Komfort und Luxus verzichten, damit es schneller vorwärts geht.
Gerade mit Windows, da es dort ja wie immer ein paar mehr Stolpersteine bei der Entwiklung gibt.

Wir haben jetzt schon 3 Möglichkeiten damit es bei Windows klappt.

  • Anaconda 500MB Pille aber unkomplizierter.
  • Python3.6 aber auf Windows etwas komplizierter einzurichten was die Libarys und den Path betrift.
  • Manuell und dafür den Router evtl umstellen, das er nicht jedes mal eine neue IP vergibt.
    oder schneller sein. Bestimmt bekommt man für Windows auch schnell eine .bat/.cmd Datei hin, die das im Autopilot macht.

Machst auf alle fälle einen Tollen Job @Andreas

Meine etwas ältere Fritz!Box kann entsprechende DHCP-Leases für den FiPy scheinbar nicht reservieren. No idea why.

Das wäre toll, wenn wir unser Tooling irgendwann einmal in eine .exe falten könnten, ja. Gerade um Benutzern die erwähnten, manchmal fehleranfälligen Einzelschritte zu ersparen. terkin.exe, anyone?

Danke für die Zusammenfassung der aktuellen Möglichkeiten zur Basis der interaktiven Konfiguration über IP und natürlich genauso für Dein Engagement! Wenn die aktuelle terkin.py-Schwummse generell unter Windows nicht möglich gewesen wäre, wäre das komplette Mikrovorhaben natürlich von vornherein nonsense gewesen. Dadurch, dass Du die Funktionalität des Prototypen drüben bei ESP32 network discovery through LAN IP scanning and Ethernet ARP monitoring - #30 by MKO bestätigen konntest, konnten wir uns diesem Weg überhaupt erst intensiver widmen.

Ich hoffe, dass es gleich auch bei @clemens gut klappt und vielleicht auch bei @waggi und anderen.

Also, auch wenn ihr hier 3 Möglichkeiten aufzählt geht bei mir bisher weder 2 noch 3. Es geht ja nicht nur darum die IP rauszufinden, das kann ich zur Not auch über die FritzBox machen, sondern der maintenance-mode soll ja auf dem Gerät auch gestartet werden.

Nun lande ich da, nachdem ich npcap installiert habe:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu\home\cgruber\hiveeyes\sources\hiveeyes-micropython-firmware> python tools/terkin.py monitor
2019-07-10 17:10:48,639 [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:10:48,639 [tools/terkin.py] INFO   : Waiting for device with MAC address prefix 80:7d:3a to appear on your local network
2019-07-10 17:10:49,157 [tools/terkin.py] INFO   : Sending an ARP ping to 169.254.0.0/16 to find devices already connected
2019-07-10 17:10:49,157 [tools/terkin.py] INFO   : Sending an ARP ping to 127.0.0.0/8 to find devices already connected
2019-07-10 17:10:49,157 [tools/terkin.py] INFO   : Sending an ARP ping to 192.168.178.0/24 to find devices already connected
2019-07-10 17:10:56,595 [scapy.runtime] WARNING: DNS decompression loop detected
2019-07-10 17:11:02,175 [scapy.runtime] WARNING: DNS decompression loop detected
2019-07-10 17:11:03,142 [scapy.runtime] WARNING: more DNS decompression loop detected
1 Like

Genau. Alternativ ist das jederzeit möglich. Wenn man die IP-Adresse kennt, kann man das Gerät folgendermaßen in den Wartungsmodus versetzen.

Das ist natürlich so wie hier geschrieben 1:1 von einer GNU/Linux/macOS shell, vermutlich braucht das für Windows (nativ) noch leichte Abwandlungen. telnet? PowerShell?

Never heard of that but totally makes my day.


With the commit from a few seconds ago, these networks will be skipped when sending out ARP ping requests. Hope this helps.

    2019-07-10 17:10:49,157 [tools/terkin.py] INFO   : Sending an ARP ping to 169.254.0.0/16 to find devices already connected
    2019-07-10 17:10:49,157 [tools/terkin.py] INFO   : Sending an ARP ping to 127.0.0.0/8 to find devices already connected

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!

2 Likes

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

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.

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

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.