[Berlin-wireless] Packet Loss zum VPN03 woher?

[Malte]

On Wed, 6 May 2015, Bastian wrote:

> spontan würde ich auch auf MTU-Probleme tippen. Speziell Provider mit 
> CGN/DS-Lite haben damit Issues.

Der Anschluss ist ja im Bridge-Modus inkl. öffentlicher IPv4-Adresse, also 
kein DS-Lite. mssfix ist an. Das Fehlerbild passt eigentlich nicht; bei 
falscher MTU laufen soweit ich weiß bestimmte Dienste/Server gar nicht, 
andere problemlos. Zeitabhängiges Verhalten oder "50% Packet Loss" sollte 
es da nicht geben.

Ich habe trotzdem nochmal experimentiert, auch mit link_mtu 1400 habe ich 
im Moment 30% Packet Loss. :-(

> Tritt das Problem bei allen vpn03-Servern auf? Also hast du mal die drei 
> IPv4-Adressen gezielt durch probiert?

Das Problem tritt an allen VPN03-Servern auf, aber eben nur von dem einen 
Anschluss aus...

Grüße,
Malte

> Gruß
> Bastian
>
> On 05/06/2015 09:41 PM, Malte wrote:
>> Hi!
>>
>> Setup: Kathleen 0.1.0 auf 3600 hinter einer Fritzbox hinter einem
>> KD-Kabelmodem (Anschluss relativ neu geschaltet, aber auf "alten"
>> Bridge-Modus umkonfiguriert, zur Sicherheit trotzdem mit mssfix).
>> Internet-Sharing an. Keine WLAN-Verbindung zum BBB.
>>
>> 1. Das Problem: Das Freifunk-Netz hinter dem FF-Router geht mäßig gut;
>> große Downloads gehen gut, aber Webseiten mit vielen Elementen hängen
>> häufig.
>>
>> 2. Im LAN vor dem FF-Router geht das Netz prima.
>>
>> 3. Direkt auf dem FF-Router geht ein "ping 8.8.8.8" ohne nennenswerten
>> Packet Loss.
>>
>> 4."ping -I ffvpn 8.8.8.8" bringt häufig Packet Loss >70%, verhexterweise
>> ist das aber anscheinend zeitabhängig, manchmal klappt's auch
>> problemlos. Im Moment sieht das besonders traurig aus [1].
>>
>> Woher kann sowas kommen? Wie debuggt man sowas? Die OpenVPN-Meldungen
>> per logread sehen unverdächtig aus, komisch ist da nur, dass der
>> Verbindungsaufbau manchmal lange dauert (30 Sekunden vom "UDPv4 link
>> remote" zu "Peer Connection Initiated" oder Timeouts kommen da schon
>> vor), das ist bei diesem Packet Loss aber wohl nicht ungewöhnlich.
>>
>> Ich wollte auch mal testweise OpenVPN über TCP laufen lassen, aber das
>> klappt nicht so ohne weiteres; Verbindungsaufbau geht sofort, der Tunnel
>> bricht dann aber auch sofort wieder ab [2]. Hat das jemand mal mit
>> Kathleen getestet?
>>
>> KD bzw. VPN03 allgemein bockt nicht; bei einem anderen KD-Anschluss in
>> Berlin sehe ich (zeitgleich) diese Probleme nicht. Der betroffene
>> Anschluss wird aber etwas anders geroutet (über *-isp.superkabel.de,
>> dann ip5886c22c.dynamic.kabel-deutschland.de; bei dem "guten" Anschluss
>> geht's nicht über superkabel.de).
>>
>> Tipps? Völlig von Verdacht freigesprochen habe ich die Fritzbox noch
>> nicht, aber tippe eigentlich eher auf seltsame KD-Überlast...
>> Erfahrungen? Und vor allem: Was tun?
>>
>> Grüße,
>> Malte
>>
>> [1]
>> # ping -I ffvpn 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8): 56 data bytes
>> 64 bytes from 8.8.8.8: seq=0 ttl=60 time=13.524 ms
>> 64 bytes from 8.8.8.8: seq=16 ttl=60 time=76.833 ms
>> 64 bytes from 8.8.8.8: seq=139 ttl=60 time=11.457 ms
>> 64 bytes from 8.8.8.8: seq=163 ttl=60 time=20.143 ms
>> 64 bytes from 8.8.8.8: seq=170 ttl=60 time=49.486 ms
>> 64 bytes from 8.8.8.8: seq=174 ttl=60 time=79.728 ms
>> 64 bytes from 8.8.8.8: seq=178 ttl=60 time=12.462 ms
>>
>> [2]
>> (OpenVPN auf VPN03 via TCP)
>> daemon.notice netifd: Interface 'ffvpn' is now up
>> daemon.notice openvpn(ffvpn)[23212]: /etc/openvpn/ffvpn-up.sh ffvpn 1500
>> 1528 172.31.xxx.xxx 255.255.255.0 init
>> daemon.notice openvpn(ffvpn)[23212]: Initialization Sequence Completed
>> daemon.err openvpn(ffvpn)[23212]: Connection reset, restarting [0]
>>
>>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>>
>
>
>