[Berlin-wireless] großer Routen-fubar oder wie lernte die Brieftaube zu lieben

[Axel]

Hallo,

On Freitag 23 November 2007, Frithjof Hammer wrote:
> Hallo!
>
> Ich jage seit einigen Wochen mit wachsender Verzweiflung einem Fehler
> hinter her.
>
> Das Problem spielt sich in Weissensee und bzw. irgendwo zwischen Kernel und
> olsrd ab.
>
> Die Fehlerbilder sind vielfältig und verändern sich gern über die Zeit bzw.
> bei topologischen Veränderungen.
>
> Einige typische Fehlerbilder:
>
> -Pings über eine direkte (managed 5GHZ) Strecke gehen verloren oder
> brauchen bis zu 3000ms. Zeitgleiche arppings auf die gleiche Gegenstelle
> werden ohne Verluste und Verzögerungen beantwortet. Am ttl der Pings ist
> aber zu erkennen, dass es sich nicht um eine Kreisroute handelt, die gerade
> noch schnell genug verlassen wird. Der Anhang "ping.txt" zeigt dieses
> Verhalten.
>
> -ping -R zeigt ein eigenwilliges Routenspringen wie im Anhang "ping_-R.txt"
> gezeigt. Eigenwillig, weil es kein Springen der Route ist. Die IPs
> 104.0.200.2 und 104.0.200.5 sind zwei Interfaces im selben Node.
So weit ich weiß zeichnet ping -R die IP des ausgehenden Interfaces von jedem 
Node auf ( traceroute dagegen die des eingehenden Interfaces ). Demnach hast 
du dann doch ein Springen der Route. Zum teil werden die pakete über den 
Link: 104.0.200.2 -> 104.0.200.6 geschickt und zum Teil über den
Link: 104.0.200.5 -> 104.0.200.6

Kann das sein? Ulf und ich haben schon öfters beobachte wie bei madwifi (mit 
festeingestellter Frequenz, cellid, essid) trotzdem pakete aus anderen 
Kanaelen/cellids/essids beim automatischen background scannen einer atheros 
karte bis in den IP stack gekommen sind. Wenn selbst unterschiedliche WEP 
Schlüssel das nicht abfangen wär das zwar noch ne nummer härter aber wer 
weiß, schlüssel sind ja alle im gleichen treiber hinterlegt.

Konkret ist mir mal aufgefallen wie batman im debug modus Nachbarn (und zwar 
bidirektionale) angezeigt hat die das interface nicht hätte haben sollen. Am 
Ende kam raus das es an diesem blöden background scannen lag (müßte sich 
deaktivieren lassen wenn du das modul /lib/modules/2.6.x/wlan_scan_sta.ko 
umbenennts und neu startest).

Vielleicht kommt der routing daemon ja durcheinander wenn er zwischendurch mal 
einen "sehr guten" link hat der dann wieder komplett weg ist. Die loops die 
in ping_-R angezeigt werden ließen sich doch so interpretieren.

viele Grüße,
axel

> Alle 
> Interfaces haben eine enge Subnetzmaske (255.255.255.252) und sind
> gemanagete 5GHZ Strecken mit guten SNR, unterschiedlichen ESSIDS und
> WEP-Keys.
>
> -doppelte Routeneinträge:
> root at scharpingap:~# route -n | grep 104.66.0.88
> 104.66.0.88     104.0.200.5     255.255.255.255 UGH   16     0        0
> ath0 104.66.0.88     104.12.0.30     255.255.255.255 UGH   19     0       
> 0 eth1 Dies sollte wenig Effekt haben, da ja die Metric unterschiedlich
> ist. Dennoch tritt es sonst bekanntermaßen nicht auf. Meiner Beobachtung
> nach ist die Route via die 104.0.200.5 immer eine Kreisroute.
>
> Alle Probleme treten mit olsrd 0.4.10 und 0.5.4 auf jeweils allen der
> multiinterface Nodes auf. Die multiinterface Nodes sind PCs mit 2.6.16 bzw
> 2.6.18 sowie ein Wrap mit Kamikaze 7.06. Mit dem Auftreten des Fehlers sind
> keine tiefgreifenden Änderungen einhergegangen.
>
>
> Wer hat Ideen?
>
> Gruß
> Frithjof