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)
                       

  olsrdcfgfile autogenerated.txt (Größe: 20.57 KB / Downloads: 123)
  init_d_olsrd.txt (Größe: 2.26 KB / Downloads: 126)

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

Hallo zusammen.

Ich habe mehr als eine Woche meine Bastelabende investiert, um die Kommunikation zwischen AREDN Knoten zu verstehen. Mein Startproblem war eigentlich ganz einfach: ich wollte einen alten TP-Link WR841 (so eine weiße 2.4GHz WLAN Seifenschale) als Switch zwischen zwei AREDN Knoten verwenden und dabei auch gleich noch einen Hotspot zu realisieren. Oder alternativ in zwei Knoten gleichzeitig mein LAN (für das AREDN Netzwerk wäre das der WAN Anschluss) einzuspeisen.
Gedacht, gemacht, geht so nicht.

   

Wieso geht das nicht? Hmmm. Wenn man die beiden Nanostations direkt miteinander verbindet, scheint alles in Ordnung. So bald ich den Switch dazwischen setze (also ohne die Router Funktionen im WLAN Router), dann funktioniert das nicht mehr richtig. Was heißt "funktioniert nicht richtig"?

Wenn die beiden Nanostations direkt mit einem Ethernet Kabel verbunden (ge-patch-t) sind, dann geht eine rote LED an, was so viel heißt wie "Mesh aktiv", und wenn ich mich via drittem Node auf mit den beiden verbinde, dann melden sie ordnungsgemäß "Device-to-Device" (DtD) Link ativ. So soll es sein, so funktioniert das richtig. Und so bald ich den Switch dazwischen setze funktioniert es eben nicht mehr, aber warum? Das muss doch ein Fehler des Switches sein, verflixt nochmal!
Tatsächlich ist ein Fehler der Switch Konfiguration, und das genau zu verstehen, hat leider etwas gedauert. Ich spare mir die Schilderung des Wegs zur Erkenntnis zu Gunsten der Ergebnisbeschreibung.

AREDN Knoten kommunizieren auf drei verschiedenen logischen Kanälen, wovon zwei mittels VLAN Tagging versehen sind. Davon hatte ich schon einmal gelesen, aber nichts verstanden. VLAN Tags sind eine Ergänzung eines Ethernet Frames (also keine TCP/IP Funktion, sondern eine Layer2 Eigenschaft), mit welcher man einfach Switches realisieren kann indem man z.B. den Verkehr auf jedem Port eines Switches mit einem Tag versieht. Dann weiß die zentrale Switch CPU genau, welches Paket von welchem Port (Anschluss) kam und ob es verbotene Datenpfade gibt oder besonders erlaubte. So implementiert ein Switch z.B. auch eine Durchsatzlimitierung.
Bevor die Pakete wieder den Switch verlassen müssen die Tags wieder aus den Ethernet Datenpaketen entfernt werden, denn das ist ja etwas, das der Switch eigentlich für sich eingefügt hat. Eigentlich!

Entfernt man die Tags nicht aus den Ethernet Paketen und lässt sie aus dem Switch nach draußen, dann kann man auch außerhalb des Switches noch ge-tag-gte Pakete erkennen. Bis zu ~2^12 Tags sind möglich! Pakete ohne Tag sind vier Byte kürzer, stören aber getaggte Pakete gar nicht. Zeitlich nacheinander coexistieren die auf der Ethernet Verbindung. Das ganze folgt dem IEEE Standard 802.1Q.

Unsere AREDN Knoten verwenden:

• ungetaggte Pakete, um sich bei einem Router im Heimnetz, HAMNET oder woanders eine IP Adresse zu besorgen und Daten zu empfangen oder zu senden.
  
• Pakete mit VLAN TAG 1, die in Zusammenschaltungs-Situationen (mein Bild, s. oben) so etwas wie einen Fernwartungszugriff auf genau einen Knoten erlauben.
  
• Pakete mit VLAN TAG 2, auf welchem die Nodes Routing Information miteinadner austauschen (DtD, s. oben).
  

1. verbindet man einen AREDN Knoten direkt mit dem eigenen Heimnetz (wo bereits ein DHCP Server/Dienst aktiv ist) ohne einen Switch, der VLAN Tags behandelt, dann bleibt er stumm.
   
2. währenddessen kann man aber beobachten, dass er Verkehr mit VLAN Tag2 versucht; dort wird nach einem OLSR Nachbarn gesucht ("HELLO" Nachrichten)-
   
