l2tp Tester gesucht!

Di Mär 8 08:37:25 CET 2016

hi

Fürth hängt sich mal mit dran :) Hier klappt auch alles einwandfrei.

Da es in Fürth nur meinen Server und nue1 gibt, ist da ein testen
relativ ungefährlich. Ich announce sicher die deutlich höhere Bandbreite
als nue1 und im normalfall haben wir eine ähnliche Verbindungsqualität.
Mit gefixter Batman Gatewayselection landet ihr also relativ sicher auf
meinen Server (bisher hab ich noch keinen Router gesehen der gefixt ist
und nue1 ausgewählt hat ;))

Das heißt fühlt euch frei das ganze in Fürth mal zu testen. Sehr ans
Herz würde ich es delphiN (im CC) legen, damit wir den Tunnel mal unter
Dauerlast testen können. Es gibt ja jederzeit den Fallback zu fastd wenn
was schief läuft. Aber natürlich ist auch jeder andere in Fürth zum
testen eingeladen

Am besten nen extra Router nehmen und diese Firmware flashen:

http://langhammer-mainberg.de/fff/firmware/
oder eine eigene wo die Gatewayselection bereits gefixt ist und die l2tp
Kernelmodule enthalten sind.

Danach diese Anleitung durchführen:
https://wiki.freifunk-franken.de/w/L2TP_und_Tunneldigger#Am_Router

l2tunnel auf on stellen (gerne auch mal dual testen, was da passiert)
und ab geht die Post (hoffentlich ;))

bei Probleme einfach lauthalts los brüllen.

mfg

Christian

Am 08.03.2016 um 00:51 schrieb mayosemmel:
> Hallo zusammen,
> 
> in Nürnberg gibt es nun auch einen Server mit Tunneldigger. Wer testen
> will also immer drauf los!
> Nach den ersten Testergebnissen bin ich sehr begeistert. Zum einen ist
> der Datendurchsatz ca. doppelt so hoch (dann limitiert das 16k DSL) zum
> anderen, sind die Latenzen sehr viel stabiler. Vorher hatte ich zur
> FF-internen IP von meinem GW zwischen 30ms und 150ms jetzt liege ich
> zwischen 32ms und 38ms.
> 
> Bezüglich dem unteren Vorschlag von Christian bzw. Robert:
> Weiß jemand was passiert, wenn der Client diese Option nicht
> verarbeitet? Fragmentiert dann der Router oder gehen die Pakete kaputt?
> Wenn der Router fragmentiert, sollte man das allgemein mal machen, da es
> dadurch dann nur besser werden kann.
> 
> Viele Grüße
> Jan
> 
> Am Montag, den 07.03.2016, 23:51 +0100 schrieb Robert Langhammer:
>> Hallo Cristian,
>>
>> die Idee kommt einem als erstes-  Internet 1500 - l2tp - batman - xxxx
>> =  Client mtu.
>>
>> Man muss also die MTU der Clients umstellen. Da gibt es auch eine DHCP
>> option interface-mtu xyz
>> Ich glaube aber nicht, dass alle Clients diese Option verarbeiten. Hat
>> da schon jemand Erfahrungen damit gemacht?
>> Robert
>>
>> Am 07.03.2016 um 23:35 schrieb Christian Dresel:
>>> Guten Abend
>>>
>>> Ich dachte bisher eigentlich, dass sich das MTU Problem nicht lösen
>>> lässt, aber diese Mail brachte mich auf eine Idee die ich mal
>>> "ansprechen" möchte, vielleicht ist die Antwort darauf auch nur, geht
>>> nicht weil wegen weiß Gott...
>>>
>>> Am 07.03.2016 um 13:52 schrieb Robert Langhammer:
>>>> Hallo Dominik,
>>>>
>>>> da warst du jetzt schneller als ich.
>>>>
>>>> In der default Configuration macht der tunneldigger / broker 1500 - 54 =
>>>> 1446.
>>>> Ist es sinnvoll die 8Byte für Adsl noch weg zu nehmen. Im LAN, wo der
>>>> Router dranhängt haben wir die üblichen 1500 und Über Kabel sind es auch
>>>> 1500.
>>>>
>>>> So wie ich das verstanden habe, wird immer fragmentiert, da die
>>>> Wlan-Clients und unser w2ap eine 1500 mtu haben. Dann kommt batman dazu
>>>> und wir bräuchten >1500 aber durchs Internet geht nicht mehr.
>>> warum muss w2ap denn 1500 haben? Wenn w2ap (angenommen) 1350 hat und
>>> Batman seine 28 Bytes (glaub ich) drauf packt, sind wir in dem Bereich
>>> was tunneldigger durchjagen kann und müssen hier nicht fragmentieren.
>>> Man kanns jetzt noch exakt ausrechnen, das hier ist nurn Beispiel.
>>>
>>> Überseh ich irgendwas?
>>>
>>> mfg
>>>
>>> Christian
>>>
>>>> Bin ich da richtig?
>>>>
>>>>
>>>> Bremst das Fragmentieren spürbar?
>>>>
>>>>
>>>> Am 07.03.2016 um 13:34 schrieb Dominik Heidler:
>>>>> Hi,
>>>>>
>>>>> ich habe es gefunden:
>>>>>
>>>>> https://github.com/wlanslovenija/tunneldigger/blob/master/client/l2tp_client.c#L63
>>>>>> // L2TP data header overhead for calculating tunnel MTU; takes
>>>>>> // the following headers into account:
>>>>>> //
>>>>>> //   20 bytes (IP header)
>>>>>> //    8 bytes (UDP header)
>>>>>> //    4 bytes (L2TPv3 Session ID)
>>>>>> //    4 bytes (L2TPv3 Cookie)
>>>>>> //    4 bytes (L2TPv3 Pseudowire CE)
>>>>>> //   14 bytes (Ethernet)
>>>>>> //
>>>>>> #define L2TP_TUN_OVERHEAD 54
>>>>> Das bedeutet, dass L2TPv3 1 Byte *mehr* overhead hat, als FastD.
>>>>> Allerdings fahren wir fastd aktuell mit einer unnütig niedrigen MTU (1492-(52+14)=1426).
>>>>> Da wir keine Verschlüsselung verwenden, könnten wir fastd theoretisch mit einer MTU von
>>>>> 1439 laufen lassen.
>>>>> Aber so, wie es aktuell läuft, beträgt der fastd overhead 66 statt 53 byte.
>>>>>
>>>>> Somit bringt uns der Wechsel eine Verbesserung um 12 byte.
>>>>>
>>>>> Grüße,
>>>>> Dominik
>>>
>>>
>>>
>>
>>
>> -- 
>> franken-dev mailing list
>> franken-dev at freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> 
> 

-- 
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: ChristianD at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160308/7a7282c9/attachment-0002.sig>