home
erste Version am 10.11.2013
letzte Änderung am 28.05.2022

Pinger


Dieses Script prüft den Online-Status von eingestellten Hosts.
Änderungen am Online-Status werden zusammen mit dem jew. Timestamp in einer Datei protokolliert.

Inhaltsverzeichnis

Pinger v2
Update auf v3
Update auf v4

Pinger v2

Pinger prüft im Minutentakt, welche Hosts aus einer im Script anzupassenden Liste auf ping's antworten.
Nur einmal bei Programmstart wird der Status der erreichbaren Systeme ausgeben, danach werden nur Änderungen protokolliert.
Im Script sind die Variablen
    logfile
und
    hosts2ping
an die eigenen Gegebenheiten anzupassen.

Ausgabe von:    tail -f log_pinger.txt

Screenshot

Der Start erfolgt üblicherweise mit:     nohup pinger2.py &

Pinger verwendet statt ping das hier besser geeignete fping.
Unter openSUSE waren für fping root-Rechte nötig.
Nach
 cp /usr/sbin/fping /usr/bin/.
und
 setcap cap_net_raw+epi /usr/bin/fping
kann fping auch mit user-Rechten ausgeführt werden.

Das Python-Script: pinger.py

Update auf v3

Nach fast neun Jahren brauchts mal ein Update.
Ich möchte jetzt auch den Online-Status von Systemen protokollieren, die sich nicht im Haupt-VLAN befinden. Konkret wegen dem hier.

In der neuen pinger-Version werden jetzt auch Systeme angePINGt, die nur im VLAN10 bzw. dem GoogleWifi-Mesh bekannt sind.
Leider gibts da nur nackige IP-Adressen - keine Hostnames. Daher kommt ein Dictionary zum Einsatz, über das den IP-Adressen jeweils Hostnames zugeordnet werden können, die statt der IP-Adressen im Log landen. Hoffentlich bleibt die derzeitige Relation "IP-Adresse zu Host" im DHCP-Server der GoogleWifis lange statisch. Aber bisher (ca. eine Woche) gabs keine Änderungen.
Sieht dann etwa so aus:
20220520-183139 online  c12
20220520-204818 offline c12
20220521-135057 restart --------------------------------------------------
20220521-135057 online  8.8.8.8, GWifi-Büro, GWifi-Dach, GWifi-Schlaf, GWifi-Wohn, dlna, fb, gw2, nffw, nffw1, nffw4, ss, switch
20220521-135158 online  c12
Die vier GWifi's, nffw1 und nffw4 sind im VLAN10.

Für den Zugriff auf das andere VLAN braucht es ein System, das sich sowohl im VLAN1 wie auch im VLAN10 befindet, fping installiert hat und per ssh-KeyExchange (bzw. ohne Passwort-Abfrage) erreichbar ist.
Ich nutze dafür einfach meine DLNA-Server-VM. Die ist "always on" und hängt sogar in allen drei VLANs, die ich hier mittlerweile verwende.
Der simple Trick ist, dass der fping via "ssh remote command execution"
ssh dlna fping -a <Liste von zu prüfenden IP-Adressen im VLAN10>
auf dem entfernten System ausgeführt und dessen Ausgabe vom Script ausgewertet wird.
BTW: unter Debian (DLNA-Server-VM) muss kein Heckmeck betrieben werden, um fping mit User-Rechten ausführen zu dürfen.

Update auf v4

Die Hoffnung, dass die Relation "IP-Adresse zu Host" lange statisch bleibt, wurde enttäuscht.

Aber hier habe ich gerade gefunden, dass der nmap mehr Infos ausgibt, wenn er via sudo aufgerufen wird. Speziell kommt dann die MAC-Adresse mit:
dede@dlna:~$ sudo nmap -sP 192.168.86.0/24

Starting Nmap 6.47 ( http://nmap.org ) at 2022-05-28 09:57 CEST
Nmap scan report for 192.168.86.1
Host is up (0.00049s latency).
MAC Address: B0:6A:41:DC:6F:C7 (Unknown)
[.....]
Nmap scan report for 192.168.86.31
Host is up (-0.063s latency).
MAC Address: 64:66:B3:FA:BA:C8 (Tp-link Technologies CO.)
[.....]

Würde ich im pinger-Script nun der MAC-Adresse einen Hostname zuordnen und nmap statt fping verwenden, hätte ich es wieder statisch.
Jedoch ....leider....: der nmap meldet nicht durchgehend alle Systeme. Warum auch immer. Ist eh recht langsam. Meist über fünf Sekunden für das /24-Netz.

Für MAC-Adressen gibts ja aber noch das arp-Kommando (in den net-tools). Das liefert mir blitzschnell die auf dem DHCP-Server bekannten Relationen "IP-Adresse zu MAC-Adresse".
Etwa so:
root@dlna:~# arp -i eth0.10
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.86.62                    (unvollständig)                          eth0.10
192.168.86.41            ether   3e:98:e5:3a:19:d6   C                     eth0.10
192.168.86.22            ether   b0:6a:41:dc:67:19   C                     eth0.10
192.168.86.1             ether   b0:6a:41:dc:6f:c7   C                     eth0.10
192.168.86.31            ether   64:66:b3:fa:ba:c8   C                     eth0.10
192.168.86.70                    (unvollständig)                          eth0.10
192.168.86.69                    (unvollständig)                          eth0.10
192.168.86.36            ether   84:16:f9:9b:ac:e4   C                     eth0.10
192.168.86.25            ether   b0:6a:41:dc:6e:51   C                     eth0.10
192.168.86.55            ether   d8:50:e6:bd:99:c9   C                     eth0.10
192.168.86.35            ether   08:b4:b1:79:76:2b   C                     eth0.10
192.168.86.83            ether   26:cf:8b:76:cc:ca   C                     eth0.10
192.168.86.50            ether   38:56:3d:04:7a:7d   C                     eth0.10

Aber auch nicht zuverlässig immer alle Systeme, die online sind. Wahrscheinlich sollte ich erstmal alle 256 IP-Adressen anpingen, damit der arp-Cache aktuell gefüllt ist.
Weil auch das immer noch nicht 100% stabil war, ist jetzt noch eine Indirektion drin. Und zwar ein Dictionary mit der Relation "IP-Adresse zu MAC-Adresse". Das wird immer nur erweitert oder geändert. Es kennt also auch alte Beziehungen. Erst wenn eine IP-Adresse an eine andere MAC-Adresse vergeben wurde, wirds geändert.
Dadurch siehts nach Restart vielleicht so aus:
20220528-135125 restart --------------------------------------------------
20220528-135125 online  8.8.8.8, GWifi-Dach, GWifi-Wohn, MotoG6+, c12, dlna, fb, gw2, nffw, nffw4, ss, switch
20220528-135225 online  GWifi-Büro, GWifi-Schlaf, nffw1
Will heißen: erst beim zweiten Durchlauf werden alle Systeme angezeigt, die online sind.
Die erste Zeile alleine ist Quatsch - wie sollten die GoogleWifi-Satelliten online bzw. erreichbar sein, wenn es der Master (GWifi-Büro) nicht ist.

Somit jetzt hier pingerV4.
Mal schauen, wie sich diese Version so über die Zeit macht.