https://forum.amateurfunk-ulm.de/ Thu, 14 May 2026 13:22:56 +0000 MyBB https://forum.amateurfunk-ulm.de/thread-32.html Sat, 08 Apr 2023 10:56:01 +0000 dominik]]> https://forum.amateurfunk-ulm.de/thread-32.html 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

  MeshStatusOnRemote.png (Größe: 54.94 KB / Downloads: 391)

  OLSR_daemon_Configuration.png (Größe: 134.74 KB / Downloads: 392)

  OLSR_daemon_Routes.png (Größe: 69.93 KB / Downloads: 395)

  OLSR_daemon_LinksTopology.png (Größe: 80.86 KB / Downloads: 389)

  OLSR_daemon_SmartGateway.png (Größe: 29.47 KB / Downloads: 387)

  OLSR_daemon_Position.png (Größe: 106.26 KB / Downloads: 368)

  olsrdcfgfile autogenerated.txt (Größe: 20.57 KB / Downloads: 425)

  init_d_olsrd.txt (Größe: 2.26 KB / Downloads: 409) ]]> 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

  MeshStatusOnRemote.png (Größe: 54.94 KB / Downloads: 391)

  OLSR_daemon_Configuration.png (Größe: 134.74 KB / Downloads: 392)

  OLSR_daemon_Routes.png (Größe: 69.93 KB / Downloads: 395)

  OLSR_daemon_LinksTopology.png (Größe: 80.86 KB / Downloads: 389)

  OLSR_daemon_SmartGateway.png (Größe: 29.47 KB / Downloads: 387)

  OLSR_daemon_Position.png (Größe: 106.26 KB / Downloads: 368)

  olsrdcfgfile autogenerated.txt (Größe: 20.57 KB / Downloads: 425)

  init_d_olsrd.txt (Größe: 2.26 KB / Downloads: 409) ]]> https://forum.amateurfunk-ulm.de/thread-29.html Wed, 29 Mar 2023 16:45:31 +0000 DG6SK]]> https://forum.amateurfunk-ulm.de/thread-29.html 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.]]> 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.]]> https://forum.amateurfunk-ulm.de/thread-13.html Sun, 12 Mar 2023 21:32:23 +0000 DK2FK]]> https://forum.amateurfunk-ulm.de/thread-13.html
Mein Knoten ist aktuell meistens nur abends online (wenn ich was daran mache), Peters ziemlich durchgehend.

Mehrere "gemeshte" tunnel haben wir noch nicht getestet, das wäre vielleicht auch noch mal interessant.]]>
Mein Knoten ist aktuell meistens nur abends online (wenn ich was daran mache), Peters ziemlich durchgehend.

Mehrere "gemeshte" tunnel haben wir noch nicht getestet, das wäre vielleicht auch noch mal interessant.]]> https://forum.amateurfunk-ulm.de/thread-5.html Sun, 05 Mar 2023 22:14:17 +0000 DM4AB]]> https://forum.amateurfunk-ulm.de/thread-5.html
Letztes Wochenende hatte ich einen Testaufbau wie unten auf den Bildern gezeigt zwischen zwei Nanostation M5. Das Feld war relativ eben zwischen beiden Stationen. Der erste Versuch war mit beiden Stationen in 1m Höhe über Grund in der Erwartung, dass sich die Bodennähe erhöhte Dämpfung bemerkbar macht. Realistisch war zwischen beiden Stationen ein bisschen Einschnürung, d.h. etwa in der Mitte Sichtline war die Sichtlinie vielleicht 0.6m über Grund. Die Skizze zeigt den Querschnitt. Die beiden Stationen waren 180m voneinander entfernt.

