[Wien] Master-Client, Alternative links -

[Erich N. Pekarek]

Hallo!

Vorsicht: Antwort in Romanlänge ;-)

Am 2016-04-22 um 19:04 schrieb Mike B. Kerber:
> On 2016-04-22 18:06, Matthias Šubik wrote:
>>> On 22.04.2016, at 17:59, Mike B. Kerber <(spam-protected)> wrote:
>>>
>>> On 2016-04-19 12:00, (spam-protected) wrote:
>>>> Date: Mon, 18 Apr 2016 16:06:23 +0200
>>>> From: Matthias Šubik <(spam-protected)>
>> ...
>>>> [...]
>>> Das wäre in der Tat super. Ich würde mal vorschlagen bei knoten mit
>>> Master-Client layout auf jenen clients die multi SSID können einfach
>>> einen AP zu machen, dass man sie scannen kann. ich vermute ich könnte so
>>> manchen möglichen partner sehen, wenn der ein SSID ausstrahlen würde.
>>> Das wäre es natürlich super, wenn es dazu eine convention gäbe wie
>>> noolsr-client.node.funkfeuer.at oder so, damit man weiss das das kein
>>> MESH ist und wo zzt kein olsr (aufgrund von technischen details) läuft.
>> Das ist ja machbar, aber warum glaubst Du dass dann dort kein olsrd läuft?
>> Im Standardfall läuft der ja auf allen Interfaces, d.h. wenn ein AP eine zweite SSID ausstrahlt, kann da problemlos auch olsrd laufen.
> Ja aber dann brauchen alle diese interfaces eine ip, bei ipv4 ist das
> ein bissi verschwenderisch wenn das nach bedarf geht.
> Ipv6 olsr kann man aber anmachen gibts ja mehr IPs ;)
Man müsste folgende Konzept einmal im Detail nachbauen:
https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf

Deren Mobile Adhoc Network im Infrastruktur-Modus, besteht aus:

  * RONs (ROuter Nodes), die sowohl als Station als auch als AP arbeiten
    und somit das Mesh bilden,
  * STANs (Station Nodes), also reine Clients eines AP, zum Beispiel
    Smartphones.

RONs sollen untereinander ein MANET mit Hilfe eines nicht näher 
bezeichneten Routingprotokolls bilden - das kann auch OLSR sein.
Auf den AP-Interfaces der RONs soll je ein DHCP-Server oder DHCP-Relay 
laufen, um lokale Clients, also STANs zu bedienen.
Zudem sollen sie als DNS-Resolver gegenüber den STANs laufen. Nach 
diesem Konzept sollen RONs die Gateways für die STANs sein, vorzugsweise 
mit eigenen IP-Assignments. STANs sollen demnach vom komplexen Routing 
dahinter nichts wissen müssen.

Die Arbeit geht von APs und STAs auf virtuellen Interfaces, 
beispielsweise durch ath9k implementiert, aus.

Weiters thematisiert sie die Mobilität von sowohl STANs als auch RONs:
Um mobilitätsbedingten Routingproblemen (Layer 2 und Layer 3) und 
Zeitverzögerungen durch ARP im Falle eines Handover eines STANs auf 
einen anderen RON zu begegnen, lassen Wirtz et. al. jeden RON dasselbe 
Netzwerk bereitstellen. D.h. die APs strahlen dieselbe SSID aus, sind 
auf dieselbe IP konfiguriert und nutzen dieselbe (Fake-) MAC-Adresse 
("/MAC  address  of  the  gateway  interface  a  STAN communicates  with./")
Die BSSID wird allerdings einzigartig gehalten ("/keep  the  MAC 
address  of  the  wireless  interface of the RON unique/"). Dies dient 
der Vermeidung von DUPs (doppelt übermittelte Pakete von benachbarten RONs).

Problematisch ist in diesem Konzept die (Retour-)Route hin zu den STANs.

Auf die Mobilität von RONs wird insoweit eingegangen, als sie zwar 
vorgesehen ist, jedoch wegen Änderungen der Netzwerktopologie davon 
abgeraten wird, sie großzügig zu nutzen. D.h. RONs würden, wie auch 
bisher bei uns, einzigartige ESSIDs nutzen.


>> Wenn wir jetzt einen Master-AP auf einem node starten, und der heisst FunkFeuer.at Hotspot, dann erwartet man sich da natürlich DHCP+NATv4.
> was eben da drauf läuft sollte man erkennen, wenn ich node.funkfeuer
> sehe erwarte ich keinen hotspot ;)
Wenden wir das Konzept theoretisch auf Knoten bei uns im Netz an und 
denken das durch:

Dann haben wir:
Root-Nodes, die nur als AP fungieren und via Tunnel angebunden sind - 
auf ihnen läuft ein AP-Interface und OLSR (z.B.: Krypta, Brenner)
RONs, die als Station an einem Root-Node angebunden sind und auf 
demselben Kanal einen AP anbieten - zB etwa ein wo9 an brenner
RONs, die als Station an einem anderen RON angebunden sind und auf 
demselben Kanal einen AP anbieten - zB etwa kr3 an wo9.
STAN: der Laptop von Sven am RON kr3.

