[Berlin-wireless] Datenrate über vpn03 bei größeren Dateien?

[Christian Hammel]

Hallo Philipp,

ich teste es der Tage mal aus.
Helfen solche Netalyzr-Protokolle (wie der Link ganz unten) eigentlich 
überhaupt beim Suchen?

Gruß

Christian

Am 15.11.2015 um 21:33 schrieb Philipp Borgers:
> Moin,
>
> ich habe jetzt auf allen Instanzen das established timeout auf zwei Minuten
> gesetzt. Außerdem haben wir auf allen Instanzen die fast-io Option
> eingeschaltet, weil sie so verlockend klingt. Die SO_SND/RCV-Buffer werden jetzt
> nicht mehr von openvpn auf 65k gesetzt [1]. Wir übernehmen den Kernel-Default bzw.
> überlassen dem Kernel die Optimierung der Buffer. Den Clients/Routern versuchen
> wir diese Änderungen ebenfalls über den Server mitzuteilen.
>
> Leider haben wir immer noch keine aussagekräfitgen Client-Metriken, deshalb ist
> das eher eine Blindflug-Optimierung. Falls euch etwas auffällt (positiv/negativ)
> meldet euch bitte.
>
> Gruß Philipp
>
> [1] https://github.com/freifunk-berlin/puppet-vpn03/commit/e81604fb5a8ed48a64eab3d608691cdc48ca72bb
>
> On Thu, Nov 12, 2015 at 11:53:47PM +0100, Philipp Borgers wrote:
>> Moin,
>>
>> unsere VPN-Instanzen hatten mal wieder Probleme mit dem Connection-Tracking. Die
>> maximale Größe wurde erreicht :/
>>
>> Ich werde in den nächsten Tagen den folgenden Wert auf zwei Minuten setzen:
>>
>> net.ipv4.netfilter.ip_conntrack_tcp_timeout_established
>>
>> Außerdem muss ich mal gucken warum unsere sysctl Konfiguration nicht von
>> /etc/init.d/procps beim System-Start angewendet wird.
>>
>> Das ist aber nicht zwingend eine Erklärung für dein Problem.
>>
>> Es gibt auch noch mögliche Optimierungen, die ich gerne von vpn03d auf die
>> anderen Instanzen übernehmen würde. Sobald ich etwas Ruhe habe, würde ich das
>> versuchen.
>>
>> Gruß Philipp
>>
>> On Thu, Nov 12, 2015 at 10:43:25PM +0100, Christian Hammel wrote:
>>> Hallo,
>>>
>>> mein FF-Router (Wuthenow9) hängt am Kabel-Deutschland-Anschluss ( 25MBit/s
>>> (Download) / 1 MBit (upload)), der ohne FF die Werte auch erreicht.
>>>
>>> Seit ich eure Tipps zur MTU=1300 umgesetzt habe, kommen bei meinen
>>> Freifunk-Clients 10 bis 12 MBit/s (Download) an. Upload ist bei 0,9 MBit/s.
>>> Vorher war es deutlich weniger.
>>>
>>> Das ist also so weit ganz ordentlich.
>>>
>>> Bei größeren Downloads, speziell, wenn Linux sich größere Updates (z.B.
>>> irgendwelche Browser) von ubuntu-mirrors holt, geht die Datenrate allerdings
>>> deutlich nach unten. Sowohl bei Funk- als auch bei Kabel-Clients.
>>>
>>> Kann mir jemand aus den nachfolgenden Infos sagen, ob das an meiner Konfig
>>> (Firewall, NAT,..) liegt, oder ob ich selbst da sowieso nichts machen kann?
>>>
>>> Danke
>>>
>>> Christian
>>>
>>>
>>>
>>>
>>> Router: WDR 4300 mit Kathleen 0.1.2.
>>>
>>> MTU in /etc/config/openvpn auf 1300, außerdem die 1300 in LuCi bei den
>>> erweiterten Einstellungen der WAN und der DHCP-Schnittstellen nochmal
>>> manuell eingetragen.
>>>
>>> Firewall-Zoneneinstellung für WAN -> freifunk ist: Eingang zulassen, Ausgang
>>> zulassen, Weitergeleitet zurückweisen, NAT an (wofür brauche ich das
>>> eigentlich?), MSS-Korrektur aus.
>>>
>>> In /etc/config/openvpn steht (u.a.)
>>> 	option mssfix '1300'
>>>   	option tun_mtu '1300'
>>>
>>>
>>> Der Monitor zeigt eine schwankende ping-Droprate mit seltsamen Zahlenwerten
>>> (2k %)an:
>>> <http://monitor.berlin.freifunk.net/detail.php?p=ping&t=ping_droprate&h=Wuthenow9&s=604800&x=800&y=350>
>>>
>>> Netalyzr meckert über Fehler beim Transport von fragmentiertem UDP-Traffic
>>> (und zwar unabhängig vom Endgerät sowohl von 1 Linux-PC per Kabel als auch
>>> von einem Lappi per Funk als auch vom Android-Telefon):
>>>
>>> The client was unable to receive fragmented UDP traffic. The most likely
>>> cause is an error in your network's firewall configuration or NAT.
>>> The maximum packet successfully received was 1272 bytes of payload.
>>> The path between your network and our system supports an MTU of at least
>>> 1500 bytes, and the path between our system and your network has an MTU of
>>> 1300 bytes. The path MTU bottleneck that fails to properly report the ICMP
>>> "too big" is between 185.66.195.250 (das ist vpn03d) and *. The path between
>>> our system and your network does not appear to report properly when the
>>> sender needs to fragment traffic.
>>>
>>> Details (auch der tracert, der zu der Bottleneck-Angabe gehört): <http://n2.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-4223-0758abf4-7136-484c-9fec>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Christian Hammel, Wuthenowstr. 9, 12169 Berlin
>>>
>>> _______________________________________________
>>> 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
>
>
>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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
>

_______________________________________________
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