Re: [OpenWrt-Devel] [PATCH] modules: package l2tp_ip6.ko in kmod-l2tp-ip6
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] firewall: Allow MLD input on WAN
Hi Steven, On Sun, May 03, 2015 at 04:43:24PM +0200, Steven Barth wrote: Hello Linus, thanks for the patch. I have two questions here. #1 Why should this be done for v6 but not for v4? woops, sorry, had the IGMP part for v4 in my test setup but forgot to add it to the patch. Going to do that. #2 If the intention is to respond to MLD queries why should the firewall allow reception of report messages? Yes, responding to queries is the primary concern. Technically, it doesn't make much of a difference to allow reception report messages. The default in OpenWRT is to have the querier on the bridge, so reports shouldn't arrive on the input chain of br-wan anyways as the bridge won't forward them (see RFC4541, Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches). On the other hand, there's RFC4890, Recommendations for Filtering ICMPv6 Messages in Firewalls which says in section 4.3.3, that firewalls mustn't drop either queries nor reports. MLD/IGMP traffic shouldn't do any harm as it's always link-scoped. Cheers, Linus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] modules: package l2tp_ip6.ko in kmod-l2tp-ip6
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] generic/4.0: update to 4.0.1
Also refresh one patch.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
include/kernel-version.mk| 4 ++--
.../generic/patches-4.0/773-bgmac-add-srab-switch.patch | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index de20fef..9067272 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,10 +3,10 @@
LINUX_RELEASE?=1
LINUX_VERSION-3.18 = .11
-LINUX_VERSION-4.0 =
+LINUX_VERSION-4.0 = .1
LINUX_KERNEL_MD5SUM-3.18.11 = 2def91951c9cedf7896efb864e0c090c
-LINUX_KERNEL_MD5SUM-4.0 = a86916bd12798220da9eb4a1eec3616d
+LINUX_KERNEL_MD5SUM-4.0.1 = ea7fc80310be8a5b43b2c6dfa5c4169f
ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git a/target/linux/generic/patches-4.0/773-bgmac-add-srab-switch.patch
b/target/linux/generic/patches-4.0/773-bgmac-add-srab-switch.patch
index 0a8b451..b883d73 100644
--- a/target/linux/generic/patches-4.0/773-bgmac-add-srab-switch.patch
+++ b/target/linux/generic/patches-4.0/773-bgmac-add-srab-switch.patch
@@ -12,7 +12,7 @@ Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
#include bcm47xx_nvram.h
static const struct bcma_device_id bgmac_bcma_tbl[] = {
-@@ -1432,6 +1433,17 @@ static void bgmac_mii_unregister(struct
+@@ -1538,6 +1539,17 @@ static void bgmac_mii_unregister(struct
mdiobus_free(mii_bus);
}
@@ -30,9 +30,9 @@ Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
/**
* BCMA bus ops
**/
-@@ -1551,6 +1563,16 @@ static int bgmac_probe(struct bcma_devic
- goto err_dma_free;
- }
+@@ -1664,6 +1676,16 @@ static int bgmac_probe(struct bcma_devic
+ net_dev-hw_features = net_dev-features;
+ net_dev-vlan_features = net_dev-features;
+ if ((ci-id == BCMA_CHIP_ID_BCM4707 ||
+ ci-id == BCMA_CHIP_ID_BCM53018)
@@ -47,7 +47,7 @@ Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
err = register_netdev(bgmac-net_dev);
if (err) {
bgmac_err(bgmac, Cannot register net device\n);
-@@ -1577,6 +1599,10 @@ static void bgmac_remove(struct bcma_dev
+@@ -1690,6 +1712,10 @@ static void bgmac_remove(struct bcma_dev
{
struct bgmac *bgmac = bcma_get_drvdata(core);
@@ -60,7 +60,7 @@ Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
netif_napi_del(bgmac-napi);
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
-@@ -457,6 +457,9 @@ struct bgmac {
+@@ -462,6 +462,9 @@ struct bgmac {
bool has_robosw;
bool loopback;
--
2.3.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] firewall: Allow MLD input on WAN
Hello Linus, thanks for the patch. I have two questions here. #1 Why should this be done for v6 but not for v4? #2 If the intention is to respond to MLD queries why should the firewall allow reception of report messages? Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] firewall: Allow IGMP and MLD input on WAN
The WAN port should at least respond to IGMP and MLD queries as otherwise a snooping bridge/switch might drop traffic. RFC4890 recommends to leave IGMP and MLD unfiltered as they are always link-scoped anyways. Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- v2 of [PATCH] firewall: Allow MLD input on WAN: * Allow IGMP too * Added note about RFC4890 .../network/config/firewall/files/firewall.config | 19 +++ 1 file changed, 19 insertions(+) diff --git a/package/network/config/firewall/files/firewall.config b/package/network/config/firewall/files/firewall.config index d149e77..1a20e39 100644 --- a/package/network/config/firewall/files/firewall.config +++ b/package/network/config/firewall/files/firewall.config @@ -46,6 +46,13 @@ config rule option family ipv4 option target ACCEPT +config rule + option name Allow-IGMP + option src wan + option protoigmp + option family ipv4 + option target ACCEPT + # Allow DHCPv6 replies # see https://dev.openwrt.org/ticket/10381 config rule @@ -59,6 +66,18 @@ config rule option family ipv6 option target ACCEPT +config rule + option name Allow-MLD + option src wan + option protoicmp + option src_ip fe80::/10 + list icmp_type '130/0' + list icmp_type '131/0' + list icmp_type '132/0' + list icmp_type '143/0' + option family ipv6 + option target ACCEPT + # Allow essential incoming IPv6 ICMP traffic config rule option name Allow-ICMPv6-Input -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] modules: package l2tp_ip6.ko in kmod-l2tp-ip6
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
