[Berlin-wireless] leiduges thema ad-hoc-interface

[Sven-Ola Tuecke]

Dennis,

in Deinen Ausfuehrugen kommt das Stichwort "TSF" nicht vor. Du kannst jede 
X-beliebige WLAN-Karte auf eine BSSID zwingen (hat jedenfalls immer ganz gut 
geklappt), wenn diese beim Hochfahren auf einen aelteren Node trifft (aelter 
im SInne des TSF - ein Zeitstempel in den Beacons). Starte erstmal das 
hOrst-Tool auf einem WRT in der Naehe des bockigen Rechners. Mit der 1.2 
dieses Tools kannst du die oberen 32Bit des TSF anzeigen:

- ipkg install horst
- wl monitor 1
- horst

Der bockige Rechner sollte hier mit einer anderen BSSID angezeigt werden. 
Sonst sendet er ja gar nix + die Antenne ist nicht dran oder die Karte ist 
echt Gaga. Dann erzwinge die BSSID, indem du beim WRT den TSF auf irrsinnig 
alt stelltst:

- ipkg install freifunk-setbssid
- freifunk-setbssid -s eth1 ffff0000:0

Das bringt den WRT auf 500.000 Jahre. Wenn die OGO-Karte dann nicht in 1-2 
Minuten die BSSID vom WRT uebernimmt wirf sie einfach weg. Achso: Gerade bei 
Prism2 ist die Firmware-Version eine Einflussgroesze, genauer die "Station 
Firmware". Gerade die neueste Version kann Ad-Hoc gar nicht gut 
(...ausprobieren). Die FW kann man downgraden. Hier eine funktionierende 
Version vom HDL2:

root at mtx-hdl-2:~# hostap_diag wlan1
Host AP driver diagnostics information for 'wlan1'

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.7.4 (station firmware)

HTH Sven-Ola 

Am Montag 24 April 2006 11:54 schrieb Dennis Bartsch:
> hallo liste,
>
> langsam wird haarig in wse ... aber erstmal zur vorgeschichte:
>
> da mitte letzten jahres die WRTs noch relatuv teuer gewesen sind und ein
> akutes performance-problem mit wachsender node-anzahl hatte, entschieden
> wir uns, an eher zentralen punkten APs aus alter PC-Hardware
> zusammenzufrickeln. aus sichter des stromverbrauch gibt es da ab 3
> wlan-interfaces keinen großen unterschied (27W für den kompletten rechner
> unter belastung in der cbase ggü 3x8W für linksysse incl steckernetzteile)
> und die prozssorauslastung lag nie über 40% (400MHz k6-2). das hat die APs
> zu sehr zuverlässigen knoten gemacht (1 monat uptime ohne einen neustart
> ... bei dieser node-dichte in wse schafft das kaum ein WRT). aber dann kam
> der force-BSSID-hack für den WRT ... fluch und segen zugleich. erst war er
> ein segen, da weißensee bis dahin alle 2-3 wochen von herben teilweise tage
> dauernden BSSID-splittings erschüttert wurde ... surfen was nicht möglich.
> doch als alle WRTs nach unser bitten, betteln und flehen upgedated waren,
> wollten die prismGT, die in den PC-APs die rundstrahler befeuerten, sich
> mit dem ad-hoc-Netz nichtmehr verbinden ... mit jedem ifdown/ifup haben die
> karten eine andere schwachsinnige BSSID angenommen. selbst das minütliche
> cron-script hat stunden gebraucht, um die prisms wieder ins ad-hoc-netz zu
> stellen, was dann wieder nur für weniger als eine stunde hielt. da
> "dramatische" daran ist, dass diese selbstgestrickten APs mittlerweile das
> rückrat bilden.
>
> daraufhin haben wir uns auf alternativensuche für die wlan-karten gemacht.
> zuerst habe ich in einer unschönen downtime des internetuplinks über ostern
> dem uplink-AP nen 2.6er kernel verpasst und den islsm-treiber für die
> prismGT ... der stack hat zwar behauptet, die karte würde mit einer festen
> bssid im netz stehen, routen wurden aber trotzdem nicht aufgebaut ...
> nichteinmal bekannte nachbarn konnten angepingt werden. zusätzlich haben
> sich der im islsm genutzt madwifi-bsd-stack und der madwifi-ng-stack
> beharkt ... also keine alternative. ähnlich verhielt sich auch die ralink
> rt2500 mit aktuellem rt2x00-treiber ... feste bssid ist zwar möglich, aber
> es gibt keine verbindung. den dritten anlauf haben wir gerade mit einer
> intel 2200bg am laufen ... mit den modul-parametern "auto_create=0 mode=1
> channel=10 hwcrypto=0" geladen ... aber diese scheint sich ihre nachbarn
> auszusuchen ... es gibt nie verbindungen zu mehr 3 nachbarn gleichzeigtig
> ... noch dazu steigt die karte regelmäßig mit einer flut von "firmware
> errors" im kernel-log aus. also _auch_ keine alternative ...
> momentan frickeln wir mit einer prism2 rum ... mit hostap-treibern und
> 1.4.9-firmware lässt sich die bssid fest einstellen und es werden auch wie
> verrückt olsr-pakete gesendet und empfangen ... aber der olsrd (0.4.10 mit
> "fixes" und "optimize" patches) will keine routen über das interface
> aufbauen. es ist zum auswachsen.
>
> hat noch wer ideen, wie wir die rundstrahler wieder ans netz kriegen
> können?
>
> durch den halb-offline-zustand dieses rundstrahlers sind ~20 APs betroffen,
> die so nur halb online sind (mal gehts, mal gehts nicht), wo vorher locker
> mindestens 100kB/s über das backbone aus dem internet geflossen sind. jetzt
> kann man uns zum einen auslachen, wieso wir uns die arbeit machen und
> gemacht haben, wo es doch die WRTs gibt, oder zum anderen über redundante
> netzstruktur blubbern ... das problem löst das aber nicht ... ich bin eher
> an technischen lösungen interessiert.
>
> gruß
> dennis bartsch
> wlanhsh.de
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

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