[OpenWrt-Devel] modules: package l2tp_ip6.ko in kmod-l2tp-ip6

r45593 includes l2tp_ip6 in the kmod-l2tp-ip package.
This is not feasible for several reasons:
 - in a given setup one usually uses either l2tp_ip or
   l2tp_ip6, but never both
 - l2tp_ip doesn't depend on ipv6
 - versioning of kmod-l2tp-ip doesn't indicate that it
   now does include support for L2TP-over-IPv6

I did waste some thoughts and actually my inital approach
to include l2tp_ip6 looked very much like what was applied
in r45593. However, there might be people making use of
kmod-l2tp-ip on devices not having the resources to also
include kmod-ipv6, and we usually prefer the most atomic
packaging possible.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 package/kernel/linux/modules/netsupport.mk | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

On 02.05.2015 13:33, Daniel Golle wrote:
> r45593 includes l2tp_ip6 in the kmod-l2tp-ip package.
> This is not feasible for several reasons:
>   - in a given setup one usually uses either l2tp_ip or
>     l2tp_ip6, but never both
I disagree here, if you e.g. use a hostname and resolve that before 
connecting this would dynamically resolve to either IPv6 or IPv4.

>   - l2tp_ip doesn't depend on ipv6
True, I'm not sure if it makes sense to have IPv6 as an external module 
any longer since its been a while and its enabled by default anyway. I 
guess after the CC branch we might want to enable it in the default 
kernel config and remove the module packaging. This would also save some 
space in the end.

>   - versioning of kmod-l2tp-ip doesn't indicate that it
>     now does include support for L2TP-over-IPv6
Versioning is based on the kernel, so I don't think I get this argument.

Hi Steven,

On Sun, May 03, 2015 at 10:28:16AM +0200, Steven Barth wrote:
> On 02.05.2015 13:33, Daniel Golle wrote:
> >r45593 includes l2tp_ip6 in the kmod-l2tp-ip package.
> >This is not feasible for several reasons:
> >  - in a given setup one usually uses either l2tp_ip or
> >    l2tp_ip6, but never both
> I disagree here, if you e.g. use a hostname and resolve that before
> connecting this would dynamically resolve to either IPv6 or IPv4.

Given that there are the right support-tools around iproute2 to
resolve the hostname and pick the right local address, this is
indeed a valid scenario I didn't consider (due to the lack of
tools actually doing the magic).
For now I've been using L2TP with pre-configured addresses and
predictable use of either address family.

(see: https://gist.github.com/dangowrt/a1b816b509a8def28c0e )

Anyway, I get that argument, but it could still be solved by
adding +IPV6:kmod-l2tp-ip6 as a dependency to kmod-l2tp-ip.

If it's really about the packaging overhead, it would also
be possible to only include l2tp_ip6.ko in FILES if IPV6 is set,
thus getting rid of the kmod-ipv6 dependency on non-IPv6 systems.

In the long-run, I dream about native L2TPv3 integration in
netifd using netlink, just like GRE tunnels are supported in

http://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c

That could then take care of resolving hostnames, adding host-
routes and all that...

What are you using to setup pseudo-wires in OpenWrt after

https://github.com/openwrt/packages/commit/08ae49377644067d2ad3e004f7fc1644e128b6c4

?


> >  - l2tp_ip doesn't depend on ipv6
> True, I'm not sure if it makes sense to have IPv6 as an external module any
> longer since its been a while and its enabled by default anyway. I guess
> after the CC branch we might want to enable it in the default kernel config
> and remove the module packaging. This would also save some space in the end.

There are still many cases where people use ImageBuilder to have a
firmware without IPv6, so they can use the space for other things.
I don't like that approach either and only know about it because
these systems then don't respond to IPv6 link-local multicast ping
which is one of my most used tools in my personal maintainance
toolbox...

So I generally agree, but it's something to happen in the future
which hasn't happened yet...
And won't we one day package IPv4 as an optional module instead then?

> >  - versioning of kmod-l2tp-ip doesn't indicate that it
> >    now does include support for L2TP-over-IPv6
> Versioning is based on the kernel, so I don't think I get this argument.

Right, the fact that versioning is based on the kernel is exactly the
problem here. Imagine that I'm using a 3.14-based locally maintained
OpenWrt branch and provide updates via a feed. Now some user asked me
for l2tp_ip6 support and I'd like to tell her, "yes, it's available now.
Go ahead an install kmod-...".
Now the user already got kmod-l2tp-ip installed, so opkg won't re-install
the package as it believes it's up-to-date. I guess that should explain
it.


Cheers


Daniel

> Anyway, I get that argument, but it could still be solved by
> adding +IPV6:kmod-l2tp-ip6 as a dependency to kmod-l2tp-ip.
>
> If it's really about the packaging overhead, it would also
> be possible to only include l2tp_ip6.ko in FILES if IPV6 is set,
> thus getting rid of the kmod-ipv6 dependency on non-IPv6 systems.
I guess that sounds like a good compromise.

>
> In the long-run, I dream about native L2TPv3 integration in
> netifd using netlink, just like GRE tunnels are supported in
Yes, it's one of those: I would really love to implement that one day 
list, along with a 100 other things unfortunately :/


>
> http://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c
>
> That could then take care of resolving hostnames, adding host-
> routes and all that...
>
> What are you using to setup pseudo-wires in OpenWrt after
>
> https://github.com/openwrt/packages/commit/08ae49377644067d2ad3e004f7fc1644e128b6c4
>
> ?
ip-full for now, though I might one day get annoyed enough to write a 
smaller replacement but IIRC it uses "generic netlink" which is a bit 
more complicated than usual netlink.

> There are still many cases where people use ImageBuilder to have a
> firmware without IPv6, so they can use the space for other things.
> I don't like that approach either and only know about it because
> these systems then don't respond to IPv6 link-local multicast ping
> which is one of my most used tools in my personal maintainance
> toolbox...
I guess those people would need to use the SDK / buildroot then. I will 
try to bring it up with the other core-hackers at some point.


> And won't we one day package IPv4 as an optional module instead then?
I don't think that the Linux kernel supports that (yet?).

> Right, the fact that versioning is based on the kernel is exactly the
> problem here. Imagine that I'm using a 3.14-based locally maintained
> OpenWrt branch and provide updates via a feed. Now some user asked me
> for l2tp_ip6 support and I'd like to tell her, "yes, it's available now.
> Go ahead an install kmod-...".
> Now the user already got kmod-l2tp-ip installed, so opkg won't re-install
> the package as it believes it's up-to-date. I guess that should explain
> it.
Okay, got it though to be fair snapshot builds are in practice not 
really "upgradable" at the moment anyway due to the often times 
false-positive kernel version mismatch.


Cheers,

Steven