search

freifunk-gluon / gluon

a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes
https://gluon.readthedocs.io
Other
543 stars 324 forks source link

L2TP support #752

Closed neocturne closed 7 years ago

neocturne commented 8 years ago

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

MPW1412 commented 8 years ago

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 client (l2tp_client.c) is badly structured and needs refractoring. We plan to start that tonight.

neocturne commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 :+1:

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

christf commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

lcb01a commented 8 years ago

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 commented 8 years ago

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

jplitza commented 8 years ago

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 commented 8 years ago

Yup that's the thing missing.

wattnpapa commented 8 years ago

Any News?

Wlanfr3ak commented 8 years ago

Anything new about this Issue ?

Adorfer commented 7 years ago

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

rotanid commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

for reference: https://github.com/ffrl/ffrl-packages/issues/8

Adorfer commented 7 years ago

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 commented 7 years ago

I've created a pushrequest for this issue: https://github.com/freifunk-gluon/gluon/pull/947

lcb01a commented 7 years ago

New PR for this issue is: https://github.com/freifunk-gluon/gluon/pull/978

neocturne commented 7 years ago

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

A-Kasper commented 7 years ago

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 https://github.com/freifunk-gluon/gluon/issues/752#issuecomment-285759054, or mute the thread https://github.com/notifications/unsubscribe-auth/AIA7Us0ljnDrcnTg5XDLulUNHH1tqWRBks5rkaGKgaJpZM4IW-82 .

mitar commented 7 years ago

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.