3. verbindet man einen Laptop mit dem AREDN Knoten, dann fragt der Laptop, nachdem er ein aktiven Netzanschluss erkannt hat, ob es einen DHCP Server gibt und bittet um eine Adresse; dann vergibt der AREDN Knoten als DHCP Server dem Laptop eine Adresse und man kann ihn via seiner Homepage lokal erreichen. Der Laptop bekommt dann eine Adresse aus dem LAN Adressbereich des AREDN Knoten.
      
   
   

1. Schließt man einen AREDN Knoten mit seinen drei logischen Kanälen (untagged, VLAN Tag1 und Tag2) an einen Switch an und übersetzt den Verkehr 
   (a) aus dem Knoten von VLAN Tag 1 --> untagged um (d.h. AREDN-Knoten sendet mit Tag1, Switch übersetzt zu untagged), und
   (b) in den Knoten von untagged --> VLAN Tag 1 um, dann
   
2. ist der Knoten mit einem Mal mit WAN versorgt, man kann aber nicht mehr ohne weiteres auf die Verwaltungsoberfläche zugreifen.
   
   
3. Wenn man jetzt einen zweiten Knoten online bringt, der sich via Mesh mit dem ersten Knoten verbindet (Laptop am zweiten Knoten wie in (A) verbunden), dann berichtet der zweite Knoten, dass er WAN via ersten Knoten erhält und man kann ganz normal auf das WAN (Internet) zugreifen.
   (im Bild: DM4AB3 hängt am Switch mit VLAN Tag Übersetzung, s (1), DM4AB2 ist der zweite Knoten mit WAN Zugang)
      
   
   
4. Währenddessen lässt sich beobachten, dass auf dem logischen Kanal mit Tag VLAN 2 OLSR Protokoll läuft und sich die beiden Knoten austauschen zur Link-Qualität, Bandbreite, ...
   

• schließt man einen Laptop an einen Knoten direkt an, dann kann man den Knoten konfigurieren
  
• schließt man ein WAN an einen Knoten direkt an, passiert nichts direkt hilfreiches: der Knoten fragt nach keiner Adresse, bleibt stumm, wird keine Daten weiterleiten
  
• liefert man WAN auf VLAN1 an den Knoten, dann fragt er nach einer IP-Adresse in dem Netzwerk und verhält sich danach wie ein normaler LAN Teilnehmer im lokalen Netz, und falls er Anfragen via WLAN nach Internet-Inhalten erhält, versucht er diese zu besorgen wie jeder lokale LAN Teilnehmer auch.
  
• Verkehr auf VLAN Tag2 ist nett zu sehen, aber nicht unbedingt relevant, außer man möchte zwei Knoten miteinander lokal verbinden!
  

1. Verkehr mit Tag1 muss zwischen beiden Knoten möglich sein (das ist der WAN Verkehr!)
   
2. Verkehr mit Tag2 muss zwischen beiden Knoten möglich sein (damit tauschen die beiden Knoten Link-Information aus, DtD, Device-to-Device Link)
   
3. Untagged Verkehr des einen oder anderen Knoten ist nett, damit man die Knoten konfigurieren kann; sinnvollerweise wollten sich die beiden Knoten hier nicht "sehen", sonst bekommt der angeschlossene Laptop von zwei DHCP Servern eine Adresse angeboten.
   
4. damit der WLAN Hotspot den WAN Verkehr versteht, braucht er eine Version davon ohne Tags (=Tag1 entfernt); ausgehender Verkehr vom WLAN Accesspoint muss mit Tag1 versehen werden und beiden AREDN Knoten weiter gegeben werden, sonst wissen die nicht, dass es sich um WAN Verkehr handelt.
   

Mein Ziel war es, eine Sprachkommunikation mit einfachen Mitteln im AREDN-Mesh, ausschließlich mit IP-Telefonen bzw. einer Softwarelösung auf dem Laptop, herzustellen.

Erste Versuche erfolgten mit IP-Telefonen des Typs Snom300 mit Firmware 8.7.3.25.9.
Die Telefone verfügen über ein Web-Interface und lassen sich somit gut konfigurieren.
Den Login in die 4 möglichen Identities habe ich ausgeschaltet. Somit versucht das Telefon sich nicht an einem Server anzumelden.
Wichtig sind dann noch die folgende Einstellungen, vor allem um auch eingehende Anrufe zu erkennen:

In den Menuepunkten:

