IEEE 802.11s und das Hybrid Wireless Mesh Protocol

Da in den letzten Tagen vermehrt das Stichwort 802.11s fiel, habe ich mir zumindest mal ein paar Artikel durchgelesen. Wenn ich alles richtig verstanden habe, kommt dieser Industrie-Meshing-Standard mit seinem eigenen Protokoll, dem Hybrid Wireless Mesh Protocol.

Gibt es hier irgendwelche Potentiale für Freifunk? Ich denke da so in die Richtung breitere Hardwareauswahl weil Industriestandard. Ist HWMP in irgendeiner Form ein Kandidat, der B.A.T.M.A.N. und OLSR ablösen könnte?

Was ist euere Meinung dazu?

Man kann 802.11s auf mehrere Arten für Freifunk nutzen:

  • Wenn man das Forwarding deaktiviert ist das praktisch ein Ad-Hoc-Ersatz. Das Feature kommt mit Gluon 2015.2.
  • Man kann es auch als batman-adv-Ersatz verwenden. Dann muss man den DHCP Gatewaymodus allerdings irgendwie selbst implementieren, aber sowas ist ja auch schon in der Entwicklung.
  • Man kann es als „Meshwolken“-Protokoll in einem größeren Layer3 nutzen.
  • Diese Liste ist nicht abschließend. Gibt bestimmt noch viele andere sinnvolle Einsatzgebiete. Was mit 11s nicht geht ist es über VPN oder auch mehrere WLAN Interfaces zu sprechen. Da muss man dann bridgen.

Ich verweise mal auf die Berliner Liste zu möglichen Vorteilen. Sofern ich das richtig verstanden habe, setzt man in Berlin aber derzeit zur Teile der Möglichkeiten ein (Hervorhebung von mir)?

Falls niemand Einwände hat, sollten wir uns bei der mesh_id auf „freifunk“ einigen. Ansonsten ist nur wirklich wichtig, das eingebaute 802.11s Mesh-Forwarding mit „mesh_fwding 0“ zu deaktivieren. Der Rest der Config kann je Router unterschiedlich sein und sollte sich an die bisherige adhoc Konfiguration anlehnen.

Mir ist leider noch nicht klar geworden, was ein Mesh-Point (MP) ist bzw. wie aus einem MP ein Mesh-Access-Point (MAP) wird; in der Gluon-Welt ist ja normalerweise (außer: AP-Modus deaktiviert) jeder Knoten auch Access-Point.

Zu HWMP, soweit ich das verstanden habe, ist das ähnlich wie batman_adv, leitet Pakete auf MAC-Ebene weiter. Was mich allersdings wenig hoffnungsfroh stimmt, sind so Aussagen wie diese:

Als typische Größe eines Mesh-WLANs nimmt 802.11s 32 Mesh-(Access)-Points an, doch das ist keine absolute Grenze.

Auch ist mir unklar, wie sich der Einsatz von 802.11s im Gluon-Kontext auswirken wird. Können dann verschiedene Uplinks im Mesh noch genutzt werden? Muß, anders als heute, der Ausbau geplant werden?

Aber, wie die Kollegen in Berlin schon schrieben:

Wir treten mit Adhoc/IBSS ein inzwischen ziemlich totes Pferd obwohl wir damit nicht wirklich vorwärts kommen. Der momentane Fortschritt und die Weiterentwicklung in Sachen Wireless-Mesh setzt auf 802.11s.

Schon daher wäre der Wechsel von Ad-Hoc zu 802.11s interessant, ob das dann die Hardwareauswahl wirklich erhöht, steht auf einem anderen Blatt. (Implementierter Standard bedeutet ja nicht zwingend auch stabile Funktion ;))

1 Like

Wie gesagt: Erstmal ist das als 1:1 Ersatz für Ad-Hoc gedacht und verhält sich auch exakt so. Ad-Hoc wird von Gluon natürlich weiterhin unterstützt, ebenso wie der Parallelbetrieb von 11s und Ad-Hoc. Die oft zitierten 32 Knotenlimits beziehen sich auf die Anzahl der direkten Nachbarn. Da kann 11s soweit ich weiß nicht mehr verwalten und wird einfach die 32 ersten Nachbarn nehmen. Für übliche Freifunknetze ist das kein Problem.

Es gibt bereits Geräte auf denen Gluon laufen kann, die Ad-Hoc und AP nicht gleichzeitig können, Ad-Hoc und 11s jedoch schon. Dazu gehört neben meinem x86 Laptop auch der VoCore und andere Ralink-basierte Geräte.

Da vermutlich Adhoc und 11s nicht auch noch gleichzeitig gehen, kann man wohl nicht so einfach wechseln.

Wird es da ein Updateprozedere geben oder müssen die Communities da nochmal selbst basteln?

Auf den Geräten auf denen adhoc+AP geht, geht auch adhoc+AP+11s.

3 Likes

Das ist ja fett! <aödlskfjaösdkfjaöfkljd>

Hat schon jemand 802.11s only in einer größeren Wolke getestet? Wie sind die Erfahrungen? Gibt es noch Probleme? @tcatm, du weist wahrscheinlich am besten bescheid.

Haben es hier Mal in einer dreier Wolke getestet. Durchsatz ist gleich, gefühlt soll die Latenz besser sein. Könnte aber auch einfach daran liegen, dass die Knoten, die schon länger liefen, komplett zurückgesetzt worden sind.

1 Like

Hier beobachte ich ab und an, dass Meshlinks mit 11s quasi einschlafen. Das Signal ist konstant vorhanden, die TQ liegt aber dauerhaft im einstelligen Prozentbereich.

Bei Routern mit SSH-Zugriff reicht in der Regel der wifi-Befehl schon aus, damit das Problem wieder verschwindet. Welche Ursache könnte das haben?

Es sieht für mich nach einem BATMAN-Problem aus, der der 11s-Link ist in Ordnung, er wird dann nur nicht benutzt:

# iw mesh0 station dump

Station 62:e8:28:d6:12:54 (on mesh0)
    inactive time:    1467890 ms
    rx bytes:    1241929107
    rx packets:    7805919
    tx bytes:    1084383445
    tx packets:    5116688
    tx retries:    4127893
    tx failed:    4122
    signal:      -77 [-79, -81] dBm
    signal avg:    -77 [-78, -81] dBm
    Toffset:    -92154273569 us
    tx bitrate:    52.0 MBit/s MCS 11
    rx bitrate:    78.0 MBit/s MCS 12
    expected throughput:    0.933Mbps
    mesh llid:    305
    mesh plid:    1021
    mesh plink:    ESTAB
    mesh local PS mode:    ACTIVE
    mesh peer PS mode:    ACTIVE
    mesh non-peer PS mode:    ACTIVE
    authorized:    yes
    authenticated:    yes
    preamble:    long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:    no