Nach dem Konzept von Wirtz et. al. würden die Root-Nodes und die RONs je 
einen DHCP-Server oder ein Relay betreiben.
Da unser Netz mit statischen, öffentlichen IPs und Prefixes arbeitet, 
sollte das kein Problem sein - DHCP mit einem internen Range würde die 
STANs bedienen. Die anderen RONs haben ja statische IPs, womit es kein 
Problem gibt. Sofern NAT auf den RONs läuft, müsste es sich auf die 
internen IP-Ranges (RFC1918), sofern APIPA genutzt wird, auf RFC 3927 
beschränken, damit OLSR-Pakete und geroutete Pakete nicht genattet werden.

Wichtig ist, in diesem Konzept, dass die RONs ja eine idente MAC-Adresse 
und IP verwenden. Damit RONs an RONs über OLSR routen, müssen diese 
Interfaces auch OLSR sprechen. Dazu müsste eine einzige (offizielle) 
Adresse mehrfach (per Anycast) angekündigt werden. Habe ich hier einen 
Denkfehler eingebaut? Wenn nicht, ist OLSR wie immer pro Interface 
(sonstige Interfacekonfiguration ohne Bridge-Support und mit 
AP-Isolation) zu konfigurieren. Der Spareffekt ist so ganz ohne Bridging 
auch gegeben.

Im Ergebnis solle es - organisatorischen Aufwand zur Verhinderung von 
Missbrauch in der Art, dass RONs mit internen, oder doppelt vergebenen 
internen IPs einsickern - möglich sein, mit nur einem AP also nur einer 
ESSID beide Dienste zu betreiben. Ich sehe das aber selbst noch kritisch 
und würde eine Variante mit Portal Auth bevorzugen.

Man muss sich auch bewusst sein, dass die Mitbenutzung eines Kanals 
altbekannte Airtime-Probleme insbesondere mit RTS/CTS und CTS-Flooding 
bewirken kann. Man sollte auch bedenken, dass man sich mit den STANs und 
mobile STANs etwaige Hidden Station Probleme importiert.

Das Konzept ergibt mangels rechtskonformer Multi-SSID-fähiger Firmware 
auch nur auf 2.4-GHz Nodes mit OpenWRT Sinn.
Auf 5 GHz löst es jedenfalls keine Probleme - insbesondere bei langen 
RON-RON-Ketten und DFS/TPC würde ein Kanalwechsel mit jeweils auf 
demselben Kanal operierenden Routerketten einen Kaskadeneffekt mit 
entsprechenden, womöglich wellenartig auftretenden Performanceproblemen 
auslösen.

Besteht ein RON allerdings aus "abgesetzen Radios", wie in 
vorangegangenen Diskussionen besprochen, spricht auch hier nichts dagegen.

Ein Vorteil dieses Setups könnte eine Auto-Config sein, da ein RON vor 
Erhalt seiner Konfiguration und noch bevor OLSR läuft, bereits am Netz 
teilnehmen kann.
Im Falle eines DHCP-Relays (SPoF?) kann eine im Portal hinterlegte 
MAC-Adresse auch per DHCP zugewiesen werden.

Bitte um Eure Anmerkungen zu den Überlegungen! Ich habe ziemlich sicher 
etwas übersehen.
>> Wenn Du zeit hättest, und Multi-SSID testen könntest, wäre super. Ich probier auch mal Multi-SSID+WPA2Enterprise/Free nebeneinander.
> Auf meinen Knoten läuft eben ein AP parallel zum client. Um ips zu
> sparen haben ich versucht die interfaces zu bridgen, das geht in openwrt
> mal nicht direkt, mit relayd wird der Knoten im olsr umgangen aber es geht.
Im Wlan-Frame ist die MAC-Adresse (Layer 2) des pseudo-gebridgten 
Interfaces nicht vorhanden, es sei denn, man nützt WDS, weil dabei die 
Mac-Adresse des Senders (Ethernet), bei von dort stammenden Paketen, in 
den WLAN-Frame als Absender eingebaut wird. WDS muss aber auf beiden 
Seiten unterstützt werden, damit es wirklich klappt [Access Point (WDS) 
und Client (WDS)]; darauf hast Du nicht immer Einfluss...

https://wiki.openwrt.org/doc/howto/clientmode#bridgedclientmodeissues
> Schöner wäre es pro Gerät eine IP zu haben und die interfaces zusammen zu bringen. Es gibt dazu mails im Archiv mit Erich (Siehe Next gen. node).
Das ist alles "WIP", nur ohne Progress, weil ich nicht mehr dazu 
gekommen bin, nachdem ich mich mit dem 
WRT54G/GL-mit-0xFF-FW-kann-nicht-mit-Atheros-AP-assoziieren-Problem 
sinnlos aufgehalten habe.
>
> Bei einem grösseren Knoten mit einem backbine router könnte man die Interfaces jedes geräts auf den backbone router durch bridgen und nur dort läuft dann mit einer OLSRD originator IP ein olsr. die einzelnen
Sie oben.
> geräte müssten dann halt über portforwards oder  sowas angesprochen werden (zb zum remote configgern).
Nicht zwangsläufig.
> Daraus könnte man sogar einen kleinen sicherheitgewinn erzielen ;)
In welcher Hinsicht? Beim "abgesetzten Radio" stellt sich die Frage 
nicht, und Remote Configuration and Information ist in gewisser Weise 
Basis dieser Netzkultur. Portforwards für sich allein genommen, sind SbO 
und der vermittelnde Router ist SPoF. Oder?
>> bG
>> Matthias
> mlg
> -mike
> [...]


LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20160423/5263fec0/attachment.htm>
-------------- 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/wien/attachments/20160423/5263fec0/attachment.vcf>