Advanced->SIP/RTP->SIP->Network identy (port): 5060
Advanced->SIP/RTP->SIP->Listen on SIP TCP Port: on
Advanced->QoS/Security->Filter Packets from Registrar: off

Die IP-Adresse des Telefons kennt man im Regelfall schon, wenn man das Telefon im AREDN-Mesh konfiguriert hat.
Erfolgte die Konfiguration ausserhalb, z.B. an der heimischen Fritzbox, so kann man die IP-Adresse recht einfach am
AREDN-Node bestimmen. Mit dem Web-Browser den Knoten, an dem das Telefon angeschlossen ist, aufrufen.
Im Setup den Punkt Port Forwarding, DHCP and Services aufrufen.
Unter Current DHCP Leases ist die IP-Adresse sichtbar.

Ein Telefon war bei mir am Mikrotik hAP (DG6SK-1) angeschlossen, ein weiteres am GL.Inet GL-AR300M16-ext. (DG6SK-3).
Beide Knoten waren über 2 GHz im AREDN-Mesh verbunden.
Die gegenseitige Anwahl über die jeweilige IP-Adresse verlief problemlos, auch die Sprachübertragung stellte kein Problem dar.
Die Wahl des "Punktes" in der IP-Adresse erfolgt mit der Sternchen-Taste (*). Auch lässt sie Rufnummer im Directory, also dem
Telefonbuch des Telefons abspeichern, hier allerdings in der üblichen Schreibweise der IP-Adresse mit Punkt (.).
Was am angerufenen Telefon als Anrufer angezeigt wird, ist von den Einstellungen des Telefons und den Einstellungen der Gegenstation abhängig.
Im Regelfall ist es nicht die IP-Adresse.

Anmerkung:
Bei Telefonen dieses Typs ist bei nicht angenommen Anrufen später nicht ersichtlich, dass ein Anruf stattgefunden hat.
Auch eine Wiederwahl einer zuvor gewählten (IP-) Nummer ist nicht möglich. 

Probleme, die während des Test auftraten:

Die Snom300 Telefone haben an den AREDN-Nodes oftmals Probleme per DHCP eine Adresse zugewiesen zu bekommen, bzw. erkennen nicht,
dass sie an einem Ethernet-Port angeschlossen sind. An der heimischen Fritzbox war das kein Problem. Auch mit einem zusätzlichen Switch
(Netgear GS105E) zwischen Knoten und Telefon war das kein Problem.

Nach meinen erfolgreichen Tests verabredete ich mich mit Andreas (DM4AB) um über das AREDN-Mesh und Tunnel zu telefonieren.
Andreas setzte bei sich auf dem Laptop die Software microSIP ein. Eine gegenseitige Anwahl und auch Sprachkommunikaton 
verlief ohne jegliche Probleme.

Sollte jemand auch testen wollen und benötigt einen (Gesprächs-) Partner, dann bitte kurze Mitteilung an mich und ich sende dir dann die IP-Adresse
meines Telefons im AREDN-Mesh.

Ich hatte den Auftrag mitgenommen, die Sichtbarkeit des Universum-Centers vom Standort von DB0ULM (Turm des Gebäudes Albert-Einstein-Allee 45) aus optisch zu prüfen.

Fazit: die Sichtlinie ist leider nicht frei. Das Problem ist die südwestliche Ecke des "Uni-Waldes" (gegenüber der Physiotherapie-Schule), das zeigt auch das Geländeprofil. Sehr viel besser sieht es vom Turm AE 47 aus (das ist der westlichste der Türme der Uni West). Allerdings befinden sich dort Mobilfunkinstallationen und von Uni-Seite ist deshalb das Betreten der Turmplattform generell verboten.

73, Hermann, DF2DR

Hallo,
ich hatte immer wieder das Problem, dass der Name einers remote Routers nicht aufgelößt werden konnte.
Nach etwas suche stellte sich herraus, dass das ein bekannter Bug in den Versionen v3.22.8.0 bis v3.22.12.0 ist und im aktuellen Nightly Build behoben ist.
In aredn-2442-72dd3ae-ath79-generic-glinet_gl-ar300m16-squashfs-sysupgrade.bin funktionierte bei einem Test die Namensauflösung auf anhieb.
Da dort aber zumindest bei meinem Gerät das WAN Interface nicht mehr geht bin ich nun auf v3.22.6.0 und hoffe auf einen fix.
Grüße

