[Discuss] Ad-Hoc BSSID Erfahrungen gesucht

[Sven-Ola Tuecke]

Hi,

in Vienna macht ihr ja auch Ad-Hoc AFAIK. Hoere gerne in der naechsten Zeit 
auch Eure Erfahrungsberichte ueber BSSIDs + IBSS um die Funktion evnt. noch 
zu optimieren. In Berlin machen wir das zur Zeit so:

- Vorgabe lautet: Stellt bitte Euere WRTs auf BSSID=02:ca:ff:ee:ba:be
- Wir haben 2 WRTs an zentralen Punkten, die diese BSSID "durchsetzen"
- Das geht mit freifunk-setbssid -s eth1 ffffffff:0 in 
/usr/sbin/cron.minutely

Bisschen Hintergrund-Info noch:

<mail0>
Hi Peter, et al.,

neben den Fischaugen wird es jetzt auch eine feste BSSID im Ad-Hoc-Mode 
geben.
DIese lautet 02:ca:ff:ee:ba:be und kann auf den WRTs fest eingestellt 
werden.
Vorteile einer festen BSSID:

- Keine Kanalkriege mehr
- Rate-set wird nicht mehr von aussen beeinflusst (G-Mode ist also moeglich)
- Keine BSSID-Kriege mehr

Im Moment erzwinge ich diese BSSID von einem meiner WRT-Geraete am Alex. Es
sollten aber alle fest einstellen, die diese Moeglichkeit haben. Das geht im
Moment mit WRTs unter Freifunk-Firmware und mit MadWifi/Atheros (nur mit
MadWifi-Alt + What-the-hack-Hack oder mit MadWifi-NG mit allerneuestem Stand
von vor 3 Tagen oder so: "iwconfig ath0 mode ad-hoc [...];iwconfig ath0 ap
02:ca:ff:ee:ba:be").

Auf allen zentralen Cubes (wenn Ad-Hoc)  ist ein Restart-Job aktiv, der die
Ad-Hoc-WLAN-Karte solange neu startet, bis 02:ca:ff:ee:ba:be entdeckt ist.
Wird ein Cube von einem Nachbarn (z.B. mit einer wilden Windows-PCMCIA) von
einer anderen BSSID ueberzeugt, wird er solange die WLAN-Karte neu starten
bis wieder 02:ca:ff:ee:ba:be aktiviert ist. Der Windows-User wird garantiert
schnell aufgeben.

Es hat sogar Vorteile, wenn man die BSSID auf dem eigenen WRT fest 
einstellt.
Nur dann kommt man in den Genuss der hohen G-Mode-Datenraten. OLSR-Broadcast
nach wie vor im B-Mode (Einstellung: G-Mode=Auto) aber Unicast kann dann (je
nach Nachbar) im G-Mode stattfinden. Klappt aber nur, wenn man selbst den
BSSID-Hack mit der Einstellung ueberhaupt aktiviert hat.

Achso: Fuer den Managed Mode mit Master+Klient ist das alles natuerlich 
nicht
anwendbar. Und die "personalisierten" Firmwares aus der IP-Vergabe haben
uebrigens ab heute 02:ca:ff:ee:ba:be voreingestellt.

Noch'n achso: Stellt man die falsche BSSID ein (gerade entdeckt: irgendwer
sendet auf de:ad:be:ef:ba:be), kann man auch nicht mit anderen 
kommunizieren.
Es ist sogar so, dass die ESSID mehr oder weniger egal ist. Die braucht man
eigentlich nur, um eine gemeinsame BSSID auszuhandeln. Nur bei gleicher 
BSSID
koennen sich Stationen im Ad-Hoc-Modus gegenseitig hoeren.

HTH, Sven-Ola

Am Mittwoch 08 März 2006 21:16 schrieb Peter Lazarev:
> Danke Elektra - gut und verständlich erklärt
> Gruss Peter
>
> wirelesslan in Berlin <(spam-protected)> schrieb am 08.03.06
18:40:19:
> > Hi!
> >
> > Die Fischaugen reduzieren in erster Linie die Routingloops, indem
> > Topologienachrichten in einem lokalen Bereich öfters weitergereicht
> > werden als die 'Hellos'. In zweiter Linie trudeln (da
> > Topologiebroadcasts nicht mehr jedesmal über das ganze Netz
> > weitergereicht werden) etwas weniger globale Topologienachrichten ein.
> > Durch die schiere Grösse des Netzes (und weil einige Leute keine Updates
> > mitmachen...) treffen trotzdem immer noch ständig globale Broadcasts
> > ein. Ausserdem gehen immer mehr Leute ins Freifunk-Netz...
> >
> > Das 'inverse' Fischauge macht nicht etwa das Gegenteil, sondern geht in
> > dieselbe Richtung: Topologienachrichten, die von JWDEE eintreffen führen
> > nicht jedesmal zu einem neuen Durchlauf der Dijkstratabelle, sondern nur
> > noch Topologienachrichten aus dem lokalen Bereich lösen das aus. Treffen
> > keine lokalen Topologienachrichten ein, wird trotzdem die
> > Dijkstra-Tabelle nach dem Verstreichen eines Intervallwertes
> > durchgerechnet.
> >
> > Fischauge also hier wie dort...
> >
> > Wir kümmern Uns mit beiden Mechanismen also mehr darum was in der
> > Nachbarschaft geschieht, als was 10 Hops weiter passiert.
> >
> > Weiter haben die Bugfixes von Sven-Ola die Rechenlast reduziert. Da
> > wurde wegen eines Bugs unnötig oft die Dijkstratabelle durchgerechnet.
> >
> > Nun kann man noch einen inkrementellen Dijkstra-algorithmus einführen um
> > die CPU-Last weiter zu reduzieren.
> >
> > Trotzdem skaliert ein Proaktives Routingprotokoll in einem Mesh nicht
> > bis ins Unendliche. Aber die Latte hängt wieder sehr viel höher bis wir
> > wieder bei 99.9% CPU-Last ankommen...
> >
> > cu elektra
</mail0>

<mail1>
Lui,

theorethisch ja - praktisch nein. Das funktioniert bei ESSID!=ESSID aber
BSSID==BSSID nur zwischen zwei WRTs und (wichtiger) das Aushandeln des
Rate-sets funktioniert nur ordentlich bei gleicher ESSID. Man muesste also
auch noch die Uebertragungsrate auf beiden seiten manuell festlegen - sonst
unzuverlaessig oder langsamer als moeglich. Die verfuegbaren Raten stehen in
den Beacons und alle Becons mit != ESSID werden ja komplett ignoriert. Die
feste BSSID erreiche ich uebrigens mit "selektiver Taubheit" -> bestimmte
Beacons werden halt zusaetzlich ignoriert, z.B. welche mit falscher BSSID.

Grusz, Sven-Ola

Am Donnerstag 09 März 2006 01:41 schrieb Ludger Schmudde:
> Hi Sven-Ola,
>
> >Es ist sogar so, dass die ESSID mehr oder weniger egal ist.
> >Die braucht man eigentlich nur, um eine gemeinsame BSSID auszuhandeln.
>
> Nur bei
>
> >gleicher BSSID koennen sich Stationen im Ad-Hoc-Modus gegenseitig hoeren.
>
> oh - heißt das jetzt 'Werbefreiheit' im FFNetz?
> ...mit heterogener ESSID-Struktur: "freifunk.im-norden.de",
> "freifunk-robinson-sucht-freitag"?
> und mithin - für Problemfälle - auch: "Update-mal-deine-fff" >;-)
>
> Lui
</mail1>