Nmap readingsGroup

[curt]

Das brachte leider nicht den gewünschten Erfolg. Keine Links auch nur zu erahnen, auch im html-Quelltext nicht. Und die letzte Spalte leer. Ok, mal spielen.

So funktioniert es, der Link ist in der ersten Spalte:

Code: [Auswählen]

define NetzwerkListe readingsGroup <>,<IP-Adresse>,<Status>,<Name> \
Netzwerk:@3,#1_ip,#1_state,(.*)_alias
[/quote]

Nun darf mich aber niemand fragen, warum das funktioniert. Und warum da @3 stehen muss und @1 nicht funktioniert.

Ich freue mich. Danke!

[curt]

Ich weiß, dass das mit nmap primär gar nichts zu tun hat. Aber in der Tabelle würde ich bei den Debian- bzw. Linux-Systemen als Information ja schön machen, wenn man sehen könnte, dass Updates vorliegen.

Wie man Updates bei entfernten Maschinen grundsätzlich erkennen kann, ist in https://www.soeren-hentzschel.at/sonstiges/debian-server-auf-updates-prufen-via-shell-script/ ganz schön beschrieben. Mit einer Frequenz von 900 aufrufen ist natürlich Quatsch.

Im Forum nach "update debian server" suchen - da findet man natürlich 5.000 Seiten, die sich mit anderen derartigen Problemen beschäftigen.

Jemand eine Idee?

[supernova1963]

Nun darf mich aber niemand fragen, warum das funktioniert. Und warum da @3 stehen muss und @1 nicht funktioniert.

Damit du antworten kannst: Die "@3" gibt die Spalte an, nach der die readings gruppiert werden und muss auf die Spalte mit der Gruppierungs-Regex, im vorliegenden Fall: (.*)_alias, zeigen.

Da der Namensaufbau der Readings bei Nmap <IP>_<Wertbezeichner> ist und nach IP gruppiert werden soll, kann man an-für-sich nach jeder Spalte gruppieren. Da aber die Werte in den anderen Spalten mit valueFormat "manipuliert" werden sollen, habe ich diese Spalte gewählt.

Gernot

OffTopic: System-/Update-Stati der gefundenen Netzwerkgeräte
Sehe ich eher als eigenes Thema. Ggf. wäre es sogar möglich, im Nmap-Modul ein Art autoCreate für fhem Devices zu ergänzen, das dann wiederum Gerät-spezifische Zusatzinformationen einholt.
Mit einer eindeutigen Beziehung zu Nmap Readings (z.B. MAC-Adresse oder Netzname), könnte man dann eine geeignete ReadingsGroup erstellen.

[curt]

Zunächst nochmals mein herzlicher Dank.

OffTopic: System-/Update-Stati der gefundenen Netzwerkgeräte. Sehe ich eher als eigenes Thema.

Das versuchte ich schon in einem eigenen Thema zu diskutieren, hier: https://forum.fhem.de/index.php/topic,85498.0.html

Das Modul SYSMON https://wiki.fhem.de/wiki/SYSMON scheint in diese Richtung zu gehen. Das habe ich installiert, allerdings lediglich auf dem FHEM-Server, (noch) nicht die Abfrage der "inneren Werte" anderer Server angefasst. Möglicherweise kann man da die Abfrage des Update-Status selbst anfrickeln. Was mir da aber weniger gefällt: Die Abfrage läuft über telnet. Das halte ich für eine ganz schlechte Idee.

Ein völlig anderer Ansatz wäre xymon, welches @Reinhart in FHEM integrieren konnte. Das habe ich nicht installiert, mich schreckt ab, dass da der nächste Webserver um die Ecke guckt. Und da fehlt mir auch jede Idee, wie man den Update-Status integiert - vermutlich überhaupt nicht.

Ggf. wäre es sogar möglich, im Nmap-Modul ein Art autoCreate für fhem Devices zu ergänzen, das dann wiederum Gerät-spezifische Zusatzinformationen einholt.

Ich habe ja inzwischen gelernt, dass alles was nicht weglaufen kann, ein Device wird. Also warum nicht, der Gedanke hat ja Charme. Das liefe wohl auf ein neues Modul hinaus? Das kann ich nicht, dafür bin ich zu frisch - oder zu alt. Wir fragen mal igami was er von diesem Gedanken hält.