Blitzschutz
Nachdem uns Oliver beim Treffen am 21. März recht deutlich aufzeigte, dass auch ein indirekter Treffer recht unangenehme Folgen haben kann, sollte die Frage irgendeiner Art des Schutzes vor direktem Einschlag, Einschlag in der Nachbarschaft und durch Zuleitungen zugeführter Überspannung klar sein. Neben vielen einschlägigen Normen (sehr langweilig und trocken!) habe ich ein tolles Dokument eines Blitzschutzherstellers gefunden.

Link zum Blitzschutzleitfaden des Anbieters OBO: https://www.obo.de/unternehmen/news/nach...n-von-obo/


Rufzeichenzuteilung für einen Standorte, Sendeleistung (ERP), Standorterklärung
Jann Traschewski (DG8NGN) machte mich auf die VUS (VUS: VHF/UHF/SHF) Seiten des DARC aufmerksam. Dort gibt es einen eigenen Abschnitt zu Automatischen Stationen. Jeder Hamnet Knoten wird als eine automatisch arbeitende Station angesehen. Auf der Seite finden sich interessante Hinweise.

Wir brauchen natürlich ein Rufzeichen, Antrag auf Rufzeichenzuteilung. DB0MUL wäre frei (Maritim ULm). Den weiteren Informationen folgend scheinen wir für Linkstrecken und kommerziell verfügbares Equipment kein ernsthaftes ERP Problem zu haben.
Ein weiterer Hinweis findet sich: "Wenn es keine Überlappungsbereiche mit anderen Funkdiensten am Standort gibt, kann eine Selbsterklärung gemacht oder bei weniger als 10W EIRP sogar auf eine Selbsterklärung verzichtet werden."

Interessant (und ich hatte es fast schon wieder vergessen): EIRP bekommt man mit der Rechnung "Sendeleistung" + "Antennengewinn in dBi", die Limitierung gilt aber für ERP, was sich auf einen Lambda-Halbe Dipol bezieht. D.h. ERP = EIRP - 2.15 dB, wie hier vorgerechnet.

Liebe OMs,
nach einer hitzig geführten Diskussion mit DM4AB möchte ich hier für alle transparent darlegen, warum ich die gleichzeitige Installation einer X-5000 2m/70cm-Antenne dort nicht befürworten kann.

Rolf, DL6SL, und ich nutzen den Standort Maritim seit wohl 25 Jahren immer wieder als Standort für 2m-BOS-Relais bei großen Veranstaltungen. Daher kann ich in Anspruch nehmen, dass ich die Situation dort extrem gut kenne. Ich möchte meine Argumentation dreiteilen.

1. Notwendigkeit einer 2m/70cm-Antenne dort unter Notfunk-Aspekten

a. Wir mussten über die Jahre feststellen, dass der Standort zur Versorgung der Innenstadt nicht so gut geeignet ist, wie man denken könnte. Bei Einsatz einer Groundplane dort kommt es bereits im Bereich des Marktplatzes zu Auslöschungen durch Mehrwege-Ausbreitung. Deshalb sind wir jetzt, mit Ausnahme des Einstein-Marathons, auf einen Standort auf dem Verwaltungsgebäude der Sparkasse übergegangen. Da ist zwar die Elevation noch negativer, aber man ist einfach näher dran.

b. Wenn man sowieso das Dach des Maritims betreten muss, um in einem Notfall dort z.B. ein Crossband-Relais an die vorhandene Antenne anzuschließen, beträgt die Zeitersparnis höchstens 15 Minuten - länger brauchen wir nämlich nicht, einen Steckmast mit Antenne aufzustellen, die Spannungsversorgung anzuschließen und das Relais in Betrieb zu nehmen. Übrigens, Afu-Crossband-Relais haben wir dort schon oft betrieben (mit einer X-30). Aus meiner Sicht lohnt die Zeitersparnis den zusätzlichen Aufwand (siehe auch unten) und das Risiko nicht, das eine so auffällige Antenne für das eigentliche Anliegen, nämlich dort einen Hamnet-Knoten zu etablieren, darstellen würde.

c. Anders wäre es, wenn man dort einen permanenten Umsetzer etablieren würde, der dann aber auch lizenziert sein müsste. Dies führt Komplikationen, auf die ich noch eingehen möchte.

2. Einsatz speziell einer X-5000 oder ähnlichen Antenne

