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

[Frithjof Hammer]

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
--- 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? 
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