[Berlin-wireless] BSSID partitioning, wl.o internals - was: Funknetz-Upgrade Vorwarnung

Mi Feb 15 02:14:16 CET 2006

On Tue, Feb.14. 09:37 +0100, Sven-Ola Tuecke wrote:
> Hi,
> 
> etwa Ende Marz wuerde ich gerne (falls alles so klappt wie ich es mir 
> vorstelle) ein Major-Upgrade durchfuehren. Diese Mail soll Euch schon mal 
> "seelisch vorbereiten".  Hintergrund: Der Ad-Hoc-Mode funktioniert hier in 
> Berlin gerade mal so. Wir haben wechselnde BSSIDs, die mit einem gemogelten 
> TSF von 500.000 Jahren Halbstabilitaet herstellen. Das ist nix richtiges. Ich 
> habe eine erste Version am zucken, bei der ich die BSSID hart vorgeben kann 
> und Join-Versuche auf anderen BSSIDs oder inkompatiblen TSFs ablehne.

Hm, ich habe grad' den Überblick verloren, ist damit jetzt schon ein/der "open-source"
wl-driver gemeint?  Oder ein dis-assemblierter broadcom wl.o, den man nach Modifikation
wieder durch den gas kriegt?  Doch nicht ein binär-ge-pacht-es irgenwas =8(argg) ?

(Bin durchaus interessiert, die WEP/WPA-option im Treiber zu behalten, schließlich
 würde dies einen universelleren Einsatz der WRT's mit FFF auch in noch-nicht Freifunk-
 congested-"Sie werden doch assimiliert"-areas erlauben ;-)

nevertheless, habe vergangenen Sa. Morgen (nach 'nen brauchbaren punk-concert im
molly)  ca. 03:00 bis 05:00 damit verbracht, eine split-BSSID situation
in unserer Funk-Insel zu analysieren und ohne Neustart "zurückzubiegen".
Wollte vor allem vermeiden, einfach den reboot zu benutzen!

Ausgangs-Situ. war, zweimal "olsr.feifunk.net" im wl-scan, einmal channel-10/11Mbit
und einmal channel-10/54Mbit.  Unterschiedliche BSSID:
--------------------------------------------------------------------------
root at testhop6:~# wl scan
SSID: "olsr.freifunk.net"
Mode: Ad Hoc    RSSI: -38 dBm   noise: -90 dBm  Channel: 10
BSSID: 02:0E:35:00:D0:B7        Capability: IBSS
Supported Rates: [ 1(b) 2(b) 5.5 11 ]

[...]
SSID: "olsr.freifunk.net"
Mode: Ad Hoc    RSSI: -78 dBm   noise: -90 dBm  Channel: 10
BSSID: E6:6A:00:A3:08:30        Capability: IBSS
Supported Rates: [ 1(b) 2(b) 5.5(b) 11(b) 18 24 36 54 6 9 12 48 ]

[...]
--------------------------------------------------------------------------

Dabei waren einige nodes noch per (Funk-)ping erreichbar, andere nicht (s.u.)

