[Discuss] Hotspot und Mesh am selben Interface

[Erich N. Pekarek]

Hallo!

Am 2016-04-23 um 23:48 schrieb David Hopfmueller:
> On 04/23/2016 08:49 PM, Erich N. Pekarek wrote:
>> Am 2016-04-23 um 16:37 schrieb David Hopfmueller:
>>> On 04/23/2016 01:52 AM, Erich N. Pekarek wrote:
>
> Hi,
>
>>>> <https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf> 
>>>>
>>> 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.
>
> Doch, ein Routing-Protokoll braucht's schon, das wird nur nicht näher 
> spezifiziert: "Hence, the selection of a suited MANET routing protocol 
> is out of scope and presents future work."
Ja, genau das steht ja hier: Innerhalb des Konzepts (~ scope) ist es 
nicht vorgesehen.
Wir diskutieren ja gerade darüber, ob OLSR ein passendes Protokoll 
(suited MANET routing protocol) wäre, und, wie dieses konfiguriert 
werden müsste - ob RON-RON, RON-STAN oder RON-STA (letzteres tatsächlich 
ohne, da hier bei IPv4 NAT zur Anwendung käme und im Falle von IPv6 
vermutlich eine IPv6-native Prefix-Delegation mittels ra+assisted dhcp6)

>
> Auch eine Lösung für das Tracking der roamenden Clients für braucht 
> es: "Candidate solutions are proxy-based mobile IP variants or 
> end-to-end mobility signaling as employed in HIP".
In unserer Variante braucht es die nicht, da die einzigen nicht mit 
Routing-Protokoll arbeitenden Geräte dabei die STAs wären (nicht zu 
verwechseln mit den STANs, auf denen OLSR mit deren main ip läuft).

Alles andere liefe ja dergestalt nicht "proxy-based" ab.

>
> Zu Deinen nächsten zwei Kilometern ;-) :

:)

>
> Was die Autoren nicht klar spezifizieren, ich aber vermute, ist, dass 
> sie mehrere (virtuelle) APs pro RON verwenden: einen für das RON-Mesh 
> und einen für die STAs. Darauf deutet hin, dass sie einmal schreiben, 
> dass die ESSID immer gleich sein soll (Kapitel 3.3), weiter hinten in 
> Kapitel 3.4 heißt es hingegen, dass die ESSIDs der RONs unique sein 
> sollen, damit die RONs untereinander nicht automatisch roamen.
Ja, das versteht man auch erst nach mehrmaligem Lesen...

Deine Vermutung ist richtig, da sie explizit ath9k als Beispiel nennen. 
Dort funktioniert Multi-VAP mit der Einschränkung, dass je nach 
Chipsatz-Fähigkeiten nur eine beschränkte Anzahl von Modi möglich ist 
(iw info/iw list geben Auskunft darüber).

Man muss davon ausgehen, dass ja Teile der Funktion des Adhoc-Modes 
mittels Infrastruktur-Mode nachempfunden werden.
Während beim Adhoc-Netzwerk die BSSID das entscheidende Kriterium ist, 
ist es beim Infrastruktur-Modus die ESSID, die hier verkürzt als SSID 
vorkommt, während der Begriff "ESSID" gar nicht im Text vorkommt.

Zu 3.3 "STAN Mobility": Dieselbe ESSID im gesamten urbanen Funknetz 
ermöglicht das Roaming für die STANs. Lediglich die BSSID ("MAC of the 
wireless interface") wird "unique" gehalten.
Zu 3.4 "RON Mobility": Eine Empfehlung, es so zu machen kann ich zwar 
herauslesen, aber der Grund sind Routing-Probleme aufgrund der 
geänderten Netzwerktopologie, die ein MESH-Protokoll ja regelmäßig 
ausgleicht.
Zudem wären RONs bei uns bisher nicht mobil, sondern entsprächen den 
Knoten wie in meinen Beispielen aufgezeigt.
Man kann und soll aber darüber nachdenken, ob RON-Mobility erwünscht ist.


> Sollte das zutreffen, wäre die IP-Config wieder einfach und Nachteil 
> in der zusätzlichen SSID sehe ich eigentlich auch keinen.
Was zu testen wäre...
>
>>> 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:
>
> Die meisten Routing-Protokolle verwenden eine Router-ID, die zwar wie 
> eine IPv4 aussieht, aber keine sein muss, die dem Router zugeordnet 
> ist. Bei OLSR muss sie das offenbar sein, könnte aber auch die IP 
> eines Loopback-Interfaces sein. Damit wäre man dann unabhängig von 
> Interface-IP-Configs.
Exakt. Was bedeutet das für den Vorschlag? Siehst Du Probleme, die ich 
nicht zu erkennen vermag?
>
>> Annahme:
>> 1. Jede Station mit nur einem Multi-SSID-WLAN-Interface kann immer nur
>> mit einem einzigen AP gleichzeitig verbunden sein.
>
> Auch das stellen sich die Autoren anders vor, siehe Kapitel 2: "To 
> form the ad-hoc Wi-Fi backbone, each RON associates to APs of multiple 
> other RONs."
Du übersiehst, dass da nicht steht: "at the same time". Es ist das Wesen 
des Ath9k-Treibers und der frühen Chipsätze, dass das gewisse 
Kombinationen nicht zeitgleich möglich sind.

Ein Beispiel möglicher Konfigurationen von einem TL-WR1043NDv2 mit Chaos 
Calmer (iw list)
...
     valid interface combinations:
          * #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ 
P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
            total <= 2048, #channels <= 1, STA/AP BI must match
          * #{ WDS } <= 2048,
            total <= 2048, #channels <= 1, STA/AP BI must match
          * #{ IBSS, AP, mesh point } <= 1,
            total <= 1, #channels <= 1, STA/AP BI must match, radar 
detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }
...
Andere Router zeigen da auch andere Werte.
>
>> 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.
>
> Unter IPv6 wird das bei Link-local-Adressen ja durch Hinzuziehen des 
> Interface-Identifiers gelöst. Link-local-Adressen gibt's ja 
> grundsätzlich auch unter IPv4 und damit sollten mehrere Interfaces 
> denselben Range verwenden können. Ich habe aber meine Bedenken, dass 
> das zuverlässig funktioniert, insbesondere OS-übergreifend.
Ich würde ja sowieso nur mit v6 link local addresses auf den Interfaces 
arbeiten wollen - keep it simple. Solange router advertisements und 
neighbor discovery funktionieren, mache ich mir da keine Sorgen.

