[Berlin-wireless] Verklärung-core via Vaterhaus und BBB ins Internet - schlechte Verbindung
Sven Roederer
freifunk at it-solutions.geroedel.de
Di Jan 9 03:07:38 CET 2024
Mahlzeit,
hat etwas gedauert, aber hier die Daten vom 4.1. - gemessen von
"Verklaerung-core".
HostLoss% Snt Last Avg Best Wrst StDev
1. mid6.vaterhaus-core.olsr 0.0% 23 3.0 3.9 1.8
8.8 1.9
2. mid7.zwingli-core.olsr 0.0% 23 7.5 5.6 2.7
13.3 2.6
3. mid1.sama-core.olsr 0.0% 23 6.2 7.1 4.7
10.2 1.7
4. mid9.saarbruecker-gw.olsr 0.0% 22 6.3 7.1 5.2
14.5 2.0
HostLoss% Snt Last Avg Best Wrst StDev
1. mid9.saarbruecker-gw.olsr 2.8% 36 13.5 15.2 6.2
155.4 24.6
2. ge-0-1-8-0.bsa1-cpe1.de.syseleven.net 2.8% 36 12.4 14.4 6.9
96.6 14.8
3. ktel.bak1-r1.syseleven.net 0.0% 36 9.0 15.5 7.8
117.4 17.8
4. 45.153.82.10 0.0% 35 79.8 13.0 7.9
79.8 12.0
5. r4-ber1-de.as5405.net 5.7% 35 115.1 14.6 7.4
115.1 18.2
6. as42.bcix.de 2.9% 35 15.5 14.4 7.6
71.9 10.9
7. dns9.quad9.net 0.0% 35 14.0 13.2 7.4
73.8 11.0
Smartgateway war jetzt saarbruecker-gw (das u.g. 3. gateway - nicht
stargarder). Entweder hat der Reboot der Antenne am Vaterhaus das
Problem beseitigt oder die Route ist durch andere effekte im BBB wieder
nutzbar geworden. Zu der Zeit als ich die Störung beobachtet hab, konnte
ich alle 3 genannten Smartgateways problemlos erreichen, aber die Daten
im IPIP-Tunnel sind in irgendeiner Richtung verloren gegangen. Da ich
die Gateways problemlos erreichen konnte hatte ich weniger die Route via
Vaterhaus ins BBB im Verdacht. Aber wenn der Neustart der Antenne die
einzige Änderung war, sind dort wohl selektiv bestimmte Pakete unter den
Tisch gefallen.
Vaterhaus-Verklärung über 60 Ghz: sehe ich immernoch kritisch, wegen der baulichen Möglichkeiten. schon die NanoBeam kann ja nur zur Hälfte aus dem Fenster gucken ...
GRuss Sven
On 02.01.24 16:25, ff at xayax.de wrote:
> Hi
>
> Vaterhaus ist gerade über die 60Ghz Verbindung mit der Zwingli gut angebunden (1Gbit).
> Kannst Du mal versuchen, das SmartGateway auszumachen? Dann funktioniert ja auch Traceroute und wir können schauen, woran es liegt?
> Ich hab die PowerBeam mal neu gestartet (DFS hatte den Kanal geändert) - eventuell hilft das auch?
> Ansonsten könnten wir für die Verbindung Vaterhaus-Verklärung auch mal über 60 Ghz nachdenken?
>
> lg
> kaya
>
>> Am 02.01.2024 um 03:16 schrieb Sven Roederer <freifunk at it-solutions.geroedel.de>:
>>
>> 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
>>
>> _______________________________________________
>> Freifunk-TK mailing list -- freifunk-tk at lists.geroedel.de
>> To unsubscribe send an email to freifunk-tk-leave at lists.geroedel.de
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
Mehr Informationen über die Mailingliste Berlin