[Berlin-wireless] Verklärung-core via Vaterhaus und BBB ins Internet - schlechte Verbindung

[Sven Roederer]

Hallo,


kurz vor Weihnachten ist hier im SüdOsten der übliche DSL-Uplink via 
"Kosmos-WaMa" ausgefallen und der Traffic wird vornehmlich via Vaterhaus 
an ein Gateway im BBB geschickt.

Diese Verbindung ist aber effektiv nicht nutzbar.
Initial hatte wohl die AirOS-Funknstrecke zum Vaterhaus ein Problem (Im 
AirOS webdashboard war der Link aktiv, aber die Gegenstelleninfos nicht 
vorhanden), was sich durch einen Software-reboot geklärt hat. Diese 
WLAN-Verbindung läuft, auch wenn gelegentlich mal 20% der Pings verloren 
gehen.


Das eigenliche Problem scheint aber irgendwo im BBB oder den 
Smartgateways zu liegen (l105-gw, ohlauer, und stargarder??)


Beispiel: ping Verklaerung --> 9.9.9.9 via l105-gw

root at Verklaerung-core:~# ping -c 5 9.9.9.9
PING 9.9.9.9 (9.9.9.9): 56 data bytes
64 bytes from 9.9.9.9: seq=0 ttl=55 time=8873.333 ms
64 bytes from 9.9.9.9: seq=1 ttl=55 time=10225.124 ms
--- 9.9.9.9 ping statistics ---
5 packets transmitted, 2 packets received, 60% packet loss
round-trip min/avg/max = 8873.333/9549.228/10225.124 ms

root at Verklaerung-core:~# tcpdump -ni br-lan.20 |grep 9.9.9.9
02:18:53.407944 IP 10.31.77.254 > 10.31.127.160: IP 10.31.77.254 > 
9.9.9.9: ICMP echo request, id 1550, seq 0, length 64 (ipip-proto-4)
02:18:54.408397 IP 10.31.77.254 > 10.31.127.160: IP 10.31.77.254 > 
9.9.9.9: ICMP echo request, id 1550, seq 1, length 64 (ipip-proto-4)
02:18:55.412393 IP 10.31.77.254 > 10.31.127.160: IP 10.31.77.254 > 
9.9.9.9: ICMP echo request, id 1550, seq 2, length 64 (ipip-proto-4)
02:18:56.416378 IP 10.31.77.254 > 10.31.127.160: IP 10.31.77.254 > 
9.9.9.9: ICMP echo request, id 1550, seq 3, length 64 (ipip-proto-4)
02:18:57.420392 IP 10.31.77.254 > 10.31.127.160: IP 10.31.77.254 > 
9.9.9.9: ICMP echo request, id 1550, seq 4, length 64 (ipip-proto-4)
02:19:02.280671 IP 9.9.9.9 > 10.31.77.254: ICMP echo reply, id 1550, seq 
0, length 64
02:19:04.633079 IP 9.9.9.9 > 10.31.77.254: ICMP echo reply, id 1550, seq 
1, length 64

Eine RTT von ca. 9 Sekunden kann ich mir nicht sinnvoll erklären und ist 
natürlich auch praktisch nicht nutzbar.


Beispiel AHof-frieden03 --> 9.9.9.9 via Ohlauer

--- 9.9.9.9 ping statistics ---

5 packets transmitted, 0 packets received, 100% packet loss
root at Ahof-frieden03:~# ping -c 5 9.9.9.9
PING 9.9.9.9 (9.9.9.9): 56 data bytes
64 bytes from 9.9.9.9: seq=0 ttl=52 time=1868.525 ms
64 bytes from 9.9.9.9: seq=1 ttl=52 time=2019.677 ms
64 bytes from 9.9.9.9: seq=2 ttl=52 time=2684.014 ms
64 bytes from 9.9.9.9: seq=3 ttl=52 time=3969.190 ms
--- 9.9.9.9 ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max = 1868.525/2635.351/3969.190 ms

root at Verklaerung-core:~# tcpdump -ni br-lan.20 |grep 9.9.9.9
02:54:46.541991 IP 10.36.217.97 > 10.31.11.96: IP 10.36.217.96 > 
9.9.9.9: ICMP echo request, id 2354, seq 0, length 64 (ipip-proto-4)
02:54:47.541279 IP 10.36.217.97 > 10.31.11.96: IP 10.36.217.96 > 
9.9.9.9: ICMP echo request, id 2354, seq 1, length 64 (ipip-proto-4)
02:54:48.406656 IP 9.9.9.9 > 10.36.217.96: ICMP echo reply, id 2354, seq 
0, length 64
02:54:48.545752 IP 10.36.217.97 > 10.31.11.96: IP 10.36.217.96 > 
9.9.9.9: ICMP echo request, id 2354, seq 2, length 64 (ipip-proto-4)
02:54:49.542243 IP 10.36.217.97 > 10.31.11.96: IP 10.36.217.96 > 
9.9.9.9: ICMP echo request, id 2354, seq 3, length 64 (ipip-proto-4)
02:54:49.559009 IP 9.9.9.9 > 10.36.217.96: ICMP echo reply, id 2354, seq 
1, length 64
02:54:50.543065 IP 10.36.217.97 > 10.31.11.96: IP 10.36.217.96 > 
9.9.9.9: ICMP echo request, id 2354, seq 4, length 64 (ipip-proto-4)
02:54:51.223803 IP 9.9.9.9 > 10.36.217.96: ICMP echo reply, id 2354, seq 
2, length 64
02:54:53.505580 IP 9.9.9.9 > 10.36.217.96: ICMP echo reply, id 2354, seq 
3, length 64

Von 4 VErsuchen mit jeweils 5 Ping-requests, sind nur 1 mal ein paar 
Echo-replies angekommen, die requests aber alle im tcpdump der 
Verklärung Richtung Funkstrecke Vaterhaus rausgegangen. Die RTT liegt 
bei ca. 3 sekunden, falls eine Antwort kommt.


Ich hab keine Idde, ob das jetzt an den Smartgateways liegt oder das 
Routing hierher nicht stimmt. Wer hat eine Idee zur Ursache?



GRuss Sven