[Berlin-wireless] BBB verschlüsseln ...

[Bastian]

Hallo,

es gibt da noch eine bisher ungenannte Möglichkeit, wie wir die Probleme
mit den wenigen 5GHz-tauglichen Smartphones umgehen können:
Channel-Shifting ...
... ist mit AirOS möglich.
Sorgt dafür, das andere Geräte die SSID gar nicht sehen. Nicht
Hidden-ESSID-artig, sondern wirklich nur noch im Spectrum-Analyzer.

(Die Crypto-Vertreter dürfen jetzt gerne über die Vor- und Nachteile von
dieser Art der "Security through Obscurity" diskutieren.)

Damit sollten also auch die Use-Cases abgedeckt sein, in denen der
Smartphone-User doch wirklich mal auf das WLAN mit dem Schloss klickt
und irgend ein oder gar das richtige Passwort eintippt.
Keine Ahnung wie der Support dazu unter OpenWRT oder anderen Systemen
aussieht, aber ich denke eher schlecht. Das ganze hätte also ggf. den
tollen Nebeneffekt, das wir unseren UBNT-Vendor-Lockin noch weiter
ausbauen können.
Den Wert des Shiftings können wir einheitlich halten und genauso
öffentlich machen wie das Kennwort. Um unsere Transparenz zu wahren und
so...

@Elektra
Vielen Dank für die Erläuterung. Die Air-Time von noch nicht
assoziierten Clients habe ich nicht bedacht.

Gruß
Bastian

On 06/29/2014 03:59 PM, elektra wrote:
> Hi Bastian ?
> 
> Messung über die Belastung des Spektrums mit Koordinationstraffic bei niedrigster Basisrate hat Sven-Ola vor einer ganzen Weile gemacht, aber auf einem CCC-Camp und nicht auf den Backbones. Ich habe auch keine Ahnung, wie man das mit AirOS machen kann. Man müsste vielleicht ein zusätzliches, vergleichbares Gerät im Monitor-Mode auf den Türmen aufstellen, um das annähernd zu messen. Ich weiß nicht, ob das jemand in der BBB-Situation gemacht hat und wenn, müsste man das an vielen Standorten über einen längeren Zeitraum machen um eine ordentliche Datenbasis zu haben. Es reicht ja, wenn das Problem in unregelmässigen Abständen auftritt und die Leute dann fluchen, die den Backbone benützen wollen. 
> 
> Es wird in einer Umgebung, wo viele Geräte in Reichweite sind, exoribant viel Airtime für Probe-Scans, Probe-Responses, Beacons, Client-Assoc-Requests etc verbraucht. Ich erinnere mich grob, in der Größenordung von 40-60% der Airtime ging bei der Messung von Sven-Ola für 80211-Koordinierungs-Foo drauf.
> 
> Das 802.11-Protokoll hat viele Message-Typen, die mit Basisrate verschickt werden, um maximale Reichweite für Koordinationszwecke zu erzielen. Es soll sichergestellt werden, dass solche Koordinationsversuche erfolgreich sind und möglichst alle Stationen das mitbekommen.
> 
> Weiter: So richtig doof wird es, wenn sich ein Client am Boden dann tatsächlich mit dem Backbone assoziiert hat. Dessen Datenverkehr läuft dann *garantiert* mit niedrigster Bitrate, weil der hohe Standort wegen der vielen, wechselnden Störungen in der Fresnelzone und der AP wegen seiner exponierten Position den Client nur mit niedrigster Datenrate empfangen kann. 
> 
> Elektra
> 
>

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 538 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140629/9a2fde24/attachment.pgp>