@igami
Die Idee besteht darin, dass jeder Teilnehmer (Server, aber auch Clients wie Handy usw.) ein Device der (noch nicht vorhandenen) Klasse "Netzwerkgerät" wird. Ein konkretes Device hat dann Eigenschaften (Readings, ich hab's gelernt) wie IP, MAC, lastSeen, CPU_temp, platte_1_Auslastung, updates_vorhanden, da kann man sich ja viel ausdenken. Ich denke allerdings weniger an sekundengenau, eher schon an Aktualisierungswerte 300..900.

Mit einer eindeutigen Beziehung zu Nmap Readings (z.B. MAC-Adresse oder Netzname), könnte man dann eine geeignete ReadingsGroup erstellen.

MAC-Adresse ist kein Allheilmitel, ganz im Gegenteil. Ich erklär's.
Eine typische einfache Netzstruktur ist die von Kevin Schulz: Vorn der Router vom Provider, Wlan onboard. Das wächst über die Zeit, aber alles ist im 192.168.1.0/24. Und typischerweise DHCP for all. Da und nur da funktioniert die Eindeutigkeit via MAC.

In dem anderen nmap-Thread war ab und an zu lesen "aber der liefert gar keine MAC" - und dort wurde das nie aufgeklärt.

Das liegt daran, dass dann mehrere Subnetze, also mehr als ein Router im Spiele sind - nmap aber nur in einem Subnetz sein kann. Wenn es nun über eine Subnet-Grenze geht, fliegt die MAC weg. Wird von nmap schlicht nicht gesehen.

Bei mir ist es so, dass praktisch alles statische Adressen sind. Lediglich ein kleiner Bereich ist DHCP für Sonderfälle.

Damit müsste das (nicht vorhandene) IP-Device-Modul als "Kennung" alternativ IP, MAC, devAlias (von nmap-device!) haben.

Das waren meine Überlegungen dazu. Mal sehen, was @igami sagt.

[igami]

Ist wirklich schon ein bisschen offtopic mittlerweile und wir sollten es in einem andern Thread weiter diskutieren.

Warum habe ich das Nmap Modul geschrieben? Ich wollte automatisch neue Geräte im WLAN erkennen und dann automatisierte Funktionen ablaufen lassen (z.B. das Gerät einer Person zuweisen für Anwesenheitserkennung). Dabei ist es aber leider geblieben und ich nutze das Modul selbst eigentlich gar nicht mehr

[curt]

Ist wirklich schon ein bisschen offtopic mittlerweile und wir sollten es in einem andern Thread weiter diskutieren.

Gern - wo wäre es denn recht?
https://forum.fhem.de/index.php/topic,85498.0.html wäre ok?

und ich nutze das Modul selbst eigentlich gar nicht mehr

<lacht> Darf ich Dir Deinen einzigen Nutzer vorstellen?

Nein, im ernst: Warum nutzt Du es nicht mehr? Was nutzt Du nun? (Vielleicht ist das ja viel schöner ... auch für uns.)

[igami]

Gern - wo wäre es denn recht?
https://forum.fhem.de/index.php/topic,85498.0.html wäre ok?

sofern es um das Thema geht ja

<lacht> Darf ich Dir Deinen einzigen Nutzer vorstellen?

Laut Statistik "nutzen" es ja auch noch andere, bei mir läuft es ja auch noch mit, ich Werte es nur nicht aus.

Nein, im ernst: Warum nutzt Du es nicht mehr? Was nutzt Du nun? (Vielleicht ist das ja viel schöner ... auch für uns.)

Die Zuordnung von 6 Geräten zu einem Bewohner durch einen Automatismus stand nicht im Verhältnis Aufwand/Nutzen.

[curt]

Ich möchte Dich um etwas bitten. Ich möchte Dich darum bitten, Dein Modul testweise zu erweitern.

Die Zuordnung von 6 Geräten zu einem Bewohner durch einen Automatismus stand nicht im Verhältnis Aufwand/Nutzen.

Nun ist es aber so, dass mindestens mal ich (aber auch supernova1963) Potential in Deinem nmap-Modul erkannt haben. Offenbar Potenzial, welches Du selbst wegen Deiner 6 Geräte und Deiner ursprünglichen Intension nicht siehst.

Schau mal bitte mich an:
Ich habe gerade den RPi Zero W entdeckt, den gibt es aktuell für 11 Euro plus Versand. Das ist also ein vollwertiger Server und schon Wlan an Bord. Das ist billiger als jeder Sensor. Ok, wir brauchen noch USB-Strom und SD-Card- Aber dann haben wir zig Server im Wlan. Das schreit nach Automatisierung,  nach Überwachung: Wie geht es denen denn? Gibts die noch? Haben die Wehwehchen?

Dein nmap-Modul ist da der geniale erste Schritt: Das fängt alles ein, was nicht bei drei auf dem Baum ist. Und (leider) sehr rudimentäre Detailinformationen gibt es kostenlos dazu. Das ist schon mal sehr schön für ein künftiges Hausnetz.

Nun muss noch mehr an Infos rum, es werden ja viele kleine Server: CPU-Temperatur, Platte noch was frei, Update notwendig? Klar wird das ohne die Server, die bezogen auf FHEM-Modul nmap Clients sind nicht gehen. Aber das ist eine andere Sache, das kommt viel später.

Die Idee von supernova1963 ist nicht dumm: Jedes Gerät mit IP-Adresse muss ein FHEM-Device werden. Ein Device mit irgendwelchen zwei Readings und irgendwelchen zwei Attributen erstmal. Als erster Schritt.

Andere Module können offensichtlich neue Devices anlegen. Ich habe mal (etwas Perl kann ich) Dein Modul überflogen. Und Module, die Devices anlegen. Mit dem Ergebnis, dass ich dachte: Ok, so viel Perl kann ich nun wieder nicht.

Also möchte ich Dich bitten, das testweise zu bauen.

Ja, der Primärschlüssel ist problematisch: MAC kann es nicht sein, weil die MAC über mehrere Subnetze nicht verfügbar ist.

@supernova1963 @igami

[igami]

Ich habe noch nicht ganz verstanden was ich nun Einbauen soll. Ein Autocreate, damit jedes gefundene Gerät ein eigenes Device wird?
Das lässt sich über ein Notify lösen.

[curt]

Ich wusste nicht, dass das über "notify" möglich ist. Offen gesagt habe ich gar keine Erfahrung mit "notify". Und das Nachlesen hat mich auch nicht schlauer gemacht.

In meiner fhem.cfg finde ich ein notify

Code: [Auswählen]

define initialUsbCheck notify global:INITIALIZED usb createDas könnte in diese Richtung gehen - ich weiß aber auch das nicht.

Ok, ich versuche zu erklären:
Es gibt doch in nmap das Reading _alias. Das gibt es genau dann, wenn ich einer IP über eine Liste sage, wie deren Alias zu lauten hat.

Nun stelle ich mir vor, dass beim erstmaligen Auftreten (und nur dann) eines neuen *_alias genau dafür ein Device angelegt wird. Diesem müsste mindestens _IP (besser natürlich zudem auch _alias) mitgegeben werden.

Ich möchte Dich darum bitten, mir (kurz) zu erklären,  wie ich das anstelle.

(Vielleicht geht die Idee von @supernova1963 völlig fehl, aber unabhängig davon habe ich dann wenigstens was gelernt.)

[igami]

zu notify:

Führt eine oder mehrere Anweisungen aus, wenn ein Event generiert wurde, was dem <Suchmuster> (Gerätename oder Gerätename:Event) entspricht.

Nmap bietet dafür:

Wird ein neues Gerät erkannt wird ein Event "<name> new host: <hostname> (<IPv4>)" erzeugt.

Also braucht man ein notify welches vereinfacht dargestellt so aussieht:

Code: [Auswählen]

define new_host_notify notify Nmap:new.host:..+ {<perl um Device Namen festzulegen und IP und alias zu ermitteln>; fhem("define ...");}


[supernova1963]

Super, dass Event "<name> new host: <hostname> (<IPv4>)" habe ich bisher wohl übersehen.

Wäre es nicht sinnvoller an Stelle des "... fhem("define ...");}" ein "... fhem("defmod ...");}" zu verwenden damit, wenn vorhanden, kein Fehler entsteht?

Jetzt stellt sich nur noch die Frage auf Basis welchen Moduls das device erstellt werden soll. Zum Testen reicht sicher ein Dummy, dem man "händisch" die gewünschten readings beibringt.

Im Idealfall gäbe es eine Art "nmapClient Modul", das z.B. über eine nmap Port-Abfrage, ssh oder Vergleichbarem versucht Dienste zu erkennen (http, https, ssh, telnet, ftp, sql-Server, mqtt, ha-bridge, fhem-Server, ...) und diese z.B. als Link in einem reading anbietet.
Wenn möglich, könnte je nach erkanntem Betriebssystem, ein Systemmonitor-Device mit einer geeigneten Verknüpfung z.B. über die Namensgebung angelegt. Auch das von curt gewünschte Update reading könnte in das Modul integriert werden.
Für fhem-Einsteiger wäre vielleicht sogar ein optionales autoCreate der gefundenen Systeme denkbar (HMCCU, VCCU, MQTT, ESPEasy, Netatmo, ...)
...

Die Wunschliste erhebt keinen Anspruch auf Vollständigkeit! 
   
Wie ich feststellen mußte, fehlen mir das notwendige Nmap-/Perl-/Fhem-Wissen.

Ein schönes, sonniges Wochenende,

Gernot

[curt]

Super, dass Event "<name> new host: <hostname> (<IPv4>)" habe ich bisher wohl übersehen.
Wäre es nicht sinnvoller an Stelle des "... fhem("define ...");}" ein "... fhem("defmod ...");}" zu verwenden damit, wenn vorhanden, kein Fehler entsteht?

Bezogen auf die Aufgabenstellung "anhand des *_alias" vermutlich nicht. Denn das Device soll nur einmal erstellt werden - nicht immerzu neu, wenn das physikalische Gerät mal abwesend war.

Jetzt stellt sich nur noch die Frage auf Basis welchen Moduls das device erstellt werden soll. Zum Testen reicht sicher ein Dummy, dem man "händisch" die gewünschten readings beibringt.

Du bist mir immer zu schnell. Mir würde jetzt erstmal reichen, wenn jemand (Du?) mal den Befehl richtig ausformuliert - also so, dass anschließend bei mir neue Devices entstehen.

Im Idealfall gäbe es eine Art "nmapClient Modul", das z.B. über eine nmap Port-Abfrage, ssh oder Vergleichbarem versucht Dienste zu erkennen (http, https, ssh, telnet, ftp, sql-Server, mqtt, ha-bridge, fhem-Server, ...) und diese z.B. als Link in einem reading anbietet.

Du bist aus meiner Sicht viel-viel zu schnell. Zuerst benötigen wir wie gesagt das Obige. Dann atmen wir mal tief durch. Dann denken wir konzeptionell weiter. Nmap kann das im Ergebnis sein, muss es aber nicht. Da fiele mir noch anderes ein.
   

Wie ich feststellen mußte, fehlen mir das notwendige Nmap-/Perl-/Fhem-Wissen.

Nmap könnte ich. Perl langt für den Hausgebrach, derzeit aber nicht für neue Module. Fhem ... ich übe ...

Wer gibt mir nun den korrekten Code nach der Andeutung von @igami ?

[igami]

Nmap könnte ich. Perl langt für den Hausgebrach, derzeit aber nicht für neue Module. Fhem ... ich übe ...

Wer gibt mir nun den korrekten Code nach der Andeutung von @igami ?

Wäre das dann nicht eine gute Einstiegsaufgabe für dich? Du hast ja selbst Vorstellungen was du erreichen möchtest und musst nun "nur" noch das notify dazu schreiben.

[supernova1963]

Es fehlt doch nur noch der Perl Code!

Ungetestet (unbedingt vorher prüfen!!!), würde ich es laienhaft so versuchen:

Code: [Auswählen]

define new_host_notify notify Nmap:new.host:..+ {
my $newDeviceName = "";
my $ip = "";
my $regex = qr/host: (.*)? \(/p;
if ( $EVENT =~ /$regex/g )
  {
  $ip = $1;
  }
$regex = qr/\./p;
my $subst = '_';
$newDeviceName = $ip =~ s/$regex/$subst/rg;
fhem("defmod $newDeviceName dummy");
fhem("setreading $newDeviceName IP $ip");
fhem("set $newDeviceName ".ReadingsVal("Netzwerk",$ip.'_state','unknown'));
#...
}

Edit: ")" vergessen !

Aber das kannst du sicher besser und ausbauen. Wenn du es umgesetzt hast, poste doch mal deine rawDefinition des notify's.

Gernot