@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.
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.
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 detectedGenau. 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!
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.1875Hi 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:13Mehrere 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.
… 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.
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:
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.
$RUNNING_IN_HELL
– Haben wir früher immer als Konstante zur Signalisierung verwendet, wenn wir FOSS Software unter Windows betreiben mussten. ↩︎