Re: [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

<<attachment: erich.vcf>>-- 
Discuss mailing list
Discuss@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/discuss