Repeater für ungünstige Lage

Es geht hier darum, mit möglichst wenig Aufwand (wenige Antennen) einen nicht direkt erreichbaren Knoten durch Umweg über höhergelegenen “Repeater” zu erreichen.
Folgende Annahme 1: ich habe 2 Geräte eines im “Tal” als client (irgend ein “beam”) und eines am “Berg” als Accesspoint (z.B. nanostation). Der client ist mit einem Tunnel zu funkfeuer verbunden. Wenn dieser sich nun als client zum acesspoint verbindet, sollte über den Funk ja olsr weitergeleitet werden?
Abb1: repeater

Annahme 2: Es soll nun weiterverbunden werden. Kann sich ein weiterer client zum AP verbinden?
Abb2: da nicht alle Stationen im “Tal” Sicht auf den 1.Client haben, Umweg über weitere “Repeater-Stationen”. Die Accesspoints bekommen ihre FF Daten jeweils nur über die verbundenen clientes. Ist dieses Setup praktisch möglich oder gibt es etwas zu beachten?

Grundsätzlich sind die von Dir beschriebenen Szenarien möglich. Zu beachten wäre:

  1. „Hidden Stations“ vermeiden, um nicht unnütz Airtime zu verbraten.
  2. Pönalen für einen der beiden den Tunnel einplanen, um keine Routinganomalien zu schaffen. (Den in Sachen Bandbreite schwächeren Tunnel via OLSR LQMultiplier „verschlechtern“.
  3. Litebeam - LBE-5AC-23? Die kann 2x2 MiMo, die LBE-M5-23 hingegen nur 1x1 SiSo.
  4. Antennencharakteristik - von welchem Abstand der Clients ist hier die Rede? Die Nanostation hat einen sehr großen Öffnungswinkel, ist aber, wenn sie hoch gelegen montiert wird, auch anfällig für Störsignale. Ein CTS auf demselben Kanal innerhalb des Störradius wird selbst mit einer exponierten Nanonstation noch gut empfangen - siehe auch 1.

Fazit - für ein Erstsetup ist es ok. Auf Dauer erwarte ich eher Probleme (Erhöhter Noise Floor Level bei den APs und damit einhergehend Performance-Degradation wegen fehlender Airtime). Langfristig sind dort mehr Antennen anderer Bauart und mit ausreichendem Montageabstand sinnvoller.

Sinnvoll halte ich bei jeder Antenne, die mehr als 2 Funknachbarn hat, einen olsr-Router zwischenzuschalten - also quasi als Knoten zu designen.

Ach so war das gemeint? Ohne OLSR dahinter…? Da würde mE ab dem zweiten Hop IPv6 NDP eventuell Probleme machen. Ich wäre schon davon ausgegangen, dass in der Graphik nur die Antennen eingezeichnet, aber die ER-X-SFP oder OpenWRT-Router mitgemeint wären. Warum sonst wäre „Repeater“ unter Anführungszeichen gestanden?

Nein, ich hab schon gemeint, dass bei jedem node ein openwrt dahinter steckt, z.B. ein GL.AR150 oder so. Mir war nur wichtig, ob ein AP ohne Internetzugang allein von einem client olsr bekommt und dann an neighbors weitergeben kann. Im obigen Beispiel sehen sich die beiden "Tal"Stationen nämlich nicht …
Im einfachsten Fall wäre halt der nanobeam mit dem etwas breiteren Austrahlungswinkel eine einfache Lösung. Habe ich das aber richtig verstanden, dass ein einzelner Nanobeam (hier geht es um ca. 1.7km) auf bridging geschaltet auch ohne Openwrt zwei clients verbinden könnte (sofern die clients im “Sichtbereich” des nanobeams wären?

Das Setup, wie Du es nun beschreibst, hatte ich im Kleinformat eine Zeit lang auf gurk46 in Verwendung (Nanostation Loco M5, später Nanobeam M5-16). Der AP ohne eigene Anbindung, nur mit OLSR hat von einer Antenne im Client-Mode auf fen42 OLSR-Connectivity bekommen. Auch da war die Überlegung, dass gurk46 höher gelegen und daher weiter sichtbar sei, womit er mit vorerst nur einer Antenne im AP-Mode zwischen Clients in der Umgegend vermitteln sollte, bis irgendwann eine weitere Ausbaustufe in Angriff genommen werden kann.

Airmax-Antennen haben eine eigene Repeater-Funktion, in der sie als WDS-Repeater ein und dieselbe SSID weitergeben können. Wie im anderen Fall vermindert sich die Airtime dadurch, dass auf demselben Kanal Pakete zunächst empfangen und dann weitergegeben werden. Besonders gut skaliert das dann nicht, aber für den Anfang reicht es.

Hi,
Habe in obigem Zusammenhang ein OLSR Problem (ist reiner Testaufbau, geht nicht um Performance, nur um das Prinzip zwischen 2 OpenWrt Geräten OLSR weiterzurouten oder zu bridgen):
Testgeräte: CPE210 mit OpenWrt 19.07.3 [Ver 3.0] bzw. CPE210 Ver 3.2 mit aktuellem Snapshot

Grundkonzept (Test):
Ubiquiti Nanostation M2 -> CPE1 -> CPE2

CPE1 bekommt OLSR von der M2, alles OK

Ich habe jetzt auf CPE1 2 Interfaces definiert:
0xFF1: fixe IP, x.x.x.x 255.255.255.255, Netzwerk wlan0 - OK
CPE1 bekommt OLSR auf diesem Interface - OK
0xFF2: das wäre das Interface, das zu CPE2 verbinden sollte: wlan0-1
o funktechnisch soweit ok, ca. 300 Mbit/s,
o eine weitere fixe IP möchte ich vermeiden
o „unmanaged“ scheint nicht zu fuktionieren
o dhcp geht, aber mit privater IP
o static fixe private IP läßt sich konfigurieren, stört aber bei OLSR
o bridgen der beiden Interfaces scheint nicht zu klappen (OLSR stoppt)

Ich bin soweit, dass mir CPE2 als neigbour angezeigt wird, aber mit einer ETX von 0. Wo könnte es da noch haken? Beide Interfaces sind in der gleichen Netzwerkzone (0XFF, NAT, ). Habe Hostrouten auf die public IP’s gesetzt, auch versucht 2 IP’s auf ein Interface zu setzen, immerhin kann ich die privaten IP’s über funk pingen. Wenn es wo konkrete Anleitungen gibt wäre ich für Hinweise dankbar, selbst hab ich nicht viel brauchbares gefunden. Vielleich liegt es noch an den Firewalleinstellungen?
PS: eine Anbindung mit verschlüsseltem WLAN über wlan0-1 zum Laptop wird von der Hardware unterstützt.

"config interface ‚0xFF1‘
option proto ‚static‘
option ipaddr ‚193.238.x.x‘
option netmask ‚255.255.255.255‘

config interface ‚0xFF2‘
option proto ‚static‘
list ipaddr ‚192.168.104.1/24‘
list ipaddr ‚193.238.x.x/32‘ "

1.) Ich würde an Deiner Stelle nicht mit Interface (IP) Aliases auf einem Netzwerkinterface arbeiten, sondern mit VLAN.
Jeder OpenWRT-Router -auch diejenigen, die keinen integrierten Switch haben- können über den Kernel nach IEEE802.3p VLAN-getaggte Pakete ausgeben und decodieren.

2.) Dein Problem scheint darin zu liegen, dass die Firewall „ungültige Pakete“ verwirft, was auch OLSR-Broadcasts betrifft.