Erstmal 'ne 1/2 Stunde zugeguckt, ob die FFF(most 1.0.7+fisheye)-default-cron
Mechanik es packt, nada :-(

Dann Hand angelegt, und die Brechstange entwickelt:
 ( Kam an N-1 nodes auch per
   ethernet ran (alle nodes außer einer stehen in dieser Wolke bei mir :-)

while :; do
  while :; do
    assoc="$(wl status 2>/dev/null)"                                                              
    if echo "$assoc" |grep -sq 'Not associated'; then
      echo -n 'NA '
      wl join olsr.freifunk.net imode ibss amode open;
      wl ssid olsr.freifunk.net;
    else
      echo "$assoc"
    fi
    curr="$(wl channel |sed -n '/target channel/{s/target channel.//;p;}')"
    [ "$curr" != '10' ] && break
    sleep 3
  done
  echo "chan -> $curr"
  echo -n 'DIS '; wl disassoc >/dev/null 2>&1;
  sleep 1
  echo -n 'D '; wlconf eth2 down;
  sleep 1
  echo -n 'OFF '; wl radio off
  sleep 1
  echo -n 'ON '; wl radio on
  sleep 1
  echo -n 'U '; wlconf eth2 up;

  wl monitor 0;
  wl ap 0; wl wep off; wl wepstatus off; wl wpa_auth disable;
  wl txpwr 100;  wl dtim 3; wl frameburst 0;   wl wet off; wl lazywds 0
  wl channel 10;
  wl join olsr.freifunk.net imode ibss amode open;
  wl ssid olsr.freifunk.net;
  wl promisc 1;
  sleep 1
  wl channel
  sleep 4
done

...mit anderen Worten, _alle_ nodes waren um 05:xx wieder "auf Kurs", channel-10 und gleiche
BSSID, mit 11Mbit.  Interpretiere das so, daß das "Alter" der BSSID flöten geht, sobald ich
das wlan-device "down" setze.  Irgendwann ist eine andere BSSID alt genug, die Vorgabe-BSSID
zu liefern und alle anderen nodes "finden sich" wieder auf einer neuen, gemeinsamen BSSID.

Entscheidend ist "wl ssid olsr.freifunk.net", damit initiiert man die Neu-Assoc mit einem vorhandenen
Netz, a ka BSSID.  Alles andere außer "wlconf eth2 down" / "wlconf eth2 up" ist pures Probieren,
aber ohne dieses down/up passiert nix.

Auslöser des BSSID-partitionings könnte ein "Nachbar" gewesen sein, der seinen windoze-Treiber auf
ad-hoc, SSID olsr.freifunk.net gestellt hat, aber 54MBit only spielen wollte.
FF-router, die im B/G-mode liefen, haben sich "zu einer neuen 54Mbit Wolke auf channel 10" überzeugen
lassen...

O.k., ist als "Lösung" nicht wirklich befriedigend, wenn ein client die restliche Wolke zum ggfs.
oszilierenden re-assoc auf einer "neueren" BSSID zwingt.  Andererseits gibt es "weiße Stellen" im
broadcom-wl.driver, e.g.

roam_trigger             -70
roam_delta               20(0x14)

lazywds                  0 (off)
wet                      0 (off)

interference             enabled and not active

Glitch count to enter ACI scan mode: 1000
Glitch count to exit ACI mode: 200
Usecs to spin between rssi samples : 10
Interval (in seconds) for ACI scanning in presence of high glitch count: 20

Was heißt ACI ?

GIBT ES DAZU IRGENDEINE DOKU? (sorry für das visuelle Schreien...)

...die eine Art Automatik des "roamings" vermuten lassen, und bei denen mir nicht klar ist,
ob sie ausschließlich auf den client-mode beschränkte Bedeutung haben.
Habe jedenfalls testhalber "roam_trigger" auf -5 und "roam_delta" auf 30 gesetzt,
IMHO "no roaming possible" ;-)

Wäre interessant, ob es schonmal "gelungen" ist, eine solche split-BSSID Situ. absichtlich herbei-
zuführen?  Ich vermute, daß es mit der 11/54Mbit Voreinstellung zu tun hat.  Alle 11Mbit-only
nodes sind "bei der Stange" geblieben, nur drei b-und-g-mode konfigurierte nicht.

Beteiligt waren in unserem Zoo:
  Gv22   (b-only)
  Gv11   (b+g)       hatte ich eingeschaltet, und kam dannvon den b-only nodes nicht an ihn
                     ran (das war um 03:00 morgens...)
  GSv11  (b+g)       Nachbar, kam bis zuletzt und "von allein" nicht wieder auf neue BSSID,
                     erst, als Steffan später ein "/etc/init.d/S40network restart" per Kabel
                     loslies; uptime 74 days, sollte also eigentlich die älteste BSSID gehabt haben,
                     wäre er nicht zuvor auf die neue 54Mbit-BSSID gewechselt)
  ALL0277(b-only)
  SE505v2(b+g)
  SE505v1(b-only)
  prism2 (b-only)  secondary-firmware 1.4.9, hostap-driver

Alle b-only nodes konnte ich zu Anfang per ping untereinander erreichen, dito alle b+g-nodes.
Die b+g-nodes kamen jedoch nicht wieder auf die BSSID der b-only nodes zurück, auch diese brauchten
die "Brechstange".
Da der v22 jedenfalls neuere broadcom-firmware im radio hat, als die b-only konfigurierten
V1-hardware Ableger, scheint es nicht an selbiger zu liegen, sonst hätte diese Vermutung
nahe gelegen.

also quer Beet, marco

P.S. die link-quality _aller_ nodes liegt so bei 1.00 ...

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin