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

Sa Nov 24 01:42:38 CET 2007

hi frithjof,

Am 23.11.07 schrieb Frithjof Hammer <olsrexperiment at frithjof-hammer.de>:
> Am Freitag, 23. November 2007 schrieb Frithjof Hammer:
> > Am Freitag, 23. November 2007 schrieb ulf kypke:
> > > und das wep ausschalten
> > > gruss ulf
> >
> > ich habe kein Layer2 Problem. Die Arpings beweisen dies.
>
> Ulf, ich muss Abbitte leisten.
>
> Ich habe wohl doch (auch) ein Layer 2 Problem:
> Ich habe nochmals pings und arppings gleichzeitig über die Wlanstrecke
> geschickt. Wieder eine direkte Verbindung.
>
> Diesmal tauchten zeitgleich mit den langen Pings auch lange arppings auf.
> Ein aktueller madwifi (snapshot von heute) machte es noch schlimmer:
>
> root at repeaterKV:~# ping 42.0.200.1
> PING 42.0.200.1 (42.0.200.1) 56(84) bytes of data.
> 64 bytes from 42.0.200.1: icmp_seq=1 ttl=64 time=1.24 ms
> 64 bytes from 42.0.200.1: icmp_seq=2 ttl=64 time=0.953 ms
> 64 bytes from 42.0.200.1: icmp_seq=3 ttl=64 time=0.919 ms
> 64 bytes from 42.0.200.1: icmp_seq=4 ttl=64 time=0.786 ms
> 64 bytes from 42.0.200.1: icmp_seq=5 ttl=64 time=0.885 ms
> 64 bytes from 42.0.200.1: icmp_seq=6 ttl=64 time=0.780 ms
> 64 bytes from 42.0.200.1: icmp_seq=7 ttl=64 time=0.839 ms
> 64 bytes from 42.0.200.1: icmp_seq=8 ttl=64 time=0.905 ms
> 64 bytes from 42.0.200.1: icmp_seq=9 ttl=64 time=0.976 ms
> 64 bytes from 42.0.200.1: icmp_seq=10 ttl=64 time=0.810 ms
> 64 bytes from 42.0.200.1: icmp_seq=11 ttl=64 time=0.946 ms
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> ^C

oh wei, ist es mal wieder soweit... dann heisst es wohl etwas warten

> --- 42.0.200.1 ping statistics ---
> 13 packets transmitted, 11 received, 15% packet loss, time 31006ms
> rtt min/avg/max/mdev = 0.780/0.912/1.241/0.127 ms
> root at repeaterKV:~# ping 42.0.200.6
> PING 42.0.200.6 (42.0.200.6) 56(84) bytes of data.
> 64 bytes from 42.0.200.6: icmp_seq=1 ttl=64 time=1.14 ms
> 64 bytes from 42.0.200.6: icmp_seq=2 ttl=64 time=0.683 ms
> 64 bytes from 42.0.200.6: icmp_seq=3 ttl=64 time=0.780 ms
> 64 bytes from 42.0.200.6: icmp_seq=4 ttl=64 time=2.84 ms
> 64 bytes from 42.0.200.6: icmp_seq=5 ttl=64 time=0.915 ms
> 64 bytes from 42.0.200.6: icmp_seq=6 ttl=64 time=0.755 ms
> 64 bytes from 42.0.200.6: icmp_seq=7 ttl=64 time=0.769 ms
> 64 bytes from 42.0.200.6: icmp_seq=8 ttl=64 time=0.685 ms
> 64 bytes from 42.0.200.6: icmp_seq=9 ttl=64 time=0.628 ms
> 64 bytes from 42.0.200.6: icmp_seq=10 ttl=64 time=1.11 ms
> 64 bytes from 42.0.200.6: icmp_seq=11 ttl=64 time=0.706 ms
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
>
> Das Verhalten war wiederholbar und tauchte zu beiden Gegenstellen auf (jeweils
> ein Interface mit einer Gegenstelle).
>
> Demütig geworden, habe ich zur vorigen madwifi version zurück gewechselt
> (ath_pci: 0.9.4.5 (svn r2652)) und den WEP-Schlüssel entfernt.
>
> Jetzt zeigt es wieder das alte Verhalten (arpings bis etwa 1s). Nun aber, mit
> einem Paukenschlag:
>
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1.682ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1.145ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1.079ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 108305.744ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 153373.369ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 182635.019ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 211888.918ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 259236.570ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 306584.620ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 353937.783ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 401282.356ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 448630.530ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 495977.359ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 545253.889ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 570622.489ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 596074.646ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 621390.748ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 646879.664ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 672747.328ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 697938.048ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 723123.511ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 748312.305ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 773501.039ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 798688.559ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 823876.562ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 858944.162ms
>
> Wie geht denn das überhaupt? Wo bleiben die solange? 800s?

der ist gut!  so dolle hab ich das auch noch nie gesehen.
dieses ploetzliche "pings verschlucken" kenn ich aus dem adhoc mode,
den haben auch schon andere beobachtet, da waren die pings auch bis zu
ein/zwei min weg und kamen dann so extrem verzoegert doch zurueck.
dagegen sollte svenola's txstop patch helfen. aber du sagst ja das
setup ist master client. ob der dann auch vielleicht verwendet werden
muss?
damit ich richtig im bilde bin, atheros auf welcher plattform?
kamikaze trunk?
bgscan ist 0 und was ist denn, wenn du wds mal auf 1 stellst und die
ap mac eintraegst?

> Anderer Traffic (auch pings) gehen währendessen normal und ein neu gestarter
> arping springt auch sofort an:
>
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1743816.989ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1774923.871ms
>
> Sent 3002 probe(s) (2 broadcast(s))
> Received 3058 reply (0 request(s), 0 broadcast(s))
> root at NicoAP5G:~# arping -i ath0 104.0.200.2
> ARPING to 104.0.200.2 from 104.0.200.2 via ath0
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1.245ms
> Unicast reply from 104.0.200.2 [0:b:6b:57:12:dc] 1.078ms
>
>
> Schlaflos in Seattle, Ratlos in Weissensee
>
> Gruß
> Frithjof
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>