Ich würde also sagen wir VLAN 5 als olsr-interlink-VLAN anlegen und dafür eine eigene Firewallzone erstellen. Diese kann, wenn alles funktioniert, beschränkt werden, sodass die Input policy drop, die output policy accept und die forward policy accept ist. In den „Verkehrsregeln“ muss dann unter anderen der OLSR-Port 698 UDP eingehend zugelassen werden. ICMP echo requests wären auch gut. Die Liste müssten wir irgendwo im Wiki haben.

Ad 1) 0xFF2 - OLSR nimmt immer die erste IP als Default-Adresse.

Danke für die rasche Antwort,
offen bleibt für mich die Frage wie ich das 2. Interface am CPE1 anlege:
eth0.5 + wlan0-1 unmanaged? (und IP wird im OLSR Setup angegeben)

Wenn Du vorhast, das eth0.5 und das wlan0-1 zu bridgen und darauf OLSR laufen lassen möchtest, heimst Du Dir ein typisches Bridge-Problem ein. Beim Edge-Router verhindern wir das durch Setzen von ebtables -P FORWARD DENY.

Auf OpenWRT würde ich das sein lassen und wie folgt vorgehen:
eth0.5 als OLSR-Interface festlegen
wlan0-1 als OLSR-Interface festlegen

