L2TP support

[neocturne]

Some communities are already experimenting with L2TP to connect Gluon nodes. It would be great to have this in the official Gluon repo.

[MPW1412]

Yeah, that sounds great.

I think the most advanced repo for the tunneldigger is the FFRL repository: https://github.com/ffrl/tunneldigger

The patch for fixing the broker selection by usage is already merged (https://github.com/ffrl/tunneldigger/commit/5d34ae6a1e1cecc2b5cfb72fb02bf3e6b78a763e).

Questions to me are:

• The tunneldigger brings its own mechanism to limit the used bandwith. Shall we use that in future? The client communicates its wished maximum bandwith to the server which then throttles the connection to that limit.
• The tunneldigger has support for auto negotiated MTU, but as far as I know, no community uses it, because Batman can't handle different MTU sizes. Maybe you know more about that problem? Auto MTU negociation would be great.
• There's no way to block nodes like on fastd, as there is no authentication process. That might become a problem in the future.
• No ipv6 support at all. The upstream maintainer wlanslovenija signaled good will to merge patches to enable ipv6 support, but there's no working implementation so far. (L2TP works with ipv6, but the tunneldigger and its negotiation process don't.)

The client (l2tp_client.c) is badly structured and needs refractoring. We plan to start that tonight.

[neocturne]

• A similar feature for limiting the bandwidth on the remote side is planned for fastd, but for now using the simple-tc package for both tunnel solutions may be easier. I'm not sure...
• Yes, batman-adv is unable to deal with different MTUs in a forwarding path (and compat 15 would not be able to re-fragment on middle nodes without reassembling a packet...), so in Gluon, we've patched batman-adv to always fragment to fit an MTU of 1280...
  Having different tunnel MTUs (that are at least 1280) doesn't hurt either though (it just doesn't help), so we can just enable the auto negotiation and will actually be able to use the higher MTU as soon as we have a layer 3 routing protocol
• Missing IPv6 support is indeed an issue to be solved.

If we have enough space to fit both fastd and tunneldigger on our nodes, we could even change the expert mode package that lets the user choose between "security" and "performance" to switch from fastd to L2TP instead of switching fastd to methd "null".

[Adorfer]

@MPW1412

The tunneldigger has support for auto negotiated MTU,

Due to current batman-v15 refragmentation issues i susppose we are splitting to 1280 anyways, correct?

There's no way to block nodes like on fastd,

I assume that blocking nodes can be done on the node-id, since it's invoced to the wrapper-scripts.
(where you set up your bandwith-stuff depending on nodes too...)

[lcb01a]

