[Berlin-wireless] Die Probleme mit den neueren FFF

[Sven-Ola Tuecke]

Moins,

an der Wireless-Config hab' ich lange nix mehr gedreht. Der Broadcom-Treiber 
fuer die WRTs ist die Datei wl.o. Das ist - wie allgemein bekannt - Closed 
Source. Was der Treiber _genau_ macht steht also in den Sternen. Die Variante 
fuer die Firmware ist eine muehselig mit einem Disassembler und einem 
Hexeditor bearbeitete Fassung, zusammengelinked aus ein paar *.o-Modulen (die 
gab es mal irgendwo - vergessen wo ich die herhab). Beim Linken hab' ich aus 
Platzgruenden den WEP-Krams.o weggelassen - spart Speicher und diszipliniert 
die "Ich muss verschluesseln"-Typen *g*

Das /sbin/wifi ist von Felix und ich hab's geaendert. Quellen dazu gibts hier 
http://download.berlin.freifunk.net/sven-ola/sources/wificonf-1.12.tgz 
(TGZ-Datum auf dem Server ist Bloedsinn, kommt vom Umzug von 
styx.commando.de) Einfach auspacken, "make" druecken und dann "edit 
wificonf.c".

Hintergrund wl0_distance: Das ist ein Hack von Felix, der das Ack-Timing 
direkt in die Register drueckt. Leider verschwindet die Einstellung bei jedem 
Soft-Reset - darum gibts eine Watchdog-Funktion. Beim "offiziellem" OpenWrt 
verbleibt eine Instanz von /sbin/wifi im Speicher, bei der FFF macht das im 
cron ein "/sbin/wifi wdog". Da man den cron eh nicht abdrehen kann (das merkt 
man dann schon *g*) kann der Daemon-Speicherplatz gespart werden.

Hintergrund ff_bssid: Die BSSID wird von /sbin/wifi ausgelesen und per 
Funktionsaufruf dem wl.o-Treiber bekanntgegeben. Leider reicht das nicht - es 
muss im entscheidenden Moment der Treiber "Taub" gegen Beacons/Probes anderer 
Nodes sein. Das wird realisiert in wlcompat.o und zwar als Erweiterung des 
ioctl(bla, 0xdeaf, bla). Letzeres patched auch ein paar Nullen in wl.o 'rein 
und zwar dahin, wo die Beacons verarbeitet werden (Null==MIPS No-Operation).

Das spielt an sich alles gut zusammen und daher gibts keinen Grund da was zu 
drehen. Achso. Harald hat recht - da ja nix ueber den Binary-Treiber bekannt 
ist kann es absolut sein, dass unterschiedliche ESSIDs bei gleicher BSSID 
irgendwelche Seiteneffekte provozieren.

Noch'n Wort zu Default-Routen und so. Ihr habt in Wien zwar den 
IP-Sonderdroesel, aber defekte oder "so-nicht-gemeinte" Default-Routen 
stoeren auch in anderen Netzen gerne. Aus dem Grund gibts das dyngw-plain. 
Dumm - aber immerhin erkennt man ein Geraet mit statischer Default-Route am 
HNA4(0/0)-Announcement. Wenns bei euch oefters schief geht: "ip r del 
default;ip r del default;ip r del default" in /etc/init.d/S53olsrd einbauen. 
Das hilft. 

Leider ist Policy-Routing kompliziert zu konfen und Fehler macht man daher 
schnell. Die Funktion ist fuer "Ich will mein eigenes Internet nur fuer mich 
aber gleichzeitig am Freifunk teilnehmen ohne Internet fuer andere 
anzubieten"-Typen. Passt also nicht ganz fuer den Wiener "Offizielle IPs und 
mehrere IP-Bereiche im Mesh Sonderdroesel".

Achja. OLSR-Versionen. Leute vergessen, dass in der FFF haeufig Patches 
enthalten sind, die in den "offiziellen" Versionen nicht - oder erst spaeter 
enthalten sind. An sich ist das Firmware-Datum aussagekraeftiger, wenn man 
auf Sourceforge nach ff-devel/freifunk-olsrd.mk und ff-devel/1*.patch Dateien 
guckt.

HTH,
// Sven-Ola

