Cypheros Multimedia Forum

Versions-Historie:

1.0.8

• Farbe des Receiver-Icons ist nun gelb, wenn der Receiver im Standby ist

1.0.7

• Ist Box beim Programmstart nicht erreichbar dann wird es immer wieder probiert, bis eine Verbindung möglich ist
• Wenn beim IP-Scan ein Gerät gefunden wird, welches Zugangsdaten benötigt, erscheint ein Dialog

1.0.6

• Änderung der Spracheinstellung wird sofort ausgeführt
• Gefundene Receiver werden mit IP und Modelbezeichnung angezeigt
• IP-Scan kann abgebrochen werden
• Die Dauer der Historie an gesammelten Daten ist einstellbar

1.0.5

• Schnelleres Scannen von IPs über ICMP
• Passwörter werden nur bei Bedarf übertragen

1.0.4

• Funktionierte nicht bei Boxen, die mit einem Passwort geschützt sind
• Default Timeout für den IP-Scan auf 200ms reduziert und über Registry-Key IPScanTimeOut einstellbar
• Über die Registry-Keys OverrideScanIP und OverrideScanNetmask kann ein eigenes Netzwerk für den Scan vorgegeben werden

1.0.3

• Fehlerhafte Berechnung der Orbitalposition für Satelliten mit Westausrichtung

1.0.2

• Skalierungs-Problem behoben

1.0.1

• Initiale Version

Hmm, die Funktion "Suche Receiver im LAN" ist aber recht lebenszeitfeindlich  :'(

Schneckst Du da ganz braun alle IP Adressen ab und versuchst ein Telnet, oder was?
(wäre nicht schlecht, wenn er zeigen würde, WAS er da gerade so testet... ich hab hier ein "ungewöhnliches" LAN (*) mit einer Subnetzmaske von 255.255.248.0) Da scheint er Tage zu brauchen um den Bereich abzuschnecken.

Bei so einem Scan macht man:
* ping -c1 (nur ein Paket) auf die gewünschte Adresse
* wenn erfolgreich, dann Telnet probieren
(ich kann Dir auch aus meinen alten Sourcen die fertige Funktion raussuchen, sollte noch auffindbar sein... Aber Du willst es ja sicherlich in der Sprache der Müslifresser...)

Das geht tausendmal schneller, probier es aus.

Ach ja, Abbrechen lässt sich das Elend (trotz Knopf) auch nicht.
Geht nur mit der Keule des Taskmanagers...
--------------------------------------

(*) jaja, ich weiß... ALLES an MAM ist "ungewöhnlich"  ;D Aber schon neben der Haustür warnt ein Schild "Ich hab keine Macken, das sind nur Special Features".

Aber mal ne grundsätzliche Frage: WAS soll das Tool eigentlich tun?
Bei mir sitzt es nur dumm und untätig rum, erzählt mit was von 0% und gibt einen nervigen, tiefen, Dauerton aus?
Hmm.jpg
Hab beim Receiver extra das komplizierte V6 LAN deaktiviert, damit Dein Tool es einfacher hat:
aaa.jpg

Ich hab dann mal die Engelsgeduld aufgebracht und die Schleife zuende laufen zu lassen, das Ergebnis ist sowohl demoralisierend, wie auch fragwürdig:
Unbenannt-1.jpg
WAS wollen uns die Knöpfe in der Msgbox denn sagen???

Ist bei mir leider ebenso wenig "erhellend" (ich habe allerdings nicht suchen lassen, sondern die Zugangsinfos direkt eingegeben):
Screenshot 2026-04-17 091704.png
Auch das Verzeichnis ProgramData\Cypheros\EnigmaSignalMeter bleibt jungfraeulich...

Kann es sein, dass da ein paar (wichtige?) Bibliotheken fehlen, die dem Otto-Normal-Usah nicht zur Verfügung stehen?