Hier (https://circuitdesign.de/technical_tools/fresnel-zone/) kann man den Radius einer Fresnelzone berechnen. Bei einer Frequenz von 5.6GHz und 180m Abstand ergibt sich ein Radius, der sich in eine minimal wünschenswerte Antennenhöhe von 1.6m übersetzt.

Entsprechend Skizze erreiche ich mit meiner Einschnürung nicht die gesamte Fresnelfäche sondern berechnet fehlen mir 1.8m^2 von der Gesamtfläche von rund 8m^2, also ~25% Flächenverlust, das sollte durch die zu kleine Aufbauhöhe zu einer zusätzlichen Dämpfung von 1.25 dB führen.

Was habe ich gemessen?
Montagehöhe 1m   --> ~-58dBm, SNR ~36dB
Montagehöhe 2m   --> ~-48dBm, SNR ~48dB

Der gemessene Unterschied in Signalstärke beträgt etwa 10dB, und ist um ein Vielfaches höher als die zu erwartenden 1.25dB.
Wie kann man sich das erklären?

---

  skizze.jpg (Größe: 15.09 KB / Downloads: 373)
  auto-seite-nah.jpg (Größe: 99.97 KB / Downloads: 379)
  auto-seite-fern.jpg (Größe: 84.72 KB / Downloads: 391)
  gegenstelle.jpg (Größe: 109.75 KB / Downloads: 366)
  gegenstelle-nah.jpg (Größe: 105.07 KB / Downloads: 354) ]]>
Letztes Wochenende hatte ich einen Testaufbau wie unten auf den Bildern gezeigt zwischen zwei Nanostation M5. Das Feld war relativ eben zwischen beiden Stationen. Der erste Versuch war mit beiden Stationen in 1m Höhe über Grund in der Erwartung, dass sich die Bodennähe erhöhte Dämpfung bemerkbar macht. Realistisch war zwischen beiden Stationen ein bisschen Einschnürung, d.h. etwa in der Mitte Sichtline war die Sichtlinie vielleicht 0.6m über Grund. Die Skizze zeigt den Querschnitt. Die beiden Stationen waren 180m voneinander entfernt.

Hier (https://circuitdesign.de/technical_tools/fresnel-zone/) kann man den Radius einer Fresnelzone berechnen. Bei einer Frequenz von 5.6GHz und 180m Abstand ergibt sich ein Radius, der sich in eine minimal wünschenswerte Antennenhöhe von 1.6m übersetzt.

Entsprechend Skizze erreiche ich mit meiner Einschnürung nicht die gesamte Fresnelfäche sondern berechnet fehlen mir 1.8m^2 von der Gesamtfläche von rund 8m^2, also ~25% Flächenverlust, das sollte durch die zu kleine Aufbauhöhe zu einer zusätzlichen Dämpfung von 1.25 dB führen.

Was habe ich gemessen?
Montagehöhe 1m   --> ~-58dBm, SNR ~36dB
Montagehöhe 2m   --> ~-48dBm, SNR ~48dB

Der gemessene Unterschied in Signalstärke beträgt etwa 10dB, und ist um ein Vielfaches höher als die zu erwartenden 1.25dB.
Wie kann man sich das erklären?

---

  skizze.jpg (Größe: 15.09 KB / Downloads: 373)
  auto-seite-nah.jpg (Größe: 99.97 KB / Downloads: 379)
  auto-seite-fern.jpg (Größe: 84.72 KB / Downloads: 391)
  gegenstelle.jpg (Größe: 109.75 KB / Downloads: 366)
  gegenstelle-nah.jpg (Größe: 105.07 KB / Downloads: 354) ]]> https://forum.amateurfunk-ulm.de/thread-4.html Sun, 05 Mar 2023 18:47:23 +0000 DH1DH]]> https://forum.amateurfunk-ulm.de/thread-4.html
anbei mein Setup für eine Internetversorgung. Der erste, grundsätzliche, Gedanke war AREDN ausschliesslich nur als Transportnetzwerk (Bereitstellung von Links) zu nutzen. Aufgrund der Verschlüsselung nur auf ISM Frequenzen. Das Netzwerk hat nur so wenige Nodes weil ich leider nicht mehr habe, lief aber produktiv problemlos einige Tage am Stück völlig stabil. 

Grüsse Dieter
vy 73 de DH1DH


]]>
anbei mein Setup für eine Internetversorgung. Der erste, grundsätzliche, Gedanke war AREDN ausschliesslich nur als Transportnetzwerk (Bereitstellung von Links) zu nutzen. Aufgrund der Verschlüsselung nur auf ISM Frequenzen. Das Netzwerk hat nur so wenige Nodes weil ich leider nicht mehr habe, lief aber produktiv problemlos einige Tage am Stück völlig stabil. 

Grüsse Dieter
vy 73 de DH1DH


]]>