<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Vorsicht: Antwort in Romanlänge ;-)<br>
<br>
Am 2016-04-22 um 19:04 schrieb Mike B. Kerber:<br>
</div>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">On 2016-04-22 18:06, Matthias Šubik wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On 22.04.2016, at 17:59, Mike B. Kerber <a class="moz-txt-link-rfc2396E" href="mailto:michael.kerber@univie.ac.at"><michael.kerber@univie.ac.at></a> wrote:
On 2016-04-19 12:00, <a class="moz-txt-link-abbreviated" href="mailto:wien-request@lists.funkfeuer.at">wien-request@lists.funkfeuer.at</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Date: Mon, 18 Apr 2016 16:06:23 +0200
From: Matthias Šubik <a class="moz-txt-link-rfc2396E" href="mailto:funke@matthias.subik.de"><funke@matthias.subik.de></a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">[...]
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">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 ;)</pre>
</blockquote>
Man müsste folgende Konzept einmal im Detail nachbauen:<br>
<a
href="https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf"><a class="moz-txt-link-freetext" href="https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf">https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf</a></a><br>
<br>
Deren Mobile Adhoc Network im Infrastruktur-Modus, besteht aus:<br>
<ul>
<li>RONs (ROuter Nodes), die sowohl als Station als auch als AP
arbeiten und somit das Mesh bilden,</li>
<li>STANs (Station Nodes), also reine Clients eines AP, zum
Beispiel Smartphones.<br>
</li>
</ul>
RONs sollen untereinander ein MANET mit Hilfe eines nicht näher
bezeichneten Routingprotokolls bilden - das kann auch OLSR sein.<br>
Auf den AP-Interfaces der RONs soll je ein DHCP-Server oder
DHCP-Relay laufen, um lokale Clients, also STANs zu bedienen.<br>
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.<br>
<br>
Die Arbeit geht von APs und STAs auf virtuellen Interfaces,
beispielsweise durch ath9k implementiert, aus.<br>
<br>
Weiters thematisiert sie die Mobilität von sowohl STANs als auch
RONs:<br>
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 ("<i>MAC address of the gateway interface a STAN
communicates with.</i>")<br>
Die BSSID wird allerdings einzigartig gehalten ("<i>keep the MAC
address of the wireless interface of the RON unique</i>").
Dies dient der Vermeidung von DUPs (doppelt übermittelte Pakete von
benachbarten RONs).<br>
<br>
Problematisch ist in diesem Konzept die (Retour-)Route hin zu den
STANs. <br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">was eben da drauf läuft sollte man erkennen, wenn ich node.funkfeuer
sehe erwarte ich keinen hotspot ;)</pre>
</blockquote>
Wenden wir das Konzept theoretisch auf Knoten bei uns im Netz an und
denken das durch:<br>
<br>
Dann haben wir:<br>
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)<br>
RONs, die als Station an einem Root-Node angebunden sind und auf
demselben Kanal einen AP anbieten - zB etwa ein wo9 an brenner<br>
RONs, die als Station an einem anderen RON angebunden sind und auf
demselben Kanal einen AP anbieten - zB etwa kr3 an wo9.<br>
STAN: der Laptop von Sven am RON kr3.<br>
<br>
Nach dem Konzept von Wirtz et. al. würden die Root-Nodes und die
RONs je einen DHCP-Server oder ein Relay betreiben.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Das Konzept ergibt mangels rechtskonformer Multi-SSID-fähiger
Firmware auch nur auf 2.4-GHz Nodes mit OpenWRT Sinn.<br>
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.<br>
<br>
Besteht ein RON allerdings aus "abgesetzen Radios", wie in
vorangegangenen Diskussionen besprochen, spricht auch hier nichts
dagegen.<br>
<br>
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.<br>
Im Falle eines DHCP-Relays (SPoF?) kann eine im Portal hinterlegte
MAC-Adresse auch per DHCP zugewiesen werden.<br>
<br>
Bitte um Eure Anmerkungen zu den Überlegungen! Ich habe ziemlich
sicher etwas übersehen.<br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Wenn Du zeit hättest, und Multi-SSID testen könntest, wäre super. Ich probier auch mal Multi-SSID+WPA2Enterprise/Free nebeneinander.
</pre>
</blockquote>
<pre wrap="">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.</pre>
</blockquote>
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...<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.openwrt.org/doc/howto/clientmode#bridgedclientmodeissues">https://wiki.openwrt.org/doc/howto/clientmode#bridgedclientmodeissues</a><br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">
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).</pre>
</blockquote>
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.<br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">
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</pre>
</blockquote>
Sie oben.<br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">
geräte müssten dann halt über portforwards oder sowas angesprochen werden (zb zum remote configgern).</pre>
</blockquote>
Nicht zwangsläufig.<br>
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<pre wrap="">Daraus könnte man sogar einen kleinen sicherheitgewinn erzielen ;)</pre>
</blockquote>
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?
<blockquote cite="mid:571A59AE.30202@univie.ac.at" type="cite">
<blockquote type="cite">
<pre wrap="">bG
Matthias
</pre>
</blockquote>
<pre wrap="">mlg
-mike
[...]</pre>
</blockquote>
<br>
<br>
LG<br>
Erich<br>
</body>
</html>