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

[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