(hab auch "Direkt Eingabe" gemacht, hilft nix. Der Unterschied ist nur, dass er erkennt, wenn der Receiver AUS (deep Standby) ist und dann meckert. Aber wenn AN, keine Meldung aber auch keine Anzeige...)

OK, habe es mit mehreren Receivern und verschiedener Firmware (VTI 15, OpenATV 7.6, OpenPLI 9.2) getestet, bevor ich es Online gestellt habe.

Kann aber sein, dass älteren Boxen Probleme machen.

Der Netzwerkscanner nimmt alle IPs, die das lokale Netzwerk hergibt (IP mit Netmask) und über eine HEAD-Anfrage eine Antwort zu bekommen. Dabei wird maximal 300ms gewartet. Damit es schneller geht, laufen 30 Tasks gleichzeitig.

Wenn Debug aktiviert ist, werden die von der Box heruntergeladenen Dateien unter "C:\ProgramData\Cypheros\EnigmaSignalMeter\debug" gespeichert. Auch ein IPScan.log für die Suchfunktion ist dabei.

Wenn es nicht funktioniert, wäre es schön, wenn ihr mir die Logs schicken würdet. Am Besten gezippt per E-Mail an support(ät)cypheros.de

Die Liste mit den gefundenen Receivern sollte so aussehen:

Screenshot 2026-04-17 113931.png

Wenn die Liste leer ist, dann wurde offenbar nichts gefunden.

Ja wird nix gefunden :-(
Aber auch mit manueller Eingabe der Adresse küt nix!

170426 08:24:55:047 Host: http://192.168.0.22 (401) 6 ms
170426 08:24:55:047 Host: http://192.168.0.28 (401) 5 ms
170426 08:24:55:047 Host: http://192.168.0.6 (200) 34 ms

Also getestet hat er die 28 wohl schon, nur, gefällt ihm da mein ATV 7.6 wohl nicht.
WAS will er denn da wissen (ich kanns aber auch ausscannen mit Wireshark...) ?

Und, wie gesagt, 300ms ist lame, das geht unter 1ms!

Also der (triviale) Grund für die Ablehnung ist, dass Du gar kein Loosername/Pisswort mitschickst bei der ersten Anfrage. Da lehnt die Box natürlich jegliches Gespräch ab.
Hast Du bei Dir keine Passwörter eingerichtet???

Och.jpg
Da ist nur ein verschlüsseltes Passwort, kein Usah!


Nix.jpg

(danach kommt nur noch SCHWEIGEN)

OK, checke ich mal.

um es nochmal deutlich zu machen: Du schickst nur Root, kein Passwort
aaaa.jpg
So sollte es richtig sein:
asdasd.jpg

Oops  :o  nun kennt jeder mein "geheimes" Passwort  ;D LOOOL

Um es zusammenzufassen: der Ablauf ist auch falsch, eigentlich muss der erste Get OHNE Credentials erfolgen, dann kommt als Antwort "Unauthorized", danch wiederholt man den Get MIT (vollständigen) Credentials. Aber vielleicht sind auch Abkürzungen erlaubt. Keine Ahnung, HTTP ist nicht so meine Muttersprache :-)

Mit Wireshark-Protokollen kann ich leider nicht dienen, und wenn offenbar schon die Login-Versuche nicht sauber abgehandelt werden, brauche ich auch nicht zu betonen, dass bei mir VTi 15.0.04 laeuft.