Am Sonntag 16 November 2008 19:51:36 schrieb Harald Geyer:
> Hi!
>
> Wir (Markus Kittenberger und ich) haben dieses Wochenende versucht,
> den wifi Problemen mit den FFF Versionen nach 1.6.28 auf den Grund
> zu gehen.
>
> Wer die ganzen technischen Ausführungen nicht lesen möchte, der
> soll bitte am Ende dieser Mail weiter lesen! Diese Informationen
> sind  FÜR  ALLE  NODEOWNER  WICHTIG.
>
>
> An den Treibern scheint es (wie Sven-Ola eh schon gesagt hat) keine
> Änderungen gegeben zu haben. Ich glaube daher, dass durch irgendwelche
> Änderungen (vielleicht im nvram?) das Timing des wifi Hardware
> jetzt anders ist...
>
> Leider ist das eine Sache wo es um Mikrosekunden geht, daher ist das
> nicht so einfach zu debuggen. Schon gar nicht live in einem
> Großstadt-Mesh. Deshalb ist das Folgende alles noch Spekulation:
>
> Ich glaube, dass der Timeout, den die Hardware auf ein Layer-2 ACK bzw.
> CTS wartet zu kurz ist. Dadurch sendet die Hardware ein Retry während
> das ACK kommt, es gibt Kollisionen und über den Link geht nichts mehr.
>
> Einstellen kann man diesen Timeout in der FFF (theoretisch) über die
> Option "Entfernung" unter "Drahtlos".
>
> Die nvram Variable dazu heißt wl0_distance und ist aber bei den
> meisten Leuten nicht gesetzt. Soweit ich das sehe, wird diese
> Variable in den Skripts in der FFF nirgends verwendet, allerdings
> gibt ein 'strings /sbin/wifi | grep distance' einen Treffer...
>
>
> Dazu hab' ich folgende Fragen:
>
> Gibt's wo den source für /sbin/wifi?
>
> Könnt' es sein, dass sich die Interpretation dieser Variable
> (oder ihrer Abwesenheit) geändert hat und das wifi timing daher
> jetzt schlechter ist als vorher?
>
> Hat jemand eine Ahnung, was /sbin/wifi mit wl_distance macht?
>
> Bisher hab' ich leider nicht herausgefunden, wie man das tatsächliche
> timing aus der Hardware auslesen kann. Es gibt 'wl shortslot' aber das
> sagt nur kurz/lang - Ist das schon alles, was die broadcom Hardware
> kann? Weiß jemand mehr zu dem Thema?
>
> Kann es sein, dass eine der neueren FFF beim upgrade für wl0_distance
> irgendwelche default Werte ins nvram geschrieben hat? (Würde auch
> erklären, warum es nach einem downgrade - zumindest bei einigen Nodes -
> dann keine Verbesserung mehr gab.)
>
> @Sven-Ola: Kannst du zu diesem Rätsel irgendwelche Steine beitragen?
>
>
> Was noch erschwerend hinzukommt ist, dass nach wie vor (trotz
> Warnung vor etlichen Wochen) noch immer viele Router mit
> persönlichen SSIDs konfiguriert sind. AFAIK werden timing Sachen
> zumindest teilweise über die beacons ausgehandelt.
> Ich weiß nicht, ob's in diesem Fall einen Unterschied macht, aber
> es macht wenig Sinn ein Problem zu debuggen solang die Leute ihre
> Router mutwillig falsch konfigurieren.
>
>
> Des weiteren sind wir möglicherweise einer Ursache für die
> langzeitstabilen (mehrere Tage, in einem Fall sogar Wochen)
> routing loops in unserem Netz auf die Spur gekommen:
>
> In der FFF ist das dyn_gw Plugin aktiviert, das bei vorhandensein
> einer nicht vom olsrd eingetragenen default route automatisch
> HNA dafür macht. (Im Wiener Netz ist das unnötig.) - Es ist zumindest
> ein Fall bekannt, wo bei uns dadurch ein falsches HNA im ganzen
> Netz verbreitet worden ist - mehrere Monate unbemerkt (die Route ist
> zufällig nie zum Zug gekommen).
>
> Ich kann im Moment nicht beweisen, dass das dyn_gw Plugin wirklich
> zu loops geführt hat, aber es wäre jedenfalls fein, wenn man das
> abstellen könnte. Ich hab' versucht das zu erreichen indem ich
> policy routing aktiviere, aber das funktioniert im Wiener Netz
> auch nicht, weil wir IPs aus mehr als einem subnet verwenden, wodurch
> der kernel dann (mit dem setup in der FFF) nicht mehr die richtigen
> tables findet. Auf den Routern mit /32 subnet ist dann überhaupt nichts
> außer den direkten Nachbarn erreichbar, weil die Gateways alle in
> einem "unreachable routing table" stecken ... :)
>
> Will sich jemand dessen in einem 0xff-ipk annehmen? Oder gleich der
> Sven-Ola in der FFF darauf Rücksicht nehmen?
>
>
>
> Es gibt ein paar Dinge, die alle Nodeowner tun können, um die Probleme
> zu verringern bzw. unsere Fehlersuche einfacher zu machen:
>
> Bitte nur die "offiziellen" SSIDs auf Routern verwenden, die sich mit
> dem Mesh verbinden sollen. Die SSID ist dazu da, um das Netz zu announcen
> und nicht den einzelnen Router. Verbindungsprobleme zwischen Routern
> mit verschiedener SSID werd' ich mir in Zukunft nicht einmal ansehen.
> Wer wissen will warum, der muss die technischen Ausführungen oben
> lesen.
>
> Ansonsten tät's mir auch sehr helfen, wenn Leute Fälle, wo ein
> upgrade/downgrade zwischen 1.6.28 und neuer Links beeinflusst hat,
> halbwegs nachvollziehbar dokumentieren würden (wiki oder von mir
> aus auf der Wien-Liste). Es ist echt nicht einfach, so ein
> Problem zu untersuchen, wenn man die Fälle immer nur vom Hörensagen
> über drei Ecken kennt...
>
> Liebe Grüße,
> Harald