l2tp Tester gesucht!

Robert Langhammer rlanghammer at web.de
Mo Mär 7 23:51:08 CET 2016


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
>
>
>


-------------- 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/20160307/413c1216/attachment-0002.sig>


Mehr Informationen über die Mailingliste franken-dev