Wg. der Scan-Dauer: Die Suche durch die 64k APIPA-Adressen 169.254.0.0/16 dauert offenbar so ihre Weile.
Bei mir ist die IPScan.Log knapp 13MB gross.  :o
Ach ja: Die Adresse antwortet lautet Log mit 401 - Unauthorized.
Mir ist auch nicht ganz klar, warum der grosse APIPA-Bereich 4x durchlaufen wird. Meine beiden tatsaechlichen lokalen (fast leeren) Netze sind in 6 Sekunden durch. (Edit: Anscheinend geht er alle gefundenen Adapter durch, und damit auch die OS-internen. Vielleicht koennte man die Suche auf die "verbundenen" Netzwerke einschraenken, damit's schneller geht...)

Anscheinend wird auch der debug-Ordner erst angelegt, wenn ein Scan durchgefuehrt wird, und noch nicht, wenn die Adresse vorgegeben wird.

Zitat von: tsduser am April 17, 2026, 12:40:54Wg. der Scan-Dauer: Die Suche durch die 64k APIPA-Adressen 169.254.0.0/16 dauert offenbar so ihre Weile.

Wie schon mehrfach erwähnt, sein Ansatz ist suboptimal bis naiv.
Da kann man deutlich mehr Pep reinbringen, aber erstmal muss es laufen, auch MIT Passwort...

Danke, bin dran. Da ist noch einiges im Argen. Werden auch die Passwörter in den Logs maskieren.

OK, die 1.0.4 ist Online und sollte nun auch mit Passwort funktionieren.

Eine Versions-Historie habe ich mal in den ersten Post gepackt.

Löppt.

Und: Danke!

Vielleicht zwei Vorschlaege:
- Das Passwort (oder auch den Benutzernamen) verschluesselt in der Registry ablegen
- Den maximalen Anzeigezeitraum einstellbar machen (90sec ist an sich nicht schlecht. Aber ich empfange ueber Kabel mit dauerhaft 100%, kaempfe jedoch derzeit mit einzelnen Aussetzern, die viel seltener passieren.)

Wohlgemerkt: Nur Vorschlaege! :D

SchauMalEinerGuck!  ;D
SchauMalEinerGuck.jpg
Scheffe braucht halt nur manchmal gezielte Tritte vors Schienbein :-)
200ms ist immer noch nicht akzeptabel, arbeite Dich bis unter 1ms vor!

Minimum ist 10. Kannst du in der Registry eintragen unter "Computer\HKEY_CURRENT_USER\Software\Cypheros\EnigmaSignalMeter\Settings" über ein DWord mit dem Namen IPScanTimeOut .

Die Boxen (VTI, Zgemma) hier haben so zwischen 7ms und 91ms Responsetime.

Zitat von: Cypheros am April 17, 2026, 15:27:45Minimum ist 10. Kannst du in der Registry eintragen unter "Computer\HKEY_CURRENT_USER\Software\Cypheros\EnigmaSignalMeter\Settings" über ein DWord mit dem Namen IPScanTimeOut .

Das liegt nur wie erwähnt, an Deiner falschen Suchmethode (die zumal noch extrem gefährlich ist. Du drückst JEDEM Benutzername & Passwort aufs Auge, auch wenn er sie gar nicht wissen will. Senden nur nach ANFORDERUNG!!!)

Jede TCP / HTTP Verbindung ist um Äonen lahmer, als ein PING (der über ICMP läuft)
Eigentlich löst er einen ARP Chat aus bei V4 (in meinen Listings die allerersten Pakete, die mit "whohas ...?"), bei V6 gibts aber keinen ARP mehr, dafür NDP. Damit man nicht kompliziert unterscheiden muß, nimmt man PING, der macht das dann für Dich und liefert das Ergebnis bevor Dein HTTP Request überhaupt angenommen wurde.
Erst, wenn PING durchging, lohnt sich HTTP. Dann sparst Du Dir die Unmengen von Timeouts (egal ob 90 oder 300ms, alles reine Zeitverschwendung).

Erfahrungsgemäss hat jede Programmiersprache irgendeinen PING Befehl.

Hier eine Trivialfunktion in python:


import ping3;
def myping(host):
    try:
        resp = ping(host)
    except:
        return False

    if (Show):
        print("ping",host,"ergibt",resp)

    if resp == False or resp == None:
        return False
    else:
        return True

Im Kontext wird das dann so verwendet:
 
for Name,MinPower,Comment,Von,Bis,Display,Zweitgeraet in Devices:

        if (myping(Name) == False):
            if (Show):
              print(Name,"antwortet nicht auf PING: Uebersprungen!")
              continue


        IsOn,PowerUsed,Temp,Hum=ReadShelly(Name,False)