Yes, batman-adv is unable to deal with different MTUs in a forwarding path (and compat 15 would not be able to re-fragment on middle nodes without reassembling a packet...), so in Gluon, we've patched batman-adv to always fragment to fit an MTU of 1280... Having different tunnel MTUs (that are at least 1280) doesn't hurt either though (it just doesn't help), so we can just enable the auto negotiation and will actually be able to use the higher MTU as soon as we have a layer 3 routing protocol

If batman always uses 1280 when fragmenting a frame then we could just stick with a statically asigned MTU.
Tunneldigger currently changes the MTU dynamically after the initial interface has been setup. So we will have to make sure that a changing MTU is no problem for either Batman or later on Babel.
On the gateways / supernodes this could be achieved with several bridge interfaces to cover the different MTU values. Tunneldigger offers a hook which trigers a script when the MTU changes, this script then attaches the interface to the correct bridge.

Missing IPv6 support is indeed an issue to be solved.

Missing IPv6 support is also on the agenda of wlan slovenia: https://dev.wlan-si.net/ticket/1187
It would be great if you could help out wlan slovenija as well by contributing 👍

I will prepare a merge of the tunneldigger gluon packages into the main repository. 😄

[christf]

having a security and a performance mode would be great. But couln't fastd reach similar performance resulting in reduced complexity in the image build?

[wusel42]

Tunneldigger gains it's speed advantage by using a tunneling method supported by the kernel; in fastd, each packet causes a context-switch (kernel-context -> user-context), whereas L2TP stays within the kernel-context. Unless fastd is moved into kernel-space, I don't see how it could compete with in-kernel methods like GRE, L2TP, IPIP, ... And the issue is exhibited mostly on low-end embedded CPUs; the (x86) CPU in a Futro has no issue doing OpenVPN at 50 MBit/sec, but even an RPi v2 cannot keep up beyond about 25 MBit/sec.

[ghost]

The FFRL tunneldigger doesn't include any usable respondd data providers.

[lcb01a]

The FFRL tunneldigger doesn't include any usable respondd data providers.

For 2015.1.2 it is working, but since the switch to C it would be great if someone else could take care of that. My C skills are a bit rusty.
Please provide a pull-request to the original FFRL Gluon package repository:
https://github.com/ffrl/ffrl-packages

I will glady implement this into the pull request to the Gluon main repository

[ghost]

I don't have any C skills that could be rusty 😁
I just wanted to mention that this is something that has to be done before the package is part of gluon.

[jplitza]

FTR: fastd currently reports in the nodeinfo part its version and whether it's enabled, and in the statistics part which neighbours it is connected to for how long.

The 2015.1-style announce code in the ffrl repo reports whether tunneldigger is enabled in the nodeinfo part (can be copied 1:1 from the fastd module) and… nothing (o_O?) in the statistics part.

So presumably, those who insist on a respondd provider are missing the list of connected neighbours?

[ghost]

Yup that's the thing missing.

[wattnpapa]

Any News?

[Wlanfr3ak]

Anything new about this Issue ?

[Adorfer]

Any chance for native L2TP? is it just the Respondd missing

[rotanid]

perhaps also "No ipv6 support at all"? for me that's a no-go...
and no one volunteered to do the necessary changes or improvements, so THAT is the real problem i guess ;)

[A-Kasper]

I would also like to see the l2tp support added to gluon

https://github.com/ffrl/tunneldigger
https://github.com/ffrl/ffrl-packages
https://github.com/ffrl/ffrl-tunneldigger-docs

@rotanid the missing IPv6 is not a problem, more a "nice to have". There aren't any ipv6 only isps in germany by now. tunneldigger is much better, also on dslight connections. It would be nice to connect to vpn servers via ipv6, yes.. but ipv4 still exists and works fine. so this should not stop us from implementing l2tp. the tunnel itself is layer2, so IPv6 connections from clients through the tunnel shouldnt be affected...

[rotanid]

for reference: ffrl/ffrl-packages#8

[Adorfer]

What really lacks for the moment (as far as i am aware): respondd support for L2TP. It looks like there is missing a lot of data which can only be "indirectly" (e.g. by knowing the MAC of the L2TP servers)

[lcb01a]

I've created a pushrequest for this issue: #947

[lcb01a]

New PR for this issue is: #978

[neocturne]

Support has been merged thanks to the work of @lcb01a :)

[A-Kasper]

Nice! Thank you! 2017-03-10 20:16 GMT+01:00 Matthias Schiffer <notifications@github.com>:

…

Support has been merged thanks to the work of @lcb01a <https://github.com/lcb01a> :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#752 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA7Us0ljnDrcnTg5XDLulUNHH1tqWRBks5rkaGKgaJpZM4IW-82> .

[mitar]

IPv6 support for Tunneldigger was selected as one of this years GSoC projects. So work on https://dev.wlan-si.net/ticket/1187 will start soon.

Some comments for things mentioned above:

The tunneldigger brings its own mechanism to limit the used bandwith. Shall we use that in future? The client communicates its wished maximum bandwith to the server which then throttles the connection to that limit.

Server helping limiting is the only way you can limit bandwidth well in both directions. You cannot do that only on the node. Server has to participate.

There's no way to block nodes like on fastd, as there is no authentication process. That might become a problem in the future.

We think that for authentication, authorization, and encryption one can use IPSec. But we could discuss such feature and see. How would you identify nodes to be blocked?

BTW, the best way to reach us it to open issues on our Trac, or talk to us on our chat.