Hallo, Gast
Du musst dich registrieren bevor du auf unserer Seite Beiträge schreiben kannst.

Benutzername
  

Passwort
  





Durchsuche Foren

(Erweiterte Suche)

Aktive Themen
Registrierung
Letzter Beitrag: DM4AB
14-01-2024, 19:24
Mobile Stromversorgung - ...
Letzter Beitrag: DK2FK
29-07-2023, 09:28
Draußenfunken Ende Juni 2...
Letzter Beitrag: DM4AB
29-06-2023, 22:58
Fortschritte in der Klein...
Letzter Beitrag: DK2FK
05-06-2023, 16:45
Draußenfunken am 21. Mai ...
Letzter Beitrag: DH1DH
01-06-2023, 12:48
Internet-in-a-Box
Letzter Beitrag: DK2FK
29-05-2023, 14:16
Bergfunken AREDN und Hamn...
Letzter Beitrag: DM4AB
14-05-2023, 17:26
Ubiquity Flex Mini nicht ...
Letzter Beitrag: DC3AX
10-05-2023, 10:26
AREDN-in-a-box
Letzter Beitrag: DC3AX
09-05-2023, 23:55
Energieeffiziente x86_64 ...
Letzter Beitrag: DC3AX
09-05-2023, 23:13

Foren-Statistiken
» Mitglieder: 0,   » Neuestes Mitglied: Tobzer,   » Foren-Themen: 20,   » Foren-Beiträge: 26,  
Komplettstatistiken

  Verbindung Hochstäß Bussen
Geschrieben von: dominik - 23-04-2023, 20:57 - Forum: HAMNET - Keine Antworten

Da es heute schönes Wetter war konnte ich erfolgreich den Hamnet Userzugang auf 2,4GHz vom Hochstäß aus testen
Lokation war die Bank neberm Feldweg
https://www.openstreetmap.org/#map=18/48...2&layers=N



Angehängte Dateien Thumbnail(s)
   
Drucke diesen Beitrag

  Treffen am Dienstag, 18. April 2023, ab 19:30 Uhr im Freiraum
Geschrieben von: DM4AB - 17-04-2023, 09:38 - Forum: Ankündigungen - Keine Antworten

Hallo zusammen.