Das geht eine Liste von Hosts durch (hier Shelly Steckdosen/Thermometer usw.), guckt nach, ob das jeweilige Gerät erreichbar ist und bei positivem Bescheid liest es per HTTP die Daten des Gerätes aus (python Funktionen können mehr als ein Ergebnis liefern, deshalb die vielleicht ungewohnte letzte Zeile, oder die "komische" Schleife)

Mal was Anneres  ;D

WAS will mir das Tool eigentlich sagen?

Jjjj.jpg

97% klingt gut, aber die Aussagekraft ist doch arg limitiert. Das zeigt ja eigentlich nur an, wie gut der Verstärker des Multischalters durch kommt.

Ist ja nun nicht das Signal vom LNB.
(zumindest nicht 1:1)

Das ist der Signalpegel, den der Empfänger in der Enigma-Box rausgibt. Der wird ja auch in der Box irgendwo im Sat-Finder angezeigt. Das ist aber ein Wert der keine objektive Größe darstellt, die man mit einem anderen Receiver, der einen anderen Tuner hat, vergleichen kann.
Zwar könnte ich noch andere Werte aus dem Tuner auslesen, wie BER zum Beispiel aber die sind noch weniger aussagekräftig. BER ist bei den meisten Boxen immer 0.
Ich könnte aber zukünftig auf den aktuellen Sender Streamen und dabei Fehler registrieren. Oder ich könnte alle Transponder durchzappen und ein Spectrogram über den empfangbaren Frequenzbereich erstellen.

Neue 1.0.5 benutzt ICMP um schneller zu Scannen.

Zitat von: Cypheros am April 17, 2026, 22:26:38Neue 1.0.5 benutzt ICMP um schneller zu Scannen.

Na, da geht der Suchlauf doch gleich viel flotter ab, nicht?
@tsduser, probier auch mal aus!

