[Discuss] Aktuelle Outdoor-Hardware

[Erich N. Pekarek]

Hallo!

Am 2016-04-07 um 21:46 schrieb David Hopfmueller:
> On 04/07/2016 01:33 AM, Erich N. Pekarek wrote:
>> Am 2016-04-06 um 23:30 schrieb David Hopfmueller:
> >> On 04/06/2016 12:44 PM, Erich N. Pekarek wrote:
>
> Hi,
>
>>> Wiese muss es ein separates VLAN pro Antenne sein?
>> Weil die einzelnen "Antennen" -also Router- im Bridging-Mode nur eine
>> interne IP für Wartungszwecke nützen, und sich sonst wie ein L2-Switch
>> gerieren.
>
> ACK, macht Sinn, wenn Du davon ausgehst, dass die Antennen ansonsten 
> über einen Switch verbunden wären.
Die APs selbst sind in diesem Modus die Brigde. Freilich kann man den 
Port des SME-Switches auch zur Weiterleitung über den/die Trunk-Ports 
nützen - oder aber des läuft auf dem SME-Switch direkt ein OLSR. Die 
Wartungs-IP dient nur für die Smart Managed-Funktionen und Monitoring.

> Vielleicht ist das beim typischen OpenWRT-Gerät Standard.
Wohl bei jedem Home-WLAN-Router, aber darum geht's nicht, oder?

> Andernorts wird halt üblicherweise bei Routern die IP auf dem 
> Interface konfigurierst und man muss extra Aufwand treiben, wenn man 
> sie bridgen wills.
OpenWRT bridgt mittels hostapd/wpad im Normalfall (default) das AP-Netz 
auf das LAN. Nur für die OLSR-Interfaces schalten wir das ja bisher 
extra ab.
Ansonsten: brctl.
>
>> Würden alle
>> WLAN-Bridges am selben L2-Switch hängen, sind manche Router über mehrere
>> Routen erreichbar.
>
> Aus meiner Sicht wäre das Problem, dass eine große Broadcast-Domain 
> entstünde, die man schon mal prinzipiell nicht will.
Sehr richtig.
> Innerhalb derer wären alle Knoten direkte Nachbarn, was schon gar 
> nicht Sinn der Sache ist.
Darum geht's.
> Vielleicht meinen wir eh dasselbe.
In diesem Punkt bestimmt.
>
>>>> Ein Vorteil dieses Konzepts besteht in der Einsparung der 
>>>> WLAN-seitigen
>>>> (v4) IPs
> […]
>>> Macht derzeit Sinn, wäre aber mit IPv6 kein Kriterium mehr.
>> Verwechsle nicht Ursache mit Nebenwirkung
>
> Ich bin nur auf Dein Argument eingegangen. Ich finde aber, dass wir an 
> den wesentlichen Punkten vorbei reden: Das Hauptproblem sehe ich 
> darin, dass eine zusätzlich OLSR-Instanz auf jeder Antenne unnötig 
> viel zusätzlichen Aufwand in Form von Konfiguration, benötigter 
> Rechenleistung und Fehlerquellen bedeutet und im übrigen die Topologie 
> unnötig aufbläst. 
Da sind wir uns einig. Das war der bisherige Ansatz, der auf 
OLSRv1-Perspektive sinnvoll ist.
Das mit dem VLAN ist eine Zwischenlösung, die Standardhardware bei 
Antennenroutern ohne Firmware-Mod erlaubt: Standard-Hardware sohin 
vielseitig einsetzbar.
> Und das alles vermutlich nur deshalb, weil man halt a) abgesetzte 
> Antennen und b) möglichst genaue Metriken wollte.
Vor allem wollte "man" keine Routing-Loops und die Möglichkeit, mittels 
LQ-Multiplikatoren korrigierend einzugreifen.
>
>>> Was aus meiner Sicht derzeit fehlt, ist eine abgesetzte Antenne auf
>>> offener Basis.
>> ???
>
> Adi hat das eh schon zusammen gefasst. Ist recht genau in einem auch 
> hier mal erwähnten Paper von (Co-Autor) Henning beschrieben [1].
"abgesetzt" klingt nur "strange".
>
>> Zurück zu Mikrotik-RB mit wechselbaren Modulen?
>> Soekris?
>> Banana PI Pro/ Orange Pi 2 Pro POE-modden?
>
> Die haben alle das Problem der "zentralisierten" WLAN-Schnittstellen. 
> Darüber ist man IMHO hinweg.
--verbose
>
>> USB-WLAN-Sticks
>
> Könnte eine Möglichkeit sein. Mir fällt als Nachteil ad hoc nur die 
> recht begrenzte Leitungslänge ein. Wie sieht das aus 
> Treiber-/Performance-Sicht aus? Weiß da jemand Genaueres?
Ich denke da eine Kombination aus Beidem... PI oder ähnlich in Box und 
Sticks via USB.
Siehe auch: http://www.brennpunkt-srl.de/Grid4StickAntenne.html

Die Regulierung der Sendeleistung wäre eben wichtig, um in der Bauart 
legal zu bleiben.
>
> CU,
> David
>
> [1] Christoph Barz et al.: OLSRv2 for Community Networks: Using 
> Directional Airtime Metric with external radios
>
SG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : erich.vcf
Dateityp    : text/x-vcard
Dateigröße  : 4 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160407/0a675d4d/attachment.vcf>