Cypheros Multimedia Forum

1.0.7 fixt das. 

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

Oh! schnell er ist...
Hat Frau Dich mit Liebesentzug aus dem Schlafzimmer gejagt ?   

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



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:

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  )

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

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 

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)