Ach ja, der "Abbrechen" Knopf im Suchlauf geht immer noch nicht :-(

Zitat von: Cypheros am April 17, 2026, 20:39:19Das ist aber ein Wert der keine objektive Größe darstellt, die man mit einem anderen Receiver, der einen anderen Tuner hat, vergleichen kann.

Hatte ich befürchtet. Ist also nur "Balsam für die Seele".
Ich kann Deiner Idee mit der Fehlerüberwachung auch leider nur einen Dämpfer verpassen. Nur bei Unwetterlagen korreliert dieser Wert wirklich mit den Empfangsfehlern. Viele "normale" Fehler schlüpfen ungeahndet durch.

Du willst also den TSD zum Videorekorder ausbauen? So ein Ersatz für DVB-Viewer+Media-Server ?

Zitat von: Mam am April 18, 2026, 05:48:46Hatte ich befürchtet. Ist also nur "Balsam für die Seele".

Nein, es ist eine Vergleichsmöglichkeit, um zu sehen ob es bei bestimmten Sendern oder Satelliten zu Problemen kommt. Hier zum Beispiel ein Sender auf 5°W mit einer viel zu kleinen drehbaren 60cm Schüssel. Der schwankende Pegel zeigt sich auch durch Empfangsstörungen bei Bild und Ton.

Screenshot 2026-04-18 060825.png

Zitat von: Mam am April 18, 2026, 05:48:46Du willst also den TSD zum Videorekorder ausbauen? So ein Ersatz für DVB-Viewer+Media-Server ?

Ich denke nicht. War eher als günstige alternative für ein externes Sat-Messgerät gedacht. Theoretisch könnte ich das auch zu einer Handy-App machen.

Zitat von: Cypheros am April 18, 2026, 06:14:32Theoretisch könnte ich das auch zu einer Handy-App machen.

Da man die Pegelmesser beim Einrichten der Schüssel braucht, wäre das wohl die sinnvollste Anwendung.
(... sagte der alte Händi-Hasser  ;D )

Ich brauche meins tatsächlich auch nur zum telefonieren  :D

Allerdings gibt es schon dutzende Apps, die so etwas können.

Ich telefonier damit sogar nur kaum bis gar nicht. Hab das Dingen nur, weil bestimmte Firmen inzwischen gar keine Webseiten für Ihre Produkte mehr anbieten (z.B. Amazon Alexa) sondern nur noch "Apps".
Die braucht man dann zumindest zur Ersteinrichtung. Danach wandern sie wieder ins Datenklo.

Dein "Tool" hat übrigens noch einen weiteren, kleinen, Glitch:

* Wenn lange keine Verbindung hergestellt wurde (also der Receiver aus dem ARP Cache verschwunden ist), funktioniert der Verbindungsversuch auch mit fest hinterlegter Adresse nicht.

Da wird dann wohl das Timeout doch zu gering gewählt worden sein.

Startet man das Tool danach neu, gehts dann auch brav.

Du solltest vielleicht bei hinterlegter Adresse mehrere Verbindungsversuche (3?) probieren, bevor Du aufgibst...

PS: wenn Du nicht für jeden Versuch immer eine Stunde lang warten willst, empfehle ich den Befehl "ARP -d *", der löscht den Cache...

1.0.7 fixt das.  ;D

Zitat von: Cypheros am April 19, 2026, 07:30:431.0.7 fixt das.  ;D

Oh! schnell er ist...
Hat Frau Dich mit Liebesentzug aus dem Schlafzimmer gejagt ?  ;D  :-*

Na ja, da gibt es noch was, was eine 1.08 erfordert ...  ;D

asdasd.jpg

Das rote Icon bedeutet ja "keine Verbindung", aber es unterscheidet nicht, ob die Box wirklich nicht an ist (z.B. "Deep Standby") oder zwar im LAN erreichbar, aber im "normalen Standby".

Du solltest da vielleicht noch eine Stufe "gelb" hinzufügen, so dass der Anwender sieht "Verbindung ist korrekt konfiguriert, der Receiver ist nur gerade im Standby".

Außerdem ist mir unklar, WELCHE Empfangsstärke von WELCHEM Tuner er anzeigt. Im Prinzip müsste da ne Liste kommen mit allen Werten...

Die Web-Api gibt leider nur Infos zum gerade laufenden Sender (egal auf welchem Tuner).

Mit der 1.0.8 sieht es jetzt so aus im Standby:
Screenshot 2026-04-19 144616.png

Zitat von: Cypheros am April 19, 2026, 14:47:40Mit der 1.0.8 sieht es jetzt so aus im Standby:

Fehr Föhn!
(hab heute meinen Urmel-aus-dem-Eis-Mupfel-Tag  ;D )

Das mit dem Tuner hatte ich schon befürchtet, das schmälert den Wert des Tools erheblich. So kann man keine heimlichen Messungen an FRAUEN vorbei machen :-(

Wenn ich Zeit finde, kann ich ja mal schauen, ob man nicht über ein zusätzliches Plugin an alle Tuner-Infos kommt.

Zitat von: Cypheros am April 19, 2026, 15:55:50Wenn ich Zeit finde, kann ich ja mal schauen, ob man nicht über ein zusätzliches Plugin an alle Tuner-Infos kommt.

Iss nu nich sooo wichtich, aber wenn Du es wirklich zum Einrichten einer Schüssel nehmen wolltest, würde es ja Sinn machen, wenn es ALLE Satelitten anzeigen könnte mit mehreren Tunern...

Das hat sich ja super entwickelt so ueber's Wochenende  :D
Auch wenn noch immer die 64k APIPA-Adressen mehrfach durchsucht werden, so ist er jetzt nach ca. 13,5 sec damit fertig, und findet dabei meinen Uno 4K SE, auch ohne dass ich auf die Spruenge helfe.
60min ist sicher ein fairer Kompromiss, wenn das Tool mal gedacht war zum Satellitenschuessel-Ausrichten. Liesse man noch laenger laufen, so wuerden sich vmtl. kurze Glitches und so ueberhaupt nicht mehr im Graph ausmachen lassen, auch nicht bei 4K. (Jemand ganz pingeliges wuerde jetzt noch schreiben, dass man dann auch die Werte nicht noch hoeher im Dialog einstellen koennen sollte, aber das waere eben Jammern auf allerhoechstem [ueberfluessigem] Niveau.)
Abfragen an alle Tuner gleichzeitig waere sicher nicht schlecht, und falls die Receiver doch irgendwie auch eine sinnvolle BER-Info ausgeben koennten, waere das ebenfalls nicht verkehrt. Wie erwaehnt: bei Kabelanschluss haengt die Linie permanent bei 100% Signal. Das waere vielleicht mit einer "privaten" Anlage auch anders, aber ich wohne hier zur Miete...

Auf jeden Fall und noch einmal ganz ausdruecklich: HERZLICHEN DANK!

Zitat von: tsduser am April 19, 2026, 19:00:36Auch wenn noch immer die 64k APIPA-Adressen mehrfach durchsucht werden,

Nee, tut er nicht, das Log ist nur verwirrend, weil er gleich 30 Tasks anwirft, die unterschiedliche Bereiche abschnecken. Dadurch sieht es manchmal so aus, als würde wieder zurückgesprungen.
Die 30 Tasks sind zwar im Prinzip eine gute Idee, aber "too much". 2 oder max 3 würden denselben Effekt bringen. Aber nach dem Motto "viel hilft viel" nimmt er das Risiko eines aktiven Firewalls, der sauer auf Portscans ist, in Kauf.
(aber dank Umstieg auf ARP-first wird das abgefedert, ARP geht an jedem Firewall vorbei)

Auch wenn's rechthaberisch klingen mag: Tut er doch.

C:\ProgramData\Cypheros\EnigmaSignalMeter\debug>find "169.254.0.1 " IPScan.log

---------- IPSCAN.LOG
190426 18:35:48:338 Host: http://169.254.0.1 (0) 0 ms, no answer
190426 18:36:01:085 Host: http://169.254.0.1 (0) 0 ms, no answer
190426 18:36:01:149 Host: http://169.254.0.1 (0) 0 ms, no answer

Rechthaberisch deshalb, weil's bei der mittlerweile geringen Gesamtdauer echt egal ist, und bei den allermeisten Leuten hoechstwahrscheinlich sowieso nicht so viele Receiver stehen, dass es unzumutbar waere, deren IP-Adressen selber einzutragen. Ist 'ne reine Komfortfunktion, meine ich.

Hi,

kannst du mir mal das ganze log schicken, damit ich mir das genauer anschauen kann?
Meine Tests zeigen nur ein einzelnes Ping je IP mit einem Timeout von 10ms. Mich wundert, dass es bei dir 0 ms sind. Es wird offenbar gar kein Ping rausgeschickt. Vermutlich wird der Ping schon beim Senden blockiert und wartet nicht auf den Timeout.

Das Log sollte eigendlich so aussehen:
210426 08:18:58:371 Host: http://192.168.0.236 (0) 16 ms, no answer
210426 08:18:58:371 Host: http://192.168.0.242 (0) 14 ms, no answer
210426 08:18:58:371 Host: http://192.168.0.244 (0) 14 ms, no answer
210426 08:18:58:371 Host: http://192.168.0.199 (0) 31 ms, no answer
210426 08:18:58:371 Host: http://192.168.0.232 (0) 32 ms, no answer
210426 08:18:58:371 Host: http://192.168.0.233 (0) 32 ms, no answer

Ruhig Brauner  ;D
Nicht jeder hat so ein lahmes LAN, wie Du.

Und manche OS' sind auch in der Lage genauere Zeitangaben zu liefern:

[root@l3router ~]# ping f
PING f (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.566 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=64 time=0.571 ms
64 bytes from 192.168.0.4: icmp_seq=2 ttl=64 time=0.186 ms
64 bytes from 192.168.0.4: icmp_seq=3 ttl=64 time=0.532 ms
^C

Mehr als 1ms im LAN? Abreissen und neu bauen!

Das ist wohl ein Mistverständnis  ;)

Wenn die andere Seite nicht antwortet (no answer) sollte der Thread aber mindestens 10ms warten, bevor er aufgibt. Zumindest solange sollte man doch schon auf eine Antwort warten. Bei tsduser liefert er aber nach 0ms ein "no answer" obwohl die 10ms noch gar nicht abgelaufen sind. Ich vermute darum, dass der Ping beim Versuch zu Senden schon einen mit der Latte über den Schädel kriegt.

Zitat von: Cypheros am April 22, 2026, 15:36:04Das ist wohl ein Mistverständnis  ;)

Nein eher ein Unverständnis Deinerseits  ;D

Zitat von: Cypheros am April 22, 2026, 15:36:04Wenn die andere Seite nicht antwortet (no answer) sollte der Thread aber mindestens 10ms warten, bevor er aufgibt. Zumindest solange sollte man doch schon auf eine Antwort warten. Bei tsduser liefert er aber nach 0ms ein "no answer" obwohl die 10ms noch gar nicht abgelaufen sind. Ich vermute darum, dass der Ping beim Versuch zu Senden schon einen mit der Latte über den Schädel kriegt.

Nein, das ist völlig korrekt und Teil meines Vorschlags  8)