Höchste Zeit, dass wir uns mal wieder treffen und nicht nur miteinander telefonieren. Beim letzten Mal haben wir als Schwerpunkt die konzeptionellen Anforderungen an einen Funk-Leuchtturm wie z.B. das Maritim diskutiert.
Inzwischen klappt das mit dem MeshChat ganz vernünftig, IP-telefonieren auch, und unsere funkende Vernetzung sollte auch nicht das große Problem sein. Ich würde folgende Agenda vorschlagen:

  1. Wie sieht unser erstes Übungs-Szenario aus - was sehen wir als Problemstellung, wen wollen wir womit vernetzen?
  2. Welche Dienste bieten wir dabei an?
    Wer und wie dokumentieren wir Aufgabenstellung, Verlauf, Ergebnis und Follow-up?
  3. Was wollen wir noch an Diensten und Angeboten entwickeln?
    (lokale AP's, lokales Mesh, Informations-Leuchttürme, lokale Terminals/Laptops, ...)
  4. Was brauchen wir noch für ein Notfunk-Szenario?
    (tragbare Repeater, Funkgeräte, PMR, ...?)
  5. Wer hat Interesse / kann sich um Notfallpläne kümmern (ich meine, es ist schön, wenn wir die Technik im Griff haben, aber wie organisieren wir uns in einem Notfall? Alarmierungskette, Kommunikation, ...)

Viele Punkte für ein hoffentlich interessantes Treffen!

73 de Andreas.

Drucke diesen Beitrag

  Verteilte Dateien mit Syncthing
Geschrieben von: DM4AB - 15-04-2023, 13:02 - Forum: Software - Keine Antworten

Ich habe heute Vormittag Syncthing ausprobiert und bin völlig begeistert.

Die Software ist Open Source, für alle möglichen CPU Architekturen und Betriebssysteme kompiliert verfügbar (wer hat bitte noch Solaris?) und arbeitet ganz hervorragend. Anbei ein Screenshot, der drei verschiedene verbundene Rechner zeigt:

       

Verbunden ist sind ein Windows und ein Linux Laptop im gleichen WLAN, und ein Tablet mittels iPhone Hotspot via LTE (Windows, Linux, Android). Die drei kennen sich gegenseitig und aktualisieren Dateien in einem Verzeichnis im Ring herum. Sehr schön nachvollziehbar, mit Log-Files, vermutlich gibt es auch irgendwo Schreib- und Löschschutz, den ich aber noch nicht gefunden habe. Toll ist, dass die Teilnehmer einfach bemerken, wenn sie offline sind und wieder online werden, dann synchronisieren sie einfach los. Auch toll, dass man die Bandbreite beim Synchronisieren einstellen kann (für unsere Anwendung vermutlich sehr brauchbar um zu vermeiden, dass fette Datenbursts das Netz lahmlegen).

Ob das ganze als Insellösung gut funktioniert (also ganz ohne Internet) habe ich noch nicht ausprobiert. Ich habe da etwas über "discovery server" gelesen, und das könnte natürlich ein Problem sein. Aber die Erstprüfung dieser Software scheint absolut Klasse

73 de Andreas.

Drucke diesen Beitrag

  Solarbetriebene Website
Geschrieben von: DK2FK - 12-04-2023, 21:37 - Forum: Nützliches - Keine Antworten

Es gibt (mindestens) eine solarbetriebene Website: https://solar.lowtechmagazine.com - die dann z.B. bei schlechtem Wetter auch offline geht.

Der verlinkte Artikel beschreibt sehr schön die Hintergründe und Herausforderungen beim Design der Website. Mit den entsprechenden Optimierungen kann auch mit wenig Energie und alter Hardware noch einiges geschafft werden - sofern die angebotenen Dienste entsprechend ausgewählt oder konfiguriert werden.

Bei AREDN ist wahrscheinlich die verfügbare Bandbreite der limitierende Faktor. Der Artikel zeigt, dass vor allem durch die Reduktion der übertragenen Datenmenge die Last kleingehalten werden konnte. Vielleicht kommen wir dann auch mit kleineren Geräten aus.

Generell finde ich auch den Rest der Website interessant. Es lohnt sich, da auch mal durch die anderen Artikel zu klicken.

Drucke diesen Beitrag

  Energieeffiziente x86_64 Hardware für AREDN Dienste
Geschrieben von: DK2FK - 11-04-2023, 20:37 - Forum: Hardware - Antworten (1)

Um Dienste im AREDN/Hamnet anzubieten wird allgemein empfohlen statt ARM hardware (Raspberry PI, Odroid, etc.) auf x86_64 zu setzen, da man sich damit einige Probleme spart. Diese sind: 

  • Kein BIOS: man braucht dedizierte Images für das jeweilige Board 
  • Keine/kaum Linux Mainline Kernel Unterstützung: Kernel müssen jeweils spezifisch für das Board kompiliert werden - und sind häufig entsprechend alt 
  • Software Support: Einige Programme oder Funktionen sind nicht verfügbar oder müssen jeweils kompliiert werden 

Weiterhin ist  die ARM-Welt auch etwas zersplittert: viele Geräte basieren noch auf der armv7 Architektur, die nur 32 bit unterstützt. Seit einiger Zeit gibt es dann auch arm64, was z.T. jetzt besser unterstützt wird, aber auch noch o.g. Probleme aufweist. 

Um jetzt geschickt Dienste anbieten und auch auf weiteren Knoten installieren zu können empfielt es sich, Docker oder Podman zu nutzen. Der Vorteil ist, dass die Container unabhängig voneinander sind und damit unabhängig von den installierten Bibliotheken auf dem Host-Betriebssystem. Damit lassen sich Dienste nach Bedarf/Komponentenweise installieren statt fest im Image eingebacken zu sein - wie es etwa der HamPi macht. Weiterhin lassen sich diese Container auch recht problemlos auf anderen Betriebssystemen installieren, solange Docker oder Podman installiert ist. Die einzige Bedingung ist, dass der Container für die entsprechende Architektur verfügbar ist. Um das auch offline zu unterstützen kann lokal eine Registry installiert werden. Da allerdings hier die Container Architektur-spezifisch sind, muss für jede Architectur - sofern verfügbar - ein eigenes Image heruntergeladen und vorgehalten werden. 

Meine bisherigen Recherchen für x86_64 Geräte haben folgende Möglichkeiten ergeben: 
  • Alter Laptop/Chromebook mit Intel Prozessor
  • x86_64 Single-board Computer (SBCs)
  • Thin clients: SFF/uSFF PCs 
  • Mini PCs

Dazu mehr im folgenden:

Alter Laptop/Chromebook

Alte Laptops bieten den Vorteil, dass sie von sich aus schon relativ gut auf Energiesparen getrimmt sind und alles mitbringen, was man unterwegs brauchen kann:
  • Akku (sofern funktionsfähig) als integrierte USV
  • Tastatur + Bildschirm für eventuelle Konfigurationsänderungen
  • Ausreichend Arbeitsspeicher  und CPU-Leistung für verschiedeneste Dienste
  • Gutes Energiemanagement
Allerdings erkauft man sich damit auch einige Nachteile:
  • Größer/schwerer als vergleichbare SBCs
  • Sollte je nach Anwendungsfall (Server/Client) umkonfiguriert werden (i.e. Desktop-Umgebung an/abschalten um genügend Arbeitsspeicher zu haben)
Generell sollte bei Laptops darauf geachtet werden, dass sie einen neueren Prozessor haben (Intel: ab 6./7. Gen, AMD: ?). Am sparsamsten sind Intel Atom, Celeron, oder i3 Prozessoren, allderings sind auch moderne i5 oder i7 unter niedriger Last relativ sparsam.

Die Stromversorgung kann meist mit einem einfachen 19V Adapter bewerkstelligt werden. Allerdings ist das ein weiterer Adapter den man irgendwo unterbringen muss. Achtung: manche Laptops erfordern für die Stromversorgung auch Orginaladapter vom Hersteller (z.B. Dell). Modernere Laptops können auch per USB-C PD (power delivery) versorgt werden, was im mobilen Bereich auch eine interessante Option sein kann.

Ein Sonderfall sind Chromebooks. Diese haben einen extrem niedrigen Energieverbrauch, sind aber ziemlich zugenagelt, da Google kein Interesse daran hat, dass diese ohne Web-Zugriff auf Google-Dienste betrieben werden. Hierzu gibt es verschiedene Anleitungen online, die ich aber mangels Chromebook nicht bewerten kann.

!! Generell ist hier darauf zu achten, dass ein x86_64 Prozessor und kein ARM verbaut ist.

x86_64 Single-board Computer (SBC)

Ein entsprechendes Board zu finden ist leider aktuell nicht so leicht. Trotzdem habe ich zwei interessante Projekte gefunden:
LattePanda 3 Delta
- Zimaboard

Generell ist bei diesen Boards häufig das Problem, ausreichend Speicher/Festplattenplatz anzubinden. Mit Glück ist neben USB ports ein SATA, mSATA oder NVMe/PCIe Steckplatz vorhanden. Damit schließt sich häufig Redundanz aus, allerdings sind moderne SSDs - auch durch die großen Größen - relativ ausfallsicher, und mittlerweile auch erschwinglich.

Bleibt das Problem der Montage: Diese SBCs sind generell nakte PCBs und folgen keinem Größenstandard. Entsprechend gibt es keine Standardgehäuse und man muss sich selbst Gedanken machen, wie man die Komponenten unterbringt.

Ansonsten sind diese SBCs vergleichbar mit Laptops. Sie haben vergleichbare CPU-Leistung, Arbeitsspeicher und Schnittstellen, und Stromverbrauch. Die Versorgungsspannung ist üblicherweise 12V oder 19V und sollte ohne proprietäre Netzteile auskommen.

Thinclients/(u)SFF PCs

Thin clients sind häufig günstig über Gebrauchtwarenbörsen aus alten Bürobeständen zu erstehen. Diese sind von Leistungsfähigkeit und Leistungsaufnahme mit Laptops vergleichbar. Mit einem Celeron/i3, ausreichend RAM und einem aufrüstbaren Massenspeicher sind diese eine attraktive Lösung für mobile und Serveranwendungen, allerdings ist hier wie bei Laptops die Stromversorgung jeweils zu prüfen.

Bei der Auswahl sollte weiterhin auf einen sparsame Prozessor zu achten, da diese je nach Ausstattung auch recht leistungshungrig werden können.

Mini-PCs

Mini PCs wie Intel NUC oder ZBOXen sind aus mehreren Aspekten interessant:
- Modelle mit mehreren Netzwerkschnittstellen verfügbar
- Hohe Leistungsfähigkeit wenn gewünscht
- Passiv gekühlte Varianten verfügbar
- z.T. mehr Platz für Festplatten/SSDs (i.e. PCIe/NVMe + 2.5" SATA)
- Neue Hardware verfügbar
Nachteile sind der oft hohe Preis (je nach Ausstattung >1000€).

Die Leistungsaufnahme skaliert offenbar recht gut mit den verbauten Komponenten. Entsprechend ist hier - wie sonst auch - das beste Preis-Leistungsverhältnis für die geplante Nutzung zu finden.

Etwas außerhalb der Mini-PC Ecke sind weiterhin Mini-ITX-basierte Systeme anzusiedeln. Diese sind generell nicht so kompakt, nutzen aber Standard-Komponenten und sind damit wartungsfreundlicher und einfacher reparier/- und upgradebar. Mini-ITX boards sind in allen Leistungsklassen verfügbar. Gehäuse gibt es mit der gewünschten Anzahl 2.5" Einschübe, zum Teil sogar passiv gekühlt. Für die Stromversorgung gibt es 12V Auto-Netzteile, die auch robust gegenüber Über- und Unterspannung sind - und damit attraktiv für die mobile Nutzung. Der größte Nachteil ist allerdings die oft weniger kompakte Bauweise.

Zusammenfassung

Generell gibt es eine ganze Reihe interessanter Alternativen. Die Auswahl hängt natürlich auch von der geplanten Verwendung ab. Wo und wie sollen die Knoten betrieben werden? Muss der Knoten tragbar sein? Wie lange soll/muss der Knoten online sein? Welche Möglichkeit zur Stromversorgung besteht?

Die dem Ganzen zugrunde liegende Frage ist: Welche Dienste wir anbieten? Wie gehen wir mit Knoten/Link-Ausfällen um? Welcher Dienst hilft wem, wann, und wo?  ..und zu guter letzt: was ist das Budget? Das sollte in einem separaten Thread diskutiert werden.

Aktuell befinde ich mich noch in der Lern-/Experimentierphase, möchte aber wenn möglich etwas zukunftsfähiges bauen, daher der Fokus auf x86_64. Allerdings kann ich die Leistungsanforderungen noch nicht genauer abschätzen. Entsprechend bin ich hin- und hergerissen zwischen etwas Billigem, was dann eventuell langfristig nicht sinnvoll ist - oder zu viel Geld ausgeben, was dann am Ende doch überdimensioniert ist.

Was meint ihr? Habt ihr noch alte Hardware rumliegen, die ihr für AREDN herrichten wollt? Gibt es noch andere Optionen, die ich hier übesehen habe?

Drucke diesen Beitrag

  AREDN-in-a-box
Geschrieben von: DK2FK - 10-04-2023, 11:42 - Forum: Hardware - Antworten (3)

Gestern habe ich mich - um das Kabelgewirr etwas zu reduzieren - darangemacht die verschiedenen Komponenten in eine Box einzubauen. Das sieht dann so aus:        

Leider musste ich dann feststellen, dass der Akku den Geist aufgegeben hat. Bin mir noch nicht ganz schlüssig ob es jetzt Blei oder LiFePo4 (für die gleiche Kapazität aber 5-fachen Preis) werden soll.

Drucke diesen Beitrag

Sad Basteln mit Linux PBXen
Geschrieben von: DM4AB - 09-04-2023, 23:40 - Forum: Software - Antworten (3)

Hallo zusammen.

Ich habe die letzten Tage damit zugebracht, mich mit Asterisk und Verwandten zu beschäftigen. Dieter (DH1DH) hatte ja schon beiläufig im Gespräch geäußert, das das eine elende Popelei sein und nur etwas für ganz hartgesottene und ausdauernde Nerds sei. Na, was soll ich sagen, er hat Recht. Mit der Notfunk PBX habe ich mich auch beschäftigt, aber eins nach dem anderen.

Wenn man "open source" und "ip phone" sagt, stößt man zuerst auf Asterisk. Es gibt auch Alternativen wie freeswitch und andere, aber von allen möglichen Foren-Beiträgen muss man schlussfolgern, dass man sich entweder mit Asterisk oder freeswitch beschäftigen will. freeswitch steckt auch in den Big Blue Button Servern drin, die wir häufig  verwenden.

Ich habe mich also auf einem nicht mehr ganz aktuellen Laptop mit Asterisk beschäftigt. Nachdem das lief (?) und ich nicht verstanden habe, wie ich jetzt Profile für das von Hanspeter (DG6SK) ausgeliehene Telefon erstelle, kam ich drauf, doch auch noch FreePBX zu kompilieren und zu installieren, das eine nette Verwaltungsoberfläche versprach. Nachdem ich mit dem Laptop fertig war und FreePBX auch noch drauf lief konnte ich keine vernünftige Applikation dazu finden , bis mir klar wurde, dass ich das mit dem installierten Web-Server betrachten muss.Na gut, aber der Verwaltungsoberfläche fehlten jede Menge Menüs und alles sah auch ganz anders aus, und ... ich kam nicht gut zurecht.

Auch nervig war, dass hinter FreePBX eine Firma steckt ("Sangoma"), die ständig alle möglichen Sachen zusätzlich verkaufen wollen. Echt nervig, pfui! Also dachte ich mir, ich versuche erst mal etwas anderes.

Also her mit der Notfunk PBX vom DARC. Erstmal auf dem Laptop Asterisk deaktivieren, dann Docker installieren, dann jede Menge Gigabytes herunterladen, währenddessen Dokumentation studieren. Da gibt es einen Extra-Abschnitt für AREDN, und da steht:
   
Ja so ein Mist, warum denn das? Na ja, bei ein bisschen darüber Nachdenken könnten vielleicht alle Telefone im AREDN Netz ein Problem damit haben, eine vernünftige IP-Adresse zu bekommen, mit welcher das Telefon erreichbar wird. Und zudem könnte es bedeuten, dass Telefon und Knoten eine enge Partnerschaft eingehen müssen, denn die IP vom Telefon muss natürlich zum Adressbereich des Knoten passen, ... alles ziemlich wenig flexibel.

Und nachdem ich schon einmal beim Nachdenken war wurde mir dann auch noch klar, dass wir im Ernstfall vermutlich nie die Verbindung zu einer DARC Notfunk PBX haben werden, und den Notfunk PBX Vortrag hatte ich so in Erinnerung, dass es nur genau dann auch richtig funktioniert. Wenn ich das falsch mitgenommen habe, sagt doch mal Bescheid als Kommentar zum Thread :-)

Damit war ich dann wieder zurück bei meinen Asterisk- und FreePBX Experimenten. Beim Lesen war mein Augenmerk auf eine FreePB Linux Distribution gefallen, was sich auch nett las. Vielleicht löst das meine Probleme im Konfigurieren einer stand-alone Instanz, dachte ich. Also zwei neue Partitionen auf der Platte des Laptops her gerichtet, die Distribution auf einen USB Stick heruntergeladen und die Installation gestartet. Zuerst war das recht langsam (ok, der Laptop ist nicht der schnellste), und ich wartete immer noch auf die Frage, welche Partition zum Installieren verwendet werden soll, und ... dann war ich ein wenig draußen.
Als ich zurück kam war die Installation fertig (=prima, aber wieso?), also Rechner neu gestartet, doch Hallo!, wo war mein grub Bootloader, das Linux und die Windows-Installation? Diese blöde Distro hat die ganze Platte her genommen, alle Partitionen gekillt und mit irgendwelchem Müll voll gespielt. So ein Ärger!

Na gut, sei's drum, vielleicht taugt das Ergebnis ja. Aber das Ergebnis taugte mir nicht. Alles, was interessant aussieht, darf zusätzlich gekauft werden. Diese Firma Sangoma ist ziemlich fragwürdig in ihrer Unterstützung von OpenSource, ziemlich nervig. Auch die FreePBX Software ist nervig. 
Angry

Und nach einer Stunde herumspielen bekam der Laptop eine neue Linux Installation.

Punkt, fertig damit. Vielleicht kommt später eine Fortsetzung.

Drucke diesen Beitrag

  MeshChat v2.7 keine Nachrichten trotz Synchronisation
Geschrieben von: DG6SK - 08-04-2023, 14:00 - Forum: Probleme - Keine Antworten

Hallo,
ich hatte immer wieder mal das Problem, dass der Chat an einem meiner Knoten leer war obwohl eine Synchronisation mit anderen Knoten stattgefunden hatte. Dort war der Chat auch mit Nachrichten gefüllt.
Ich vermute mal, dass ich die Ursache gefunden habe. Mein Knoten, dessen Chat leer war, hatte keine korrekte Uhrzeit, sondern startete mit Datum und Uhrzeit, die in der Firmware vorgegeben war. Man sah dies auch bei den Last Sync Einträgen im Chat, die lagen alle in der Vergangenheit, sprich bei mir irgendwann im Jahr 2022. Und da der Chat nicht in die Zukunft schauen kann, war er eben leer.
Sobald der Knoten übers Internet oder über seine Anbindung an andere Knoten das korrekte Datum und Uhrzeit hatte, waren nach der nächsten Synchronisation auch die Chat Nachrichten vorhanden.

Drucke diesen Beitrag

  Raspberry Pi in olsrd Routing mit integrieren
Geschrieben von: dominik - 08-04-2023, 12:56 - Forum: Experimente - Antworten (1)

Mich hat die Idee gereizt, über einen beliebigen DtD Link einfach einen Raspberry Pi anschließen zu können der sich selbständig im AREDN OLSR Netz meldet. Der Vorteil ist, dass eine Konfiguration am AREDN Knoten im Tab "Port Forwarding DHCP and Services" nicht notwendig ist und der Raspberry Pi im Mesh Status verfügbar ist
Vorhanden war ein bereis vor längerem als NTP Server konfigurierter Raspberry B+ mit Raspbian GNU/Linux 10 (buster) und GPS Modul.
Es fehlt noch eine IP Adrresse für das DtD Link Interface auf VLAN 2. ARDEN nutzt die Interface MAC Adresse dafür.

Die für das Interface verwendete IP Adresse wird wie folgt generiert:
AREDN verwendet in der Standardkonfiguration den kompletten Class A Adressblock mit dem 10.0.0.0/8 Netz.
Bei der Interface MAC Adresse sind die letzten drei Blöcke für einen Netzwerkkomponentenhersteller zur freien Vergabe reserviert. Diese letzten drei Blöcke werden ein zu eins verwendet. Idee ist wohl, dass die Adressen nicht zufällig identisch sind. Bei drei Herstellen auf denen die AREDN Software läuft ist wohl das Risiko der zufällig gleichen Adresse nicht so hoch auch wen ein Hersteller mehrere Vendor Nummern zugeteilt bekommen hat.
Die MAC Adresse wird üblicherweise in Hex geschrieben. IP Adressen in Dezimal. Die zwei Hex Zahlen FF am oberen Wertebereich ergeben Dezimal 255.

Bei der MAC Adresse sind die Buchstaben:
V = Vendor
N = Hochzählende Nummer

MAC Adresse: VV:VV:VV:NN:NN:NN
                      |  |  |
IP Adresse:        A.B .C .D

Meine Schlussfolgerung des ganzen ist da schon bei Verwendung der ARDEN Software doppelte IP Adressen nicht vermeidbar sind, ist es auch egal was für eine IP Adresse für das DtD Link Interface vergeben wird.


Auf den Link Interfaces sind die IP Adressen als Link-Local-Scope konfiguriert. Das bedeutet eine Kommunikation ist auf dem Link mit dem angeschlossenem Nachbarn möglich es erfolgt jedoch kein Routing dieser Adressen. Das Routing übernimmt später das OLSR Protokoll.

Die Interface Konfiguration für das zusätzliche VLAN Interface auf dem Ethernet Port funktioniert bei mit über die Datei
/etc/dhcpcd.exit-hook
mit dem Inhalt:
if [ "$reason" = "PREINIT" ]; then
        sudo ip -4 address add 10.123.132.38/8 dev eth0.2 scope link
        exit 0
fi

Nun fehlt noch OLSR. Dies besteht aus dem Hauptmodul olsrd und Erweiterungen. Mindestens ist das plugin nameservice erforderlich. Wird dies weggelassen, ist auf der ARDEN Statusseite nur die IP Adresse des Raspberry PI zu sehen. Da AREDN auch arprefresh verwendet habe ich das ebenfalls mit aktiviert. OLSRD hat eine Erweiterung für GPS Koordinaten. Diese werden über das plugin pud von gpsd eingelesen und können dann auf der Webseite (plugin httpinfo) angezeigt werden. Über das Smart Gateway plugin kann eine Weiterleitung der GPS Daten erfolgen was wohl bei olivgrünen MANET Anwendungen genutzt wird.
Die Installation von olsrd auf meinem System war zwar prinzipiell über das Repository möglich aber gpsd hat wohl in der Vergangenhiet mehmals das Übergabeformat der GPS Koordinaten geändert. Die pud Erweierung wurde zwar nachgezogen aber halt nur im GITHUB. Die olsrd Version bei mir im Repository ist aus 2015 und inkompatibel zur im Repository vorhandenen gpsd Version.

Also ein git clone von olsrd und jedes plugin einzeln mit "make && sudo make install" compilieren. Wenn eine Fehlermeldung kommt fehlt noch irgendeine Abhängigkeit. Bei mir war das "sudo apt-get install bison flex"

Es muss dann das Konfig File noch angelegt oder erweitert werden. Jedes Modul möchte darin eine eigene Sektion haben damit es geladen wird.
Starten mit
sudo olsrd -f /etc/olsrd/olsrd.conf
Damit mehr Ausgaben angezeigt werden muss den "DebugLevel  0" in der Datei auf eine höhere Nummer gesetzt werden.

Wenns dann mal läuft fehlt noch die Datei /etc/init.d/olsrd damit auch nach einem Reboot der Dienst läuft.

Und dann noch starten mit
systemctl start olsrd.service



Angehängte Dateien Thumbnail(s)
                       

.txt   olsrdcfgfile autogenerated.txt (Größe: 20.57 KB / Downloads: 61)
.txt   init_d_olsrd.txt (Größe: 2.26 KB / Downloads: 63)
Drucke diesen Beitrag

  Topologie
Geschrieben von: DK2FK - 07-04-2023, 21:03 - Forum: AREDN für Ulm - Antworten (1)

Die aktuelle Netzwerktopologie lässt sich mittels nc auf den lokalen Knoten im PlantUML format exportieren

Code:
nc localnode.local.mesh 2004

Das sollte dann so aussehen:

Code:
digraph topology
{
"10.197.33.213" -> "10.33.246.96"[label="0.100", style=solid];
"10.197.33.213"[shape=box];
"10.197.33.213" -> "10.74.242.90"[label="0.100", style=solid];
"10.33.246.96" -> "10.34.160.49"[label="0.100"];
"10.33.246.96" -> "10.35.44.200"[label="0.100"];
"10.33.246.96" -> "10.48.229.97"[label="0.100"];
"10.33.246.96" -> "10.197.33.213"[label="0.100"];
"10.34.160.49" -> "10.33.246.96"[label="0.100"];
"10.35.44.200" -> "10.33.246.96"[label="0.100"];
"10.35.44.200" -> "10.123.132.38"[label="0.100"];
"10.48.181.27" -> "10.48.200.146"[label="1.000"];
"10.48.181.27" -> "10.48.229.97"[label="1.000"];
"10.48.181.27" -> "10.178.62.180"[label="0.100"];
"10.48.200.146" -> "10.48.181.27"[label="1.000"];
"10.48.200.146" -> "10.48.229.97"[label="1.000"];
"10.48.229.97" -> "10.33.246.96"[label="0.100"];
"10.48.229.97" -> "10.48.181.27"[label="1.000"];
"10.48.229.97" -> "10.48.200.146"[label="1.000"];
"10.74.242.90" -> "10.197.33.213"[label="0.100"];
"10.123.132.38" -> "10.35.44.200"[label="0.100"];
"10.178.62.180" -> "10.48.181.27"[label="0.100"];
"10.197.33.213" -> "10.33.246.96"[label="0.100"];
"10.197.33.213" -> "10.74.242.90"[label="0.100"];
"10.48.229.97" -> "10.135.43.8/29"[label="HNA"];
"10.135.43.8/29"[shape=diamond];
"10.48.181.27" -> "10.133.168.216/29"[label="HNA"];
"10.133.168.216/29"[shape=diamond];
"10.48.200.146" -> "10.134.68.144/29"[label="HNA"];
"10.134.68.144/29"[shape=diamond];
"10.123.132.38" -> "10.123.132.38/32"[label="HNA"];
"10.123.132.38/32"[shape=diamond];
"10.34.160.49" -> "10.21.1.136/29"[label="HNA"];
"10.21.1.136/29"[shape=diamond];
"10.33.246.96" -> "10.15.179.0/29"[label="HNA"];
"10.15.179.0/29"[shape=diamond];
"10.178.62.180" -> "10.145.245.160/29"[label="HNA"];
"10.145.245.160/29"[shape=diamond];
"10.178.62.180" -> "10.178.62.180/32"[label="HNA"];
"10.178.62.180/32"[shape=diamond];
"10.74.242.90" -> "10.87.146.208/29"[label="HNA"];
"10.87.146.208/29"[shape=diamond];
"10.35.44.200" -> "10.25.102.64/29"[label="HNA"];
"10.25.102.64/29"[shape=diamond];
"10.35.44.200" -> "10.35.44.200/32"[label="HNA"];
"10.35.44.200/32"[shape=diamond];
"10.197.33.213" -> "0.0.0.0/0"[label="HNA"];
"0.0.0.0/0"[shape=diamond];
"10.197.33.213" -> "10.197.33.213/32"[label="HNA"];
"10.197.33.213/32"[shape=diamond];
"10.197.33.213" -> "10.41.14.168/29"[label="HNA"];
"10.41.14.168/29"[shape=diamond];
}

Um das ganze mit Plantuml zu konvertieren muss man noch den Zeilenumbruch nach toppology durch ein Leerzeichen ersetzen und das ganze mit @startuml und @enduml einrahmen.

Code:
@startuml
digraph topology {
"10.197.33.213" -> "10.33.246.96"[label="0.100", style=solid];
"10.197.33.213"[shape=box];
"10.197.33.213" -> "10.74.242.90"[label="0.100", style=solid];
"10.33.246.96" -> "10.34.160.49"[label="0.100"];
"10.33.246.96" -> "10.35.44.200"[label="0.100"];
"10.33.246.96" -> "10.48.229.97"[label="0.100"];
"10.33.246.96" -> "10.197.33.213"[label="0.100"];
"10.34.160.49" -> "10.33.246.96"[label="0.100"];
"10.35.44.200" -> "10.33.246.96"[label="0.100"];
"10.35.44.200" -> "10.123.132.38"[label="0.100"];
"10.48.181.27" -> "10.48.200.146"[label="1.000"];
"10.48.181.27" -> "10.48.229.97"[label="1.000"];
"10.48.181.27" -> "10.178.62.180"[label="0.100"];
"10.48.200.146" -> "10.48.181.27"[label="1.000"];
"10.48.200.146" -> "10.48.229.97"[label="1.000"];
"10.48.229.97" -> "10.33.246.96"[label="0.100"];
"10.48.229.97" -> "10.48.181.27"[label="1.000"];
"10.48.229.97" -> "10.48.200.146"[label="1.000"];
"10.74.242.90" -> "10.197.33.213"[label="0.100"];
"10.123.132.38" -> "10.35.44.200"[label="0.100"];
"10.178.62.180" -> "10.48.181.27"[label="0.100"];
"10.197.33.213" -> "10.33.246.96"[label="0.100"];
"10.197.33.213" -> "10.74.242.90"[label="0.100"];
"10.48.229.97" -> "10.135.43.8/29"[label="HNA"];
"10.135.43.8/29"[shape=diamond];
"10.48.181.27" -> "10.133.168.216/29"[label="HNA"];
"10.133.168.216/29"[shape=diamond];
"10.48.200.146" -> "10.134.68.144/29"[label="HNA"];
"10.134.68.144/29"[shape=diamond];
"10.123.132.38" -> "10.123.132.38/32"[label="HNA"];
"10.123.132.38/32"[shape=diamond];
"10.34.160.49" -> "10.21.1.136/29"[label="HNA"];
"10.21.1.136/29"[shape=diamond];
"10.33.246.96" -> "10.15.179.0/29"[label="HNA"];
"10.15.179.0/29"[shape=diamond];
"10.178.62.180" -> "10.145.245.160/29"[label="HNA"];
"10.145.245.160/29"[shape=diamond];
"10.178.62.180" -> "10.178.62.180/32"[label="HNA"];
"10.178.62.180/32"[shape=diamond];
"10.74.242.90" -> "10.87.146.208/29"[label="HNA"];
"10.87.146.208/29"[shape=diamond];
"10.35.44.200" -> "10.25.102.64/29"[label="HNA"];
"10.25.102.64/29"[shape=diamond];
"10.35.44.200" -> "10.35.44.200/32"[label="HNA"];
"10.35.44.200/32"[shape=diamond];
"10.197.33.213" -> "0.0.0.0/0"[label="HNA"];
"0.0.0.0/0"[shape=diamond];
"10.197.33.213" -> "10.197.33.213/32"[label="HNA"];
"10.197.33.213/32"[shape=diamond];
"10.197.33.213" -> "10.41.14.168/29"[label="HNA"];
"10.41.14.168/29"[shape=diamond];
}
@enduml

Konvertiert sah das dann heute bei mir so aus:
[Bild: dLHDJyCm3BttLrGzWnSdQTeA3OaR9_x0nA5JfsrI...S_9VrCakGB]

Drucke diesen Beitrag


Benutzer Online
Momentan sind 7 Benutzer online » 0 Mitglieder
» 7 Gäste

Deutsche Übersetzung: MyBB.de, Powered by MyBB, © 2002-2024 Melroy van den Berg.