[Berlin-wireless] BSSID partitioning, wl.o internal (fehlender Absatz) - was: Funknetz-Upgrade Vorwarnung
Marco Tidow
martidow
Mi Feb 15 10:43:52 CET 2006
On Wed, Feb.15. 02:14 +0100, Marco Tidow wrote:
> 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 :-)
Das erwähnte script unten wird so ziemlich unverständlich aussehen. Hier fehlt
noch, daß ich Samstag Morgen nach Abschicken eigentlich "harmloser" Kommandos
wie "wl channel" und "wl channel 10" auf einer b+g-node zwischendurch folgendes
sehen mußte:
----------------------------------------------------------------------
root at testhop2:~# wl channel
No scan in progress.
current mac channel 10
target channel 10
root at testhop2:~# wl scan; sleep 4; wl scanresults
[...noch beide BSSIDs auf channel 10 angezeigt...]
root at testhop2:~# wl channel
No scan in progress.
current mac channel 11 **** haeh?
target channel 10
root at testhop2:~# wl channel 10
root at testhop2:~# wl channel
No scan in progress.
current mac channel 11
target channel 11
[auch mehrfach nach ca. 10s wiederholt, immer dasselbe]
----------------------------------------------------------------------
In der Folge lief die b+g-Fraktion dann laut "wl scan" tatsächlich auf channel 11,
mit derselben, eigenen BSSID wie zuvor auf channel 10.
Verifiziert durch ping und tcpdump (ohne "wl monitor 1" !!!).
Der cron lief weiterhin im Hintergrund, aber es blieb wiederum bei 10 + 11.
Jetzt wird der channel-Test im script sicherlich plausibler.
Zudem ist mir aufgefallen, daß "wl status" wohl den "target channel" anzeigt, nicht
den "current mac channel".
Es ist möglich, daß ich den channel-flip durch ein "wl scan" angeschubst habe, wonach
aufgrund des dabei ja stattfindenden Wechsels der channels, das radio offenbar auf
channel 11 "sein" Netz angenommen hat.
> 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
Mehr Informationen über die Mailingliste Berlin