Ok, damit Du nicht dumm stirbst, hier ein wenig Nachhilfe:

ARP ist seeehr simpel.
Bei Anforderung einer Netzwerkverbindung (egal welcher), fragt das System den ARP Cache ab.
Steht da nix drin zu der anforderten IP dann passieren zwei Dinge:

1) es wird ein "ARP-Request" ("who has IP x.y.z.a?" rausgesendet
2) es wird ein Eintrag in die ARP Tabelle für diesen Host angelegt, aber mit dem Status "incomplete" (da keine Antwort erfolgt ist bislang). Kann man bei Windows und Linux schlecht bis gar nicht sehen, deshalb ein Blick in ein "richtiges" OS:

[root@l3router ~]# arp -a |grep 192.168.0.77
[root@l3router ~]# ping 192.168.0.77
PING 192.168.0.77 (192.168.0.77): 56 data bytes
^C
--- 192.168.0.77 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[root@l3router ~]# arp -a |grep 192.168.0.77
? (192.168.0.77) at (incomplete) on ix0 expired [ethernet]

bei der ersten Anfrage war noch nix im Cache, der Ping hat dann den Mechanismus ausgelöst, deshalb bringt die 2te Anfrage den Eintrag aber "incomplete" und "expired".

Expired ist aber unabhängig von Deinen ms. Der Eintrag ist von Anfang an Expired.