wlan0-1 als Standalone AP ohne LAN-Interface irgendeiner Art definieren (OLSR sorgt selber für das Routing).

Der Nachteil dieser Lösung ist, dass Du für je eth0.5 und wlan0-1 eine Redeemer-IP brauchst.

Wenn Du jetzt fragen möchtest, warum wir dann die ebtables-Forward-Policy nicht über /etc/rc.local auf dem OpenWRT-Router setzen, ist die Antwort simpel: Dann funktionieren auch gewollte LAN-WLAN-Bridges nicht mehr.

Aber auch da gäbe es eine Lösung: man müsste eine ebtables-Regel anstatt einer Policy setzen und hoffen, dass sie zur Laufzeit dann auch greift.
Z.B., wenn Du eine Bridge br0 anlegtest, in der später wlan0-1 und eth0.5 liegen würden, wäre das:
ebtables -A FORWARD --logical-in br0 -i eth0.+ -j DROP
ebtables -A FORWARD --logical-in br0 -i wlan0-+ -j DROP

Ob das mit dem Joker „+“ funktioniert, musst Du bitte selber testen.

Die Regel würde das Forwarden von Paketen der einzelnen Bridge-Ports (hier wlan0-1 und eth0.5) über die Bridge und zwar untereinander verhindern. Die Brigde verarbeitet nur noch Input und Output der Bridgeports und ist gegenüber OLSR, das auf Layer 3 arbeitet, mit einer einzigen Redeemer-IP repräsentiert.

Gleiche Methode wird auch bei RouterOS auf MikroTik-Geräten angewendet. Und das schon bevor es EdgeRouter bei uns gab.

1 Like

Das mit dem Bedarf an Redeemer IP’s hab ich befürchtet und werde es deshalb nicht machen. Das mit der bridge würde mir besser gefallen, bin aber erst wieder nächsten Freitag in der Steiermark zum testen. Ebtables installiere ich immer standardmäßig mit, jenn mich aber nicht gut damit aus …

Noch eine Frage: ubiquiti Antenne haben ja den WDS modus (den hab ich im Moment auf der M2 abgedreht). Openwrt hat auch die Option Accesspoint und Client als „WDS“. Bringt WDS in diesem Zusammenhang etwas? Also CPE1 als WDS AP und CP2 als WPS client. Geht das OLSR drüber oder ist das nur ein Repeater mit dem Netz von CPE1?

WDS (wireless distribution system) ist ein nicht genormtes Verfahren, das aber unter OpenWRT und AirOS auf den 4-address-Mode zurückgreift.

Stell Dir das als Art NAT für die MAC-Adressen in einer WLAN-Bridge vor.
Wenn Du IPv6 nützen möchtest, wirst Du es jedenfalls benötigen, weil die MAC-Adresse für die Generierung der Linklokalen Adressen (LLA) vonnöten ist, aber die Linklokale Adresse auf dem LAN dann über das WLAN kein unmittelbarer Nachbar wäre.

Für OLSR auf IPv4 brauchst Du es in unserem Pseudobridge-Mode ebenfalls (außer der Nachbar ist OpenWRT wo OLSR direkt auf dem Interface läuft).

Noch ein Nachtrag:
Ich hatte natürlich zuerst versucht, die beiden mittels Ethernet zu verbinden [Es wäre darum gegangen auf 2 Seiten eines Hauses je eine Antenne zu montieren, ein Verlegung von Ethernet wurde dann aber abgelehnt]

M2 -> CPE1 -> eth0 -> unmanaged switch -> eth0 -> CPE2 ->

Dieses Setup hat merkwürdigerweise funktioniert, das 0XFF1 mit OLSR wurde dabei über eth0 gebridged und ich habe nur die Interfaces in eine gemeinsame 0xFF-Zone eingebunden (über luci). Auf jedem Gerät nur je 1 public IP. Am Samstag kann ich ja weiterkonfigurieren.

Das funktioniert deshalb, weil die beiden Ethernet-Interface je mit ihrer eigenen MAC-Adresse über die Bridge kommunizieren. Bei der Software-Bridge für das WLAN ist das nicht der Fall, weil eine MAC-Adresse des eth0 des Partners nie über die Bridge geht. (Ausnahme: OLSR läuft direkt auf dem betreffenden Gerät und spricht die Devices einzeln an.)

