Nmap readingsGroup

Begonnen von igami, 03 April 2017, 17:07:36

Vorheriges Thema - Nächstes Thema

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:

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!
RPI 4 - Jeelink HomeMatic Z-Wave

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?
RPI 4 - Jeelink HomeMatic Z-Wave

supernova1963

#47
Zitat von: curt am 14 März 2018, 01:52:51
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.

Zitat von: supernova1963 am 14 März 2018, 06:55:40
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.

Zitat von: supernova1963 am 14 März 2018, 06:55:40
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.

Zitat von: supernova1963 am 14 März 2018, 06:55:40
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.
RPI 4 - Jeelink HomeMatic Z-Wave

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 ::)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

curt

Zitat von: igami am 14 März 2018, 20:30:08
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?

Zitat von: igami am 14 März 2018, 20:30:08
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.)
RPI 4 - Jeelink HomeMatic Z-Wave

igami

Zitat von: curt am 14 März 2018, 20:54:52
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

Zitat von: curt am 14 März 2018, 20:54:52
<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.

Zitat von: curt am 14 März 2018, 20:54:52
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.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

curt

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

Zitat von: igami am 15 März 2018, 06:00:21
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
RPI 4 - Jeelink HomeMatic Z-Wave

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.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

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
define initialUsbCheck notify global:INITIALIZED usb create
Das 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.)


RPI 4 - Jeelink HomeMatic Z-Wave

igami

zu notify:
Zitat
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:
Zitat
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:

define new_host_notify notify Nmap:new.host:..+ {<perl um Device Namen festzulegen und IP und alias zu ermitteln>; fhem("define ...");}
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

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

Zitat von: supernova1963 am 18 März 2018, 14:17:17
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.

Zitat von: supernova1963 am 18 März 2018, 14:17:17
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.

Zitat von: supernova1963 am 18 März 2018, 14:17:17
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.
   
Zitat von: supernova1963 am 18 März 2018, 14:17:17
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 ?
RPI 4 - Jeelink HomeMatic Z-Wave

igami

Zitat von: curt am 18 März 2018, 22:36:00
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.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

supernova1963

#59
Es fehlt doch nur noch der Perl Code!

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

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