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

Mi Nov 18 01:30:11 CET 2015

Hi,

ich würde behaupten ja. Gut wäre, wenn min. ein Test direkt über das LAN, also
nicht das WLAN, geht. Aus den Tests sollte auch hervorgehen welche Instanz des
VPNs du nutzt. War hier der Fall.

Gruß Philipp

On Sun, Nov 15, 2015 at 10:35:20PM +0100, Christian Hammel wrote:
> 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
-------------- 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/20151118/72893dda/attachment.sig>