[Discuss] Hotspot und Mesh am selben Interface

[Erich N. Pekarek]

Hallo!

Am 2016-04-23 um 16:37 schrieb David Hopfmueller:
> On 04/23/2016 01:52 AM, Erich N. Pekarek wrote:
>
> Hi Erich,
>
>> Man müsste folgende Konzept einmal im Detail nachbauen:
>> <https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf> 
>>
>
> Ein guter Denkanstoß, aber nachbauen würd ich das nicht wollen.
:) Vielleicht /noch/ nicht.
Aber leider werden auch die Antwort-Mails nicht kürzer ;-)
>
> Die Anforderungen von Nachbar-Knoten und Clients in diesem Konzept 
> stehen einander diametral gegenüber: 
Natürlich tun sie das: das Konzept ist ein Adhoc-Netzwerk Ersatz ohne 
zusätzliches Routingprotokoll mit allen sich daraus ergebenden Konsequenzen.
Ich sehe darin eine Art Poor-Man's-Mesh, denn sauberer und zuverlässiger 
ist immer noch die Lösung mit mehreren Devices.

Allerdings halte ich die Widersprüche für auflösbar. Die Frage ist nur - 
mit welchen Mitteln?

> Auf Interfaces zu anderen Knoten will OLSR eindeutige IPs, die Clients 
> sollen aber aber immer dieselbe verwenden können.
RFC 3626, definiert dafür die "main address" - aka Orginator IP - hilf 
mir also bitte, das einmal durchzudenken:

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.

          *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.*


Annahme:
1. Jede Station mit nur einem Multi-SSID-WLAN-Interface kann immer nur 
mit einem einzigen AP gleichzeitig verbunden sein.
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.

Nebeneffekt von 2.:
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.

Hinzutreten von OLSR mit eindeutiger, sich nicht ändernder main ip:
Jeder dieser Knoten mit multiplen OLSR-Schnittstellen, hat ja zumindest 
eine eindeutige IP, die als Originator verwendet wird.
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.
Die auf mehreren Routern quasiidente Schnittstellenadresse wird somit 
von OLSR-Traffic gar nicht effektiv verwendet.
(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.)

Ob das mit dem Orginator-IP wie projektiert funktioniert, das muss erst 
noch überprüft und getestet werden.

> Ich teile Deine Einschätzung, Erich, dass der skizzierte Ansatz 
> zumindest in Verbindung mit OLSR mehr Probleme kreiert denn löst.
Das ist eine momentane Einschätzung aufgrund der obigen und vorherigen 
Überlegungen, auch, da ich mir das mit OLSRv2 noch nicht überlegt habe.
> Multi-SSID + ein Overlay-Netz wären IMHO der richtige Ansatz, um diese 
> Anforderungen sauber in den Griff zu bekommen bzw. auseinander zu halten.
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.

Wirklich "sauber" können nur pro Link dedizierte Geräte oder 
Schnittstellen mit möglichst fokussiertem Beam auf überlappungsfreien 
Kanälen je sein.
Alles andere ist ein Kompromiss zwischen Kosten und Performance.

> Ü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.
Erläutere das bitte: Wieso soll Authentifizierung beim Roaming eine 
beschleunigende eine Rolle spielen?

Ich blättere gerade in Matthew S. Gast, "802.11 Wireless Networks - The 
Definitive Guide²", um für diese Behauptung eine Grundlage zu finden:

S 10 gibt einen Überblick über Arbeitgruppen wie 802.11F, 802.11r.

S 182 widmet sich u.a. 802.11i und Key Caching:
"/Preauthentication makes roaming a smoother operation because 
authentication can take place before it is needed to support an 
association./"

S 183:
"/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./"

Auf Seite 349 und 350 finde ich:
"/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./"

In "802.11n - A survival Guide" finde ich auf Anhieb nichts, was dem 
widerspricht.
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.
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.

Auf den Seiten 426 und 427 finde ich hingegen eine Bestätigung für die 
Beschleunigung des Roamings im Ansatz von Wirtz:
"/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./"
"/Effective roaming requires transparent bridged access, not////routed 
access, to the link layer at different physical locations. However, 
roaming////with 802.11 is possible only when access points can 
communicate with each other to////track the movement of a wireless 
station./"
Deren Trick umschifft ja Notwenigkeit genau dafür.

Wie Du vielleicht weißt, bin ich selbst Kritiker des unverschlüsselten 
WLANs, verzeih also bitte, wenn ich nun mit Gegenargumenten komme.
Die Auswirkungen für Hotspots wären, sofern nicht getunnelt oder 
Ende-zu-Ende-verschlüsselt wird, dass man insgesamt drei SSIDs benötigte:
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.
*: Weil Radius ja zuvor die Verbindung zum Radius-Server erfordern 
würde, aber das vom selben Linknet abhängt...

Die Zeit für Association und Deassociation im unverschlüsselten Netz 
muss jedenfalls geringer sein, da weniger Routinen durchlaufen werden.

Ich wäre dankbar, wenn Du mir die Hintergründe erklären könntest oder 
mir Literatur nennen würdest, die dies kann.

>
> Beide Punkte (Overlay und Authentifizierung) lassen sich durch 
> WLAN-Controller lösen.
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.
> 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.
Dezentralität im 0xFF-Netz? - der war gut :-) - unter technischen wie 
sozialen Aspekten.

>
> 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.
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.
>
> 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.
>
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 ;-)
> CU,
> David
>
LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160423/ec25e0d7/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/discuss/attachments/20160423/ec25e0d7/attachment.vcf>