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

[Dennis Bartsch]

hi,

bgscan habe ich schon kurz nach dem bauen der 5GHz-links abgeschaltet, weil das so einige effekte über die zeit beseitigt hat und damit die durchschnittliche performance verbessert ... das aber mit "iwpriv athX bgscan 0". wäre aber nicht das erste mal, dass der madwifi sich nicht so verhält, wie per iw-tools eingestellt.

warum wir den WEP-key rausnehmen sollen, ist mir nicht klar. das steht so ohne begründung doch sehr dogmatisch im raum.  zumal wir damit seit nun 2 jahren keine probleme haben. dagegen spricht auch, dass viele anderen pakete eben ganz normal fließen. parallel zu den pings, die bis zu 800s (ja, achthundert sekunden) brauchen, läuft ein /dev/zero-download mit mehreren hundert kB/s.

gruß
dennis


> From: axel at notmail.org

> 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
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

_________________________________________________________________
Jetzt kostenlos downloaden: 30 Messenger Emoticons!
http://www.messenger-emoticons.de/
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071123/b983967e/attachment.html>