>
>> Wenn Du das sauber auseinander halten willst, dann ist MultiSSID in
>> jedem Fall der falsche Ansatz
>
> Einspruch: Wenn die Vorgabe (wie in dem Artikel) ein einzelnes Radio 
> ist, ist es IMHO die nächstbeste Lösung. Ansonsten bin ich natürlich 
> bei Dir, dass eine Trennung auf Layer 1 vorzuziehen ist.

Aber genau das diskutieren wir ja gerade - "saubere Lösung" versus 
nächstbeste oder "praktikable Lösung". Und bei letzterer geht es um die 
Rahmenbedingungen - aber deswegen wird die nächstebeste Lösung aber 
nicht "sauberer". Ein Trabi wird nicht auf Knopfdruck zum Ferrari.

>
>>> Ü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?
>
> Von "beschleunigend" hab ich nichts geschrieben, das Gegenteil ist der 
> Fall. "Wichtige Rolle" war vielleicht ungeschickt ausgedrückt, 
> "negativer Faktor" trifft's besser. Dieser Aspekt wird aber eben im 
> Artikel gar nicht beleuchtet. Das Optimierungspotential eines 
> WLAN-Controllers unter diesem Aspekt ist unter [1] ganz gut zusammen 
> gefasst.
>
Sorry, ... da hab ich wohl etwas hineingedichtet... trotzdem entsprechen 
WLAN-Controller und Enterprise-grade WiFi nicht unbedingt der Zielgruppe 
der STA- oder STAN-Betreiber und nur in wenigen Fällen denen, die RONs 
betreiben.

>> way. ... Access points do not have protocol operations that can
>> influence where clients attach to, and whether they will move or not./"
>
> Das ist richtig, allerdings steht einem AP frei, die Station 
> rauszukicken und einen Re-Join abzulehnen – was auch (wenn 
> konfiguriert) von aktuellen Lösungen so umgesetzt wird, um 
> Sticky-Clients zum Übersiedeln zu bewegen, wenn der AP/Controller der 
> Meinung ist, dass das von Vorteil ist.
MAC Access Control Lists auf dem AP und die Fixierung der Assoziierung 
beim Client auf nur eine BSSID tut es auch.
Die Frage ist, soll man das automatisieren? Wenn ja, mit welchen Parametern?
>
>>> 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.
>
> Ich bin ja auch nicht der Meinung, dass es die in MANETs braucht. Ich 
> sehe andererseits aber auch keine Notwendigkeit für 
> "unterbrechungsfreies" Client-Roaming.
Das ändert sich vielleicht, wenn man dazu übergehen sollte, MANETs auch 
im Auto o.ä. zu nützen - wobei das ein schlechtes Beispiel ist, wo sich 
WLAN im Auto gerade via LTE im Zusammenhang mit Serviceverträgen 
etabliert. Die Nutzungsszenarien ändern sich zwangsläufig, wenn man 
"konkurrenzfähig" bleiben will.
>
> Und von "Poor-man" schreiben sie selber eigentlich nicht. 
Richtig, das habe ich in Anlehnung an die Bezeichnung von parallelen 
oder seriellen Laplink-Kabeln als "Poor Man's LAN" so formuliert, das es 
mich irgendwie an früher erinnert.

> Ich hab das Gefühl, dass sie ihre Idee, sämtliche Mesh-Links plus 
> Clients eines RONs mit einem einzelnen Radio abzufackeln, für durchaus 
> chic halten, "weil's halt geht".
Das Paper evaluiert die Performance dieses Setups im Vergleich zum 
Adhoc-Mode. Von daher... gut so. Aber es geht auch anders ;-)
>
> CU,
> David
>
> [1] 802.11 WLAN Roaming and Fast-Secure Roaming on CUWN: 
> <http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html>
>
Danke für den Link!

LG
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/20160424/80c44106/attachment.vcf>