[Berlin-wireless] Roaming mit OLSR?

[Bastian]

On 07/09/2016 11:12 AM, Smilie wrote:
> Was sagen die Experten?

Roaming wird überbewertet. Zumindest solange wir uns nicht auf ein
konkretes Szenario festlegen.

Die wenigen Usecases, in denen eine dauerhaft stehende TCP-Verbindung
beim Handover von einem AP zum nächsten (aka Roaming) nötig sind
rechtfertigen IMHO keine komplexen (=Stadtweiten) Setups. Der einzige
mir bekannte Anwendungsfall ist VoIP, und das wird aufgrund der stark
variierenden Latenzen in einem Mesh sowieso nicht soviel Spaß machen...

Sofern nicht alle APs zentral verwaltet werden müssen wir eigentlich
zwei Fälle unterscheiden:


Wechselt das default-GW (L2/L3) deines Clients/Smartphones?
Dein Client geht durch die Straße und wandert von einem AP zum nächsten.
Wegen der identischen SSID geht der Client von einem zusammenhängenden
Netz aus und erwartet weiterhin das default-GW unter der bekannten IP
und MAC zu erreichen.
Hier kommen so Sachen wie zentrale DHCP-Server und batman-adv oder /32
Client-IPs und macvlan ins Spiel.
And what about IPv6?

Wechselt das default-GW deines Uplinks aufgrund von Topology-Changes im
Mesh?
Dein Client merkt das nicht direkt, der Pfad ins Internet hat sich
geändert aber das default-GW deines Clients bleibt gleich. Am NAT-GW gen
Internet wird nun aber eine andere public IP verwendet und schon droppen
alle deine TCP-Connections. Aber bis auf SSH und VoIP stört das i.d.R.
nicht sonderlich.
Hier sollte source-specific Routing Abhilfe schaffen, aber das muss im
gesamten Mesh aktiv sein.


Und FYI, das Roaming verhalten der meisten Clients ist faktisch
unpraktisch. Da wird nicht einfach sofort zu dem AP verbunden der ein
besseres Signal hat. Die meisten Clients bevorzugen eine Verbindung zum
initial AP und nutzen diesen solange bis die Signal-Quality unbenutzbar
wird.
Hier hilft nur ein aktives triggern von Roaming durch den jeweiligen
AP/hostapd, der dann einfach den Client kickt wenn die
Verbindungsqualität unter einen gewissen Wert sinkt.

Cheers, Bastian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160709/2c9ec359/attachment.sig>