<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2016-04-23 um 16:37 schrieb David Hopfmueller:<br>
</div>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">On
04/23/2016 01:52 AM, Erich N. Pekarek wrote:
<br>
<br>
Hi Erich,
<br>
<br>
<blockquote type="cite">Man müsste folgende Konzept einmal im
Detail nachbauen:
<br>
<a class="moz-txt-link-rfc2396E" 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>
<br>
</blockquote>
<br>
Ein guter Denkanstoß, aber nachbauen würd ich das nicht wollen.
<br>
</blockquote>
:) Vielleicht <i>noch</i> nicht.<br>
Aber leider werden auch die Antwort-Mails nicht kürzer ;-)<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
<br>
Die Anforderungen von Nachbar-Knoten und Clients in diesem Konzept
stehen einander diametral gegenüber: </blockquote>
Natürlich tun sie das: das Konzept ist ein Adhoc-Netzwerk Ersatz
ohne zusätzliches Routingprotokoll mit allen sich daraus ergebenden
Konsequenzen.<br>
Ich sehe darin eine Art Poor-Man's-Mesh, denn sauberer und
zuverlässiger ist immer noch die Lösung mit mehreren Devices.<br>
<br>
Allerdings halte ich die Widersprüche für auflösbar. Die Frage ist
nur - mit welchen Mitteln?<br>
<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">Auf
Interfaces zu anderen Knoten will OLSR eindeutige IPs, die Clients
sollen aber aber immer dieselbe verwenden können.</blockquote>
RFC 3626, definiert dafür die "main address" - aka Orginator IP -
hilf mir also bitte, das einmal durchzudenken:<br>
<pre style="font-size: 11pt; margin-bottom: 0">main address
The main address of a node, which will be used in OLSR control
traffic as the "originator address" of all messages emitted by
this node. It is the address of one of the OLSR interfaces of
the node.
A single OLSR interface node MUST use the address of its only
OLSR interface as the main address.
<b>A multiple OLSR interface node MUST choose one of its OLSR
interface addresses as its "main address" (equivalent of
"router ID" or "node identifier"). It is of no importance
which address is chosen, however a node SHOULD always use the
same address as its main address.</b></pre>
<br>
Annahme:<br>
1. Jede Station mit nur einem Multi-SSID-WLAN-Interface kann immer
nur mit einem einzigen AP gleichzeitig verbunden sein.<br>
2. Diese APs werden so gestaltet, dass der Client stets dieselbe
Routinginformation (unveränderte ARP-Tabelle hinsichtlich MAC und IP
der potentiellen Partner) für Outbound-Traffic/Uplink hat.<br>
<br>
Nebeneffekt von 2.:<br>
Auf den RONs würde sich ohne zusätzliches Routing-Protokoll das
Problem ergeben, dass die stets idente IP einerseits lokal vorhanden
ist, andererseits bei einem einen HOP entfernten Nachbarn - der
Traffic würde den Router gar nie verlassen.<br>
<br>
Hinzutreten von OLSR mit eindeutiger, sich nicht ändernder main ip:<br>
Jeder dieser Knoten mit multiplen OLSR-Schnittstellen, hat ja
zumindest eine eindeutige IP, die als Originator verwendet wird.<br>
Trägt bei Inbound-Traffic aber die Routinginformation als Absender
des Linkpartners die Originator-IP, müsste sohin die Anforderung an
die Eindeutigkeit erfüllt sein. Die Routing-Tabelle wird wegen der
von der Schnittstelleninformation abweichenden, umfassenderen
Broadcastadresse mit den externen IPs der Nachbarn bestückt. Die
uneindeutige Adresse des AP tritt in den Hintergrund, da der Traffic
an die eindeutige IP des Nachbarn laut dessen Main IP adressiert
wird.<br>
Die auf mehreren Routern quasiidente Schnittstellenadresse wird
somit von OLSR-Traffic gar nicht effektiv verwendet.<br>
(Bei Stations, die mittels NAT bedient werden, ist es nicht weiter
relevant, weil der Traffic ebenfalls über das eindeutig adressierte
Interface den Router verlässt.)<br>
<br>
Ob das mit dem Orginator-IP wie projektiert funktioniert, das muss
erst noch überprüft und getestet werden.<br>
<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
Ich teile Deine Einschätzung, Erich, dass der skizzierte Ansatz
zumindest in Verbindung mit OLSR mehr Probleme kreiert denn löst.</blockquote>
Das ist eine momentane Einschätzung aufgrund der obigen und
vorherigen Überlegungen, auch, da ich mir das mit OLSRv2 noch nicht
überlegt habe.<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
Multi-SSID + ein Overlay-Netz wären IMHO der richtige Ansatz, um
diese Anforderungen sauber in den Griff zu bekommen bzw.
auseinander zu halten.
<br>
</blockquote>
Wenn Du das sauber auseinander halten willst, dann ist MultiSSID in
jedem Fall der falsche Ansatz - schon wegen der Kanalidentität und
der Funktionsweise von RTS/CTS und CTS-to-self (Die ESSID spielt
nämlich dabei gerade keine Rolle, sondern nur die CTS-Aktivität auf
dem Kanal von beliebigen Wifi-Geräten in Reichweite). Mit MultiSSID
auf derselben Antenne bei derselben Ausrichtung vernichtest Du mit
RTS/CTS entweder jede Menge Airtime, die aufgrund von MultiSSID
schon auf dem Gerät selbst rationiert ist oder, Du nimmst
Übersprechen in Kauf, womit es zu häufigeren Resends und sinkenden
Datenraten kommt.<br>
<br>
Wirklich "sauber" können nur pro Link dedizierte Geräte oder
Schnittstellen mit möglichst fokussiertem Beam auf
überlappungsfreien Kanälen je sein.<br>
Alles andere ist ein Kompromiss zwischen Kosten und Performance.<br>
<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">Übrigens
nicht einmal erwähnt wird die Authentifizierung, die beim
(schnellen) Roaming eine wichtige Rolle spielt – Verschlüsselung
kann man ja auch bei einem MANET-Hotspot wollen.
<br>
</blockquote>
Erläutere das bitte: Wieso soll Authentifizierung beim Roaming eine
beschleunigende eine Rolle spielen?<br>
<br>
Ich blättere gerade in Matthew S. Gast, "802.11 Wireless Networks -
The Definitive Guide²", um für diese Behauptung eine Grundlage zu
finden:<br>
<br>
S 10 gibt einen Überblick über Arbeitgruppen wie 802.11F, 802.11r.<br>
<br>
S 182 widmet sich u.a. 802.11i und Key Caching:<br>
"<i>Preauthentication makes roaming a smoother operation because
authentication can take place before it is needed to support an
association.</i>"<br>
<br>
S 183:<br>
"<i>Station software is in control of roaming behavior, and can use
that to its advantage. As the station moves in such a way that AP2
appears to be a better choice, it can perform preauthentication to
speed up the process of moving over to AP2. Rather than move
everything all at once, though, it performs preauthentication to
cut down on the interruption between sending network packets.</i>"<br>
<br>
Auf Seite 349 und 350 finde ich:<br>
"<i>802.11 places no constraints on how a client device makes its
decision on how to move between APs, and does not allow for any
straightforward way for the AP to influence the decision. ...
[350:] Roaming in 802.11 is entirely driven by client decisions.
Where to send the Association Request frames is entirely in the
hands of the client system’s driver and firmware, and is not
constrained by the 802.11 specification in any way. ... Access
points do not have protocol operations that can influence where
clients attach to, and whether they will move or not.</i>"<br>
<br>
In "802.11n - A survival Guide" finde ich auf Anhieb nichts, was dem
widerspricht.<br>
Fazit: Roamingentscheidungen treffen Stations autonom, meist
aufgrund der SNR, wobei das "big light syndrom" auftreten kann -
Stations "kleben" an einem AP, bis fast gar kein Signal mehr über
dem Rauschen liegt. Der Schlüsseltausch kann durch Roamingeffekte
forciert werden - absichtlich oder als Nebeneffekt.<br>
Authentifzierung ist langsam, OPC Key Caching und 802.11i
Preauthentication können dies jedoch beschleunigen. Zum Stand der
Entwicklung hinsichtlich 802.11r bin ich nicht auf dem Laufenden.<br>
<br>
Auf den Seiten 426 und 427 finde ich hingegen eine Bestätigung für
die Beschleunigung des Roamings im Ansatz von Wirtz:<br>
"<i>The best way to ensure interoperability between vendors is to
select a system that bases roaming and handoff on dynamic VLAN
assignment. As stations authenticate, they will retain the same
logical point of attachment to the network.</i>"<br>
"<i>Effective roaming requires transparent bridged access, not</i><i>
</i><i>routed access, to the link layer at different physical
locations. However, roaming</i><i> </i><i>with 802.11 is possible
only when access points can communicate with each other to</i><i>
</i><i>track the movement of a wireless station.</i>"<br>
Deren Trick umschifft ja Notwenigkeit genau dafür.<br>
<br>
Wie Du vielleicht weißt, bin ich selbst Kritiker des
unverschlüsselten WLANs, verzeih also bitte, wenn ich nun mit
Gegenargumenten komme.<br>
Die Auswirkungen für Hotspots wären, sofern nicht getunnelt oder
Ende-zu-Ende-verschlüsselt wird, dass man insgesamt drei SSIDs
benötigte:<br>
Station (WPA2-PSK)*, AP(WPA2-PSK)*, Hotspot-AP (eventuell nach IEEE
802.1X), was wieder auf die Performance schlägt und die geforderte
Einfachheit unterwanderte.<br>
*: Weil Radius ja zuvor die Verbindung zum Radius-Server erfordern
würde, aber das vom selben Linknet abhängt...<br>
<br>
Die Zeit für Association und Deassociation im unverschlüsselten Netz
muss jedenfalls geringer sein, da weniger Routinen durchlaufen
werden.<br>
<br>
Ich wäre dankbar, wenn Du mir die Hintergründe erklären könntest
oder mir Literatur nennen würdest, die dies kann.<br>
<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
<br>
Beide Punkte (Overlay und Authentifizierung) lassen sich durch
WLAN-Controller lösen.</blockquote>
Die es im Netz nur punktuell gibt (z.T. noch eine Kostenfrage). Der
gegenständliche Artikel soll ja Vor- und Nachteile des
Poor-Man's-Mesh thematisieren, nicht zum Kauf von Enterprise grade
Hardware motivieren.<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
Das geht auf Kosten der Dezentralität – man muss sich halt
entscheiden, was einem wichtiger ist. Allerdings ist die
Fragestellung in Bezug auf 0xFF ohnehin rein akademisch, da
Client-Roaming bei der derzeitigen Knoten-Dichte kein Thema ist.
<br>
</blockquote>
Dezentralität im 0xFF-Netz? - der war gut :-) - unter technischen
wie sozialen Aspekten.<br>
<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
<br>
Insofern ist eine separate SSID mit eigener IPv4 + NAT bzw. einem
zusätzlichen IPv6-Prefix auf absehbare Zeit IMHO die einfachste
und sauberste Lösung, um Clients anzubinden.
<br>
</blockquote>
Auch die geht freilich auf die Performance. Die einfachste und
sauberste Lösung sind multiple Geräte, nicht bloß multiple SSIDs.
Als Interimslösung sind sie zulässig und notwendig. Die diskutierten
Ansätze sind nicht grundverschieden - nur dass der eine Ansatz
sparsam mit IPs umgeht und der andere eventuell nicht den
umfassenden Anforderungen an die Netzneutralität hinsichtlich IPv4
entspricht.<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">
<br>
Danke jedenfalls für den Input! Das Thema Hotspot soll auch im
Rahmen des v642-Projekts wiederbelebt werden, da werden sich diese
Fragen sicher stellen.
<br>
<br>
</blockquote>
Ich bin sicher, dass jeder der Ansätze Teile zur besten Lösung in
sich trägt. Das Thema Hotspot sollte man jedoch mit Skepsis
betrachten, aber auch als Chance sehen. Funknetze, wie wir sie
bisher kennen, sind ja EOL ;-)<br>
<blockquote cite="mid:571B88BE.3020203@hopfmueller.at" type="cite">CU,
<br>
David
<br>
<br>
</blockquote>
LG<br>
Erich<br>
</body>
</html>