[Discuss] Die Probleme mit den neueren FFF

[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