Message ID | 20150502113328.GA3844@makrotopia.org |
---|---|
State | Superseded |
Delegated to: | Steven Barth |
Headers | show |
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
diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 7ec3d29..e920509 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -895,11 +895,11 @@ $(eval $(call KernelPackage,l2tp-eth)) define KernelPackage/l2tp-ip SUBMENU:=$(NETWORK_SUPPORT_MENU) - TITLE:=L2TP IP + IPv6 encapsulation for L2TPv3 - DEPENDS:=+kmod-l2tp +kmod-ipv6 + TITLE:=L2TP IP encapsulation for L2TPv3 + DEPENDS:=+kmod-l2tp KCONFIG:=CONFIG_L2TP_IP - FILES:=$(LINUX_DIR)/net/l2tp/l2tp_ip.ko $(LINUX_DIR)/net/l2tp/l2tp_ip6.ko - AUTOLOAD:=$(call AutoLoad,33,l2tp_ip l2tp_ip6) + FILES:=$(LINUX_DIR)/net/l2tp/l2tp_ip.ko + AUTOLOAD:=$(call AutoLoad,33,l2tp_ip) endef define KernelPackage/l2tp-ip/description @@ -908,6 +908,21 @@ endef $(eval $(call KernelPackage,l2tp-ip)) +define KernelPackage/l2tp-ip6 + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=L2TP IPv6 encapsulation for L2TPv3 + DEPENDS:=+kmod-l2tp +kmod-ipv6 + KCONFIG:=CONFIG_L2TP_IP + FILES:=$(LINUX_DIR)/net/l2tp/l2tp_ip6.ko + AUTOLOAD:=$(call AutoLoad,33,l2tp_ip6) +endef + +define KernelPackage/l2tp-ip6/description + Kernel modules for L2TP IP6 encapsulation for L2TPv3 +endef + +$(eval $(call KernelPackage,l2tp-ip6)) + define KernelPackage/sctp SUBMENU:=$(NETWORK_SUPPORT_MENU)
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(-)