ein wenig weiter als vorige Woche, wollte mal prinzipiell testen, ob es überhaupt so geht:
(Problem ist auch, dass bestimmte Konfigurationen (manchmal) nur nach einem Reboot oder Entfernen vorhandener Interfaces funktioniert)
CPE1 mit 2 Interfaces 0xFF1 (wlan0) und 0xFF2 (wlan0-1), beide mit fixen public IP auf OLSR gelegt
Funk geht in beide Richtungen (als AP)
CPE2 mit 1 Interface 0xFF (wlan0) mit fixer IP und auf OLSR, Funk als Client.
->
CPE1 problemlos
CPE2 kriegt OLSR-Pakete und zeigt unter Luci auch gewohnten Status:

Network Interfaces 1
Neighbors 1
Nodes 310
HNA 184
Links total 1228
Links per node (average) 3.96

Soweit so gut, aber: es werden keine Routen importiert (es bleiben einzig die lokalen Routen …). wlan0 is in FW zone 0xFF, port 698 darf von jeder zone erreicht werden, ICMP auch. Public IP’s zwischen den Geräten sind nicht pingbar

Firewall:

config zone
option name ‚0xFF‘
option input ‚ACCEPT‘
option output ‚ACCEPT‘
option forward ‚ACCEPT‘
option mtu_fix ‚1‘
option network ‚0xFF‘
option masq ‚1‘
list device ‚wlan0‘

Denke dass da wieder mal ein Firewall Problem besteht (ICMP, 698, 1979 und 9090 sollten offen sein)
mit tcpdump kommt im Wesentlich folgendes (daher auch der positive Status, der 193.238.y.y. ist der „richtige“ Upstream Neighbor CPE1):
10:19:45.644498 IP 78.41.x.x.698 > 255.255.255.255.698: OLSRv4, seq 0xe5fb, length 32
10:19:45.683904 IP 193.238.y.y.698 > 255.255.255.255.698: OLSRv4, seq 0xd9aa, length 1144

Wo weitersuchen?

OK, in Ruhe nochmal aufgesetzt, mit fixen IP-Adressen geht es problemlos
Das mit der Bridge und ebtables muss ich noch testen …

Ich glaube ich muß um das mit der bridge zu verstehen eine Ebene tiefer ansetzen,
Ich habe bisher OLSR Verbindungen unter OpenWrt immer nur erfolgreich in folgender Art aufsetzen können:
Interface (z.b 0xFF) anlegen mit static address zugewiesener mit public IP
Olsr auf dieses Interface binden, evtl als MainIP nochmals obige statische IP
das hat immer funktioniert. Die Lösung des oben angegebenen Problems hat ja auch mit fixen IP`s funktioniert.

Wenn ich aber versuche 0xFF z.B. als „unmanaged“ anzulegen, gehen die Daten in der Regel durch, aber OLSR meist nur in eine Richtung. Ich habe port 698 immer in alle Richtungen zugelassen, ICMP, port 22 und 443 auch. Habe ich irgend welche Dienste da vergessen? Wahrscheinlich ist es immer noch ein Firewallproblem …
Merkwürdigerweise habe ich (zu mindest über Google) noch keine detaillierte Anweisung im Internet gefunden, die auf der oldwiki ist ja auch nicht mehr ganz aktuell (Netzmaske ? usw.).

Neues Setup ähnliches Problem:
Habe folgende Geräte (auf engstem Raum) aufgebaut, kann also weitgehend direkt darauf zugreifen:

  1. ER-X mit OLSR (IP 193.238.x.y)
  2. daran Nano Station M5 loco (als client)
  3. per Funk Nano Station 5AC loco als AP im Bridge modus, KEIN Router dahinter
  4. LiteBeam M-23 (als client)
  5. GL-AR300 als OLSR Router

Nach einigen Fehlschlägen (ohne edge Router ist das management schwierig, bei den AC-Modellen hat man aber 15 Minuten ein Managment Wlan zur Verfügung, das geht auch wenn man nicht auf das Management-VLAN zugreifen kann.
Aber immerhin, hab ich jetzt die UI 5AC Geräte kennengelernt.
In der Diskussion stand, dass bei so einem gebridgen Setup ohne Router in der Mitte, olsrd6 Probleme machen könnte. Pingen kann ich den ER-X nicht … [ping6: sendto: Permission denied]