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

[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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20151115/fad2cd29/attachment.sig>
-------------- nächster Teil --------------
_______________________________________________
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