Wie uns sicher allen bekannt, haben Hochgewinn-Rundstrahler eine starke Bündelung in der Elevationsebene. Das bedeutet natürlich nicht, dass man in der Nähe bei stark negativen Elevationswinkeln kein Signal empfängt, aber das Link-Budget ist schlechter als bei einer Antenne mit geringem Gewinn am gleichen Standort.

Bei offizieller Errichtung einer automatischen Station ist die Strahlungsleistung in Hauptstrahlrichtung auf 15 W EIRP begrenzt. Die X-5000 weist lt. Wimo bei 144 MHz einen Gewinn von 4,5 dB und bei 432 MHz von 8,3 dB auf. Ob die Zahlen so stimmen, ist nicht so wichtig, aber es wird sehr schwer sein, der BNetzA gegenüber mit nennenswert anderen Zahlen zu argumentieren. Da das EIRP in Hauptstrahlrichtung bestimmt wird, wir aber vor allem bei nennenswert negativen Elevationen für die Stadtversorgung arbeiten, leiden wir dort doppelt: nicht nur haben wir die hohe Winkeldämpfung der Antenne, sondern wir müssen wegen der begrenzten zulässigen Strahlungsleistung die Sendeleistung absenken, was das Link Budget im für uns relevanten Bereich weiter verschlechtert.

Mit einer Länge von 1,80 m ist die X-5000 zudem deutlich sichtbarer als die aktuell dort verbauten Groundplanes der Fa. SHS.

3. Andere Aspekte

a. Die Diamond-Antennen sind zwar gegen statische Aufladung gesichert (über den Mast geerdet), aber auf dem zur Nutzung vorgesehenen Mast ragt sie doch deutlich über die Dachhaut des Aufzuggebäudes und auch über die Groundplanes des gewerblichen Nutzers dort hinaus. Die Frage eines erweiterten Blitzschutzes stellt sich durchaus. Übrigens ist auf dem Dach sehr wohl Blitzschutz vorhanden, der für die (seitliche) Installation angedachte Mast (ehemalige Nutzung durch die Polizeidirektion Neu-Ulm) ist an die Blitzschutzanlage abeschlossen. Hier stellt sich die Kostenfrage, für ein Gutachten und/oder zusätzliche Installation.

b. Mit einer 1,8 m langen Antenne auf dem Mast ist die Windlast zumindest zu prüfen. Wahrscheinlich aber unkritisch bei dem überdimensionierten Mastdurchmesser und der beträchtlichen Einspannlänge.

c. Wir benötigen eine Standortbescheinigung, die die Anlagen der gewerblichen Nutzers mit umfasst. Das ist unabhängig von dem 2m/70cm-Strahler so, aber der macht es auch nicht einfacher ... da nicht nur Amateurfunkinstallationen betroffen sind, muss die Standortbescheinigung von einem autorisierten Anbieter durchgeführt werden. Hier stellt sich ebenfalls die Kostenfrage.

d. Bei Anmeldung eines Relais kommt unweigerlich die BNetzA zur Kontrolle. Glaubt mir das, bei DB0ULM waren sie schon zweimal. Sie schauen ziemlich genau hin.

Fazit

Ich unterstütze durch unsere Kontakte das Ansinnen gern, auf dem Maritim einen Hamnet-Knoten, auch unter Einbeziehung des Bürgernetzes, zu errichten.

Sollte aber auf der Forderung nach einem 2m/70cm-Rundstrahler auf der Mastspitze, insbesondere in der Größe einer X-5000, bestanden werden, bin ich raus.

Mal eine andere Perpektive auf Naturkatastrophen. Aus (sozial-?)wissenschaftlicher Sicht analysiert Rebecca Solnit eine Reihe von Naturkatastrophen und wie sich die betroffenen Menschen und Hilfsorganisationen darin verhalten. Das Buch ist leider relativ US-zentrisch, ich denke aber, dass sich daraus einiges fundamental Menschliches ableiten lässt. Definitiv eine Leseempfehlung von mir.

Erhältlich z.B. hier: https://www.ebook.de/de/product/23994792..._hell.html (leider mit DRM)

(wird fortwährend ergänzt; Hinweise bitte als Kommentar zu diesem Eintrag absenden)

Automatisch arbeitende (Hamnet) Stationen:

• DARC VHF/UHF/SHF Referat (trickreiche Navigation beachten!)
  
• DARC Hamnet-Seite
  
• DARC Seite für Nutzer und Betreiber automatisch arbeitender Stationen (Standorte, Beantragung, Verlängerung, Betreiberwechsel, ...)