Erst wenn eine Antwort eintreffen würde, ändert sich der Eintrag. z.B.

[root@l3router ~]# arp -a |grep 192.168.0.9
pihole.meiszl.de (192.168.0.9) at 2c:cf:67:32:af:a4 on ix0 expires in 1197 seconds [ethernet]

das ist eine aktive Kiste und die NIC kann die MAC Adresse verwenden um den Host anzusprechen.

Solange so ein Eintrag fehlt geht GAR NICHTS raus (auch kein PING!)! denn die Karte weis ja nicht wohin.

Dein Denkfehler besteht darin, dass Du meinst, da wäre eine Warteschleife oder ein einzustellendes Timeout. Ist nicht, es wird nur der Tabelleneintrag erzeugt, danach RETURN.

(die ARP Anfrage selber zuvor geht an die globale Broadcastadresse FF:FF:FF:FF:FF)

Eine eventuelle Wartezeit wird erst in den NÄCHSTEN Befehl eingearbeitet, wenn gewünscht.

Deshalb wird ein 2ter Versuch, so wie bei ihm z.B. direkt abgewiesen, der Eintrag ist noch expired, aber nicht gelöscht, also macht es keinen Sinn zu Warten, DA KÜTT NIX! Nach ein paar Minuten wird der Eintrag entfernt und ein neuer ARP Versuch gestartet.

