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

[Horst Krause]

hallo frithjof + liste,

ist zwar verm. off-topic, aber trotzdem eine ping-trophy!
getreu dem motto, horsti-klugscheisser will auch pupen:

wahrscheinlich durch eine wildgewordene batmanIn.stable (!)
WAR vor ein paar wochen hier in nieder-f'hain mal alles dicht.

== begin zitat "negative ping-time" =========================
ohne irgendwelche eingriffe und nach unauffälligem betrieb
hab ich seit Fr 18~20:00 mega-browne unexpected network-events,
- entweder hat mein wrt keuch-husten,
- oder ich hab einen erdrutsch-artigen hf-glitch,
  der auch gleich raum-zeit-wellen erzeugt,
- oder ein nachbarn betreibt ein noise-device,
- oder irgend jemand macht einen üblen scherz.

erst mal die phänomene:
[mtr] sagt: keine name-resolution, überhaupt ist alles zäh.
erst mal eth-kabel getauscht, kein unterschied.
noch mal [dhclient]; ok, bezieht ip, ect. sonst gleiche effekte.

-- läppi:[ping] via 5m-eth z. wrt_mit_antenne -------------
user at porta:~$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=679 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=2902 ms
64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=2245 ms
64 bytes from 192.168.2.1: icmp_seq=15 ttl=64 time=2806 ms
64 bytes from 192.168.2.1: icmp_seq=21 ttl=64 time=691 ms
64 bytes from 192.168.2.1: icmp_seq=22 ttl=64 time=3459 ms
64 bytes from 192.168.2.1: icmp_seq=23 ttl=64 time=2596 ms
# zäääh, eth-packet-loss, aua?

-- läppi:[ping] via 5m-eth z. wrt_ohne_antenne -----------------
64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=1.45 ms
64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=0.296 ms
Warning: time of day goes back (-1185us), taking countermeasures.
Warning: time of day goes back (-731us), taking countermeasures.
64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=0.000 ms
64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=1.58 ms
64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=1.45 ms
64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=0.433 ms
64 bytes from 192.168.2.1: icmp_seq=49 ttl=64 time=1.45 ms
64 bytes from 192.168.2.1: icmp_seq=50 ttl=64 time=0.398 ms
64 bytes from 192.168.2.1: icmp_seq=51 ttl=64 time=0.347 ms
Warning: time of day goes back (-986us), taking countermeasures.
64 bytes from 192.168.2.1: icmp_seq=52 ttl=64 time=0.000 ms
64 bytes from 192.168.2.1: icmp_seq=53 ttl=64 time=0.545 ms
# oops, normal ist (eth-)ping <1ms,
# NEGATIVE zeiten?
# uhr läuft rückwärts, oder wird "überholt ohne einzuholen"?

== end zitat =========================================================

gruss horst_104.131.10.1
offlinehorst at web.de



On Fri, 23 Nov 2007 17:58:47 +0100
Frithjof Hammer <olsrexperiment at frithjof-hammer.de> 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. 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
>