Netmon strukturieren Features * Stadtkarte mit Routern * Position * Router ID * WLAN MAC? * könnte es mehrere geben * Und jede davon wäre geeignet, oder? Man könnte einfach die niedrigste nehmen (als Zahl interpretiert) * Wieso nicht einfach die MAC, die auf dem Gerät drauf steht? * IPv6 Adresse? * dito * Betreiber * Betreiber ID * Status * Online * Traffic * Verbindungen * WLAN * Internet * Liste der Router * Liste der Verbindungen * Gilt das nur auf BATMAN oder auch auf fastd Ebene? * Um es einfach zu halten würde BATMAN reichen, die fastd Verbindungen tauchen dort ja auch auf * Nur so lange wir die reine BATMAN Infrastruktur haben, aber das ist eine andere Diskussion * Länge * "Uptime" * Qualität * Traffic * Statusseite eines Routers * Viel Info * Tools? * Route zu anderem Router (auf Karte) zeigen? * Konfigurationsseite zur Administation eines Routers * <- das sollte nicht der Netmon machen. Wer/was macht das denn? Kommt das nicht ins Netmon repo? "Netconf" ^^ * Bei mir heißt das Ding configuration. Das Teil kann im selben Repo sein, muss aber nicht. Es gibt von uns quasi nur eine Schnittstelle. Das ist SSH plus eventuell die admin-Skripte, die du erwähnt hast. Was dann andere damit machen ist erstmal offen. * Passwort setzen * Standort setzen * Firmware update/zurücksetzen * Region ändern? * Router löschen ?? * a) Es wäre nett, wenn man seinen Router einfach und sicher aus der Ferne vom Netz nehmen könnte falls er spinnt * b) Router bei Netmon/ abmelden * Liste der Clients * Traffic * Broadcast * Sperren Option * Dienste auf Router installieren/aktivieren * DHCP konfigurieren und starten da würde ich eher ganz weit von weg bleiben.. Knoten, die ins Netz Routen dürfen gern eine eigene Firmware haben. * Okay, aber warum? * Naja, ich schrieb das in dem Kontext, unserer bisheringen Netze. Ein DHCP-Knoten ist gleichzeitig ein Internet-Gateway. Da ergibt es im Moment wenig Sinn das auf einem normalen Mesh-Knoten zu konfigurieren. * Wenn wir natürlich das Netz komplett umstrukturieren und z.B. eine Art Hirarchie einbauen, dann könnte das anders sein. Aber das ist wieder eine andere Diskussion. * Bandbreitenbegrenzung für Internetmesh setzen * Fastdnodes/Verbindungen * Anzeigen * Manuell hinzufügen? * IP-Adressen Verwaltung * Liste der vergebenen Bereichen * Betreiber * Zugeordneter Router/DHCP * Status * DNS? Kommunikation * Eine vereinheitlichte Methode für alle Datentransfers zwischen Router und Netmon wäre wünschenswert * Richtung * Router -> Netmon (lesend) <- würde ich am lieben haben wollen * Warum? Wir sollten eine Liste mit Vor und Nachteilen machen * Netmon -> Router (schreibend) * Fälle * Update der Statusinformation des Routers * Speichern der Information auf dem Router * Ausführen einer Aktion auf dem Router <- das soll bitte nicht der Netmon machen * Okay, ab jetzt nenne ich es "Netconf" ^^ Sicherheit * Netmon/Ein beliebiges Programm sollte idealerweise nur vorher klar definierte Operationen durchführen können * Diese Operationen sollten lokal (unter Kontrolle des Betreibers) auf dem Router vor der Ausführung überprüft werden * Dadurch würde jedes Speichern von Information zu einer Aktion * Verstehe ich nur halb. Ich hatte das beim configurator so gedacht, dass dieser Shell-Skripte beinhaltet, welche er dann abspulen kann. Diese werden dem Nutzer vor der Ausführung angezeigt. So kann er diese ggf prüfen. * Ich hatte das so gedacht, dass der configurator auf dem Router selbst die letzte Bastion gegen Fehlkonfiguration seitens Netmon (zB hostnamebug) ist. Der sollte einfach alles was nicht passt nicht ausführen. (von der Implementierung her siehe meine Mail "Patchday" Patch 0002) * Aha.. Ich hatte es so gedacht: Auf dem Router laufen von mir aus die Adminskripte, (ich glaub admin.sh in dem Patch). Der configuratior (ich nenne ihn configuration module, du nennst ihn glaube ich Netconf) ist die Webseite, die diese Skript (über ssh) bedient. Wenn man das klar vom Netmon trennt wir das aufsetzen und aktualisieren einfacher. Ausserdem ist das Konfigurieren kritisch, da man dort Zugriff auf seinen Router gewähren muss, daher vertraut man vielleicht dem Netmon-Betreiber nicht und will sein eigenes "Netconf". Man könnte das Netconf sogar als Windows-GUI Implementieren.. oder sonstwas.. * Die Rechte sollte der Betreiber des Router gewähren (und entziehen) können * Lesezugriff (Das wäre quasi der Fall, nachdem ein Capture Modul als Ziel gewählt wurde) * Was dann nur als opt-out realisierbar wäre, denn der opt-in weg exstiert nicht (nur übers terminal, was für viele eine zu große hürde für eine standardoperation ist) * Wie gesagt, das Termin ist nicht nötig, dazu haben wir "Netconf". * Opt-in? * Opt-out? * Schreibzugriff (nur über ssh, daher hat der Passwort inhaber volle Kontrolle) * Opt-in * Eine Möglichkeit wäre, den Router nach einem bestimmten Schema in den Registrierungsmodus zu versetzen * zB nach dem ersten Start, durch drücken eines Knopfes, ... * In diesem wäre es dann möglich sshkeys bei vordefinierten Usern zu hinterlegen * Es könnte die Liste der Nutzer erweitert werden um * readevent * writeevent * Rootzugriff würde so nie benötigt Zentralität * Zentrale Punkte in Netmon * zB Eventreceiver URL * Müsste auf jedem Router gespeichert sein (ist bereits) * Ja, aber optimal ist das nicht. Vor allem wenn es eine Liste mit mehreren gibt (mehrere Regionen) dann muss die aktuell gehalten werden * Also doch die Region (mit allen Daten) über "Netconf" setzen. * Können ausfallen/angegriffen werden * Datenbank * Verteilte Datenbank denkbar * Crawlerinterface * Mehrere Interfaces (besser crawler) benötigt für getrennte submeshes Module * Datenbank * Struktur * Events * IN * OUT * ERROR/OLD * Routerlist * Data * Userlist * Data * Könnte komplett von Netmon getrennt werden * Die Kommunikation von Netmin mit den Routern funktioniert dann NIE direkt sondern führt immer über die Datenbank * (Events in diesem Sinne sind wie E-Mails, und einem Schlüssel/Index/Counter zur Erkennung von Dubletten) * IN Events (Router->DB) * Könnten durch ein Skript auf dem Router erzeugt und in einen speziellen Ordner gelegt werden * zB ua durch Cronjob * Werden durch ein Skript auf dem Server (Worker/Capture) von den Routern geholt und sofort oder in Intervallen verarbeitet * zB Hostnameänderung, Statusupdate, Fehlermeldungen, Regionsanfrage, Betriebsbericht, Fastdpeeranfrage * OUT Events (DB->Router) * Würden von Netmon in der DB gespeichert * Werden von einer (von potentiell mehreren) zuständigen Worker/Capture Instanzen auf dem Server auf den Router in einen speziellen Ordner verschoben * Der Router entscheidet "selbst" was er mit diesen Events macht * Ausführen/Antworten/Löschen * Der Ansatz ist schon ganz gut. Jedoch würde ich das DB->Router komplett durch das configuration-Modul machen lassen. Hier kein Weg über die DB, dise wird dann durch den Router wieder aktualisiert. * Ich hab die Tage noch darüber nachgedacht und ein bisschen experimentiert: * OpenWRT ist nicht für mehrere User (multi-user) ausgelegt. Ich sage nicht, dass es nicht geht, aber es ist nicht so einfach wie auf einem normalen Linuxsystem * gut zu wissen, hat aber hiermit eigentlich nichts zu tun, oder? * Für Netmon brauchen wir nur die eine RIchtung (Router->DB) , "Netconf" (X->Router) können wir dann an anderer Stelle besprechen * Ja, stimmt. Kommt mir sehr entgegen. * Netmon * Routerkarte * Lesender Datenbankzugriff * Routerliste * Lesender Datenbankzugriff * IP-Bereichsliste * Lesender Datenbankzugriff * "Events" (Interessante Änderungen am Netzzustand, nicht die Events aus dem DB Modul) * Lesender Datenbankzugriff * Routerstatus * Lesender Datenbankzugriff * Routeradministationsseite * Lesender Datenbankzugriff * Schreibender Datenbankzugriff * Routerregistrierungsseite * Schreibender Datenbankzugriff