Gültige Einträge wurden früher nach einer Stunde verworfen, heute üblicherweise nach 20 Minuten. Der Nachteil des Caches ist es, bei Wechsel der LAN Karte dafür zu sorgen, dass weiterhin die alte Karte angesprochen wird. Betriebshektiker haben sich damit schon endlos die Karten gelegt und Fehler gesucht, die nicht da sind.
Deshalb immer bei Umbauten an "arp -a -d" bzw "arp -d *" (Windows) denken!

Du GLAUBST, bei PING wären Wartezeiten mit drin, aber das täuscht...
Das reine ICMP Echo Request/Echo Reply kennt kein Schnarchen. Das kommt erst durch die Implementierung im Shell Komando.
Da wird erst ein ARP Request erzwungen, dann erfolgt eine Pause (meist 1s) solange der Status "incomplete" ist, dann wird PING gesendet, danach wieder Pause usw...
Aber in der Library Funktion ping() gibt es diese Pausen nicht.

(aber ich geb zu, dass ist Hardcore Networking aus der Abteilung "Nerdy by Nature!". Muss man nicht wissen, funktioniert seit 60 Jahre völlig unaufdringlich und sicher)

1) Den Ausfuehrungen an sich habe nichts hinzuzufuegen, ausser vllt. den demuetigen Hinweis, dass auch ARP-Pakete in einem 1Gbit-Netz langsamer transportiert werden als in einem 10er, und deswegen die Shell dort auch laenger auf Antwort warten muss. Darum werde ich auch weiterhin mein Netz nicht abreissen.  ;D

2) ipscan.log und ipconfig /all gingen an support(ät)cypheros.de

Anyway und zur Erklaerung:
Mein Wunsch-PC-2022-aehnlicher Aufbau hat neben dem Kupfer-LAN-Port (und einer weiteren gesteckten Karte) auch Wi-Fi mit "an Board". Tatsaechlich tauchen deshalb drei "Drahtlos-LAN-Adapter" (alle mit Medienstatus: Medium getrennt und aktivierter Autokonfiguration) in der Adapteruebersicht unter Win11 auf. Weil diese drei ziemlich genau der Anzahl der APIPA-Durchlaeufe im IPScan.log entsprechen, halte ich auch ohne Wireshark-Aufzeichnung erst einmal an meiner weiter oben bereits genannten Vermutung fest, und wuerde weiterhin empfehlen, einfach "nicht verbundene" bzw. "Medium getrennt" Adapter von der Suche auszunehmen. Dort eine Antwort zu erhalten ist in meinen Augen recht unwahrscheinlich. Und vielleicht ist "nicht verbunden" ja auch die "Latte", die die Zeiten auf 0ms drueckt. Bei den real existierenden Netzen werden naemlich Zeiten so ab 7ms aufwaerts, meist bei 15ms, ausgewiesen.

Zitat von: tsduser am April 22, 2026, 18:20:11Den Ausfuehrungen an sich habe nichts hinzuzufuegen

Ich bezog mich auf Scheffe mit seinen 30ms & Co, nicht auf Dich.

Scannt der wirklich die WLAN Adapter, auch wenn sie nicht verbunden sind?

mussich mal ausprobieren...

Nee, die haben doch gar keine Adresse, da ist nix zu scannen ?!?!?

Drahtlos-LAN-Adapter WLAN:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : MediaTek Wi-Fi 6E MT7922 (RZ616) 160MHz Wireless LAN Card
   Physische Adresse . . . . . . . . : F0-A6-54-D1-BA-25
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Dein APIPA muss woanders her kommen, nicht von WLANs mit "Medium getrennt"
Noch irgendwo ein vergessenes OnBoard LAN wo ein Kabel dransteckt aber kein DHCP Server dahinter ist?

Danke Professor Network  ;D