Re: [B.A.T.M.A.N.] [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README

2018-03-27 Thread Linus Lüssing
On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote: > >> I strongly believe it is a huge mistake to use sysfs for things like > >> this. This should be done via generic netlink api. > > > >This doesn't change the problem that it is already that way. This patch > >only adds the list of

Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

2018-03-12 Thread Linus Lüssing
On Mon, Mar 12, 2018 at 12:08:56PM +0100, Linus Lüssing wrote: > On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote: > > I've problem when using OpenWrt/LEDE on a home router with Broadcom's > > FullMAC WiFi chipset. > > Hi Rafał, > > Thanks for reporting

Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

2018-03-12 Thread Linus Lüssing
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote: > On 27 February 2018 at 18:05, Stephen Hemminger [...] > > ebtables is your friend in dealing with weird and broken devices. > > It may be weird, not sure if actually broken. Anyway I'd like to have > some generic solution instead of

Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

2018-03-12 Thread Linus Lüssing
On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote: > I've problem when using OpenWrt/LEDE on a home router with Broadcom's > FullMAC WiFi chipset. Hi Rafał, Thanks for reporting this issue! > Can you see any solution for this problem? Is that an option to stop > multicast-to-unicast

Re: [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-07 Thread Linus Lüssing
On Fri, Dec 08, 2017 at 06:46:06AM +0100, Linus Lüssing wrote: > Extending the usersize to include info->prev would probably be too > hackish/ugly, right? And wouldn't be enough anyway, since info->{credit,credit_cap,cost} would still be zeroed... Hm.

Re: [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-07 Thread Linus Lüssing
On Thu, Dec 07, 2017 at 01:26:19AM +0100, Pablo Neira Ayuso wrote: > > I also had a quick look at a 4.15-rc1 kernel in a VM now. I still > > end up in ebt_limit_mt_check() with the variables being reset > > when editing the table somewhere. > > My question is if your fix would work with 4.15-rc1.

Re: [Bridge] [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-03 Thread Linus Lüssing
On Mon, Dec 04, 2017 at 05:53:35AM +0100, Linus Lüssing wrote: > And so, no I do not have this patch. I looked at it now, but it > does not seem to have any relation with .matchinfo, does it? Relation between .usersize and .checkentry I ment, not .usersize and .matchinfo.

Re: [PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-12-03 Thread Linus Lüssing
Hi Pablo, Thanks for your reply! On Tue, Nov 28, 2017 at 12:30:08AM +0100, Pablo Neira Ayuso wrote: > [...] > > diff --git a/net/bridge/netfilter/ebt_limit.c > > b/net/bridge/netfilter/ebt_limit.c > > index 61a9f1be1263..f74b48633feb 100644 > > --- a/net/bridge/netfilter/ebt_limit.c > > +++

[PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

2017-11-24 Thread Linus Lüssing
sending packets every 250ms for 600s, with a "--limit 1/sec --limit-burst 50" rule and a command like this in the background: $ ebtables -N VOIDCHAIN $ while true; do ebtables -F VOIDCHAIN; sleep 30; done The results are: Before: ~1600 packets After: 650 packets Signed-off-by: Lin

[PATCH net v3] bridge: ebtables: fix reception of frames DNAT-ed to bridge device/port

2017-04-19 Thread Linus Lüssing
of ip_input.c/ip_rcv() as the dnat target left the skb->pkt_type as PACKET_OTHERHOST. Fixing this by resetting skb->pkt_type to an appropriate type after dnat'ing. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- Changelog v3: - moved pkt_type fixup into ebtable dnat cod

Re: [PATCH v2] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-04-17 Thread Linus Lüssing
On Tue, Mar 21, 2017 at 04:32:45PM -0700, Stephen Hemminger wrote: > On Tue, 21 Mar 2017 23:28:45 +0100 > Linus Lüssing <linus.luess...@c0d3.blue> wrote: > > > However, the IP code drops it in the beginning of ip_input.c/ip_rcv() > > as the dnat target did not update

[PATCH v2] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-21 Thread Linus Lüssing
ERHOST to PACKET_HOST, too. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- Changelog v2: * refrain from altering pkt_type for multicast packets with a unicast destination MAC --- net/bridge/br_input.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

Re: [Bridge] [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-20 Thread Linus Lüssing
On Sun, Mar 19, 2017 at 05:55:06PM +0100, Linus Lüssing wrote: > On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote: > > Wait. > > > > May this break local multicast listener that are bound to the bridge > > interface? Assuming the bridge

Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-19 Thread Linus Lüssing
On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote: > Wait. > > May this break local multicast listener that are bound to the bridge > interface? Assuming the bridge interface got an IP address, and that > there is local multicast listener. > > Missing anything here? Hm, for

Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-15 Thread Linus Lüssing
On Wed, Mar 15, 2017 at 07:15:39PM +0100, Pablo Neira Ayuso wrote: > Could you update ebtables dnat to check if the ethernet address > matches the one of the input bridge interface, so we mangle the > ->pkt_type accordingly from there, instead of doing this from the > core? Actually, that was the

Re: [PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-15 Thread Linus Lüssing
On Wed, Mar 15, 2017 at 11:42:11AM +0100, Pablo Neira Ayuso wrote: > I'm missing then why redirect is not then just enough for Linus usecase. For my usecase, the MAC address is configured by the user from a Web-UI. It may or may not be the one from the bridge device. Besides, found it counter

[PATCH net] bridge: ebtables: fix reception of frames DNAT-ed to bridge device

2017-03-14 Thread Linus Lüssing
ERHOST to PACKET_HOST, too. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- net/bridge/br_input.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index 013f2290b..ec83175 100644 --- a/net/bridge/br_input.c +++

[PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches

2017-02-02 Thread Linus Lüssing
tch fixes this by always resending MLD reports when an interface change happens, for instance from NO-CARRIER to CARRIER state. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- Initial problem report was sent to the bridge mailing list a while ago: - https://lists.linuxfounda

[PATCH net-next v5] bridge: multicast to unicast

2017-01-21 Thread Linus Lüssing
kau <n...@nbd.name> [linus.luess...@c0d3.blue: various bug + style fixes, commit message] Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- This feature is used and enabled by default in OpenWRT and LEDE for AP interfaces for more than a year now to allow both a more robust

[PATCH net-next v4] bridge: multicast to unicast

2017-01-18 Thread Linus Lüssing
kau <n...@nbd.name> [linus.luess...@c0d3.blue: various bug + style fixes, commit message] Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- This feature is used and enabled by default in OpenWRT and LEDE for AP interfaces for more than a year now to allow both a more robust

[PATCH net-next v3] bridge: multicast to unicast

2017-01-18 Thread Linus Lüssing
.@c0d3.blue: various bug + style fixes, commit message] Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- This feature is used and enabled by default in OpenWRT and LEDE for AP interfaces for more than a year now to allow both a more robust multicast delivery and multicast at highe

[PATCH net-next v2] bridge: multicast to unicast

2017-01-17 Thread Linus Lüssing
kau <n...@nbd.name> [linus.luess...@c0d3.blue: various bug + style fixes, commit message] Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- This feature is used and enabled by default in OpenWRT and LEDE for AP interfaces for more than a year now to allow both a more robust

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-09 Thread Linus Lüssing
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote: > I wonder if MAC80211 should be doing IGMP snooping and not bridge > in this environment. In the long term, yes. For now, not quite sure. I personally like to go for simple solutions first :).

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-09 Thread Linus Lüssing
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote: > On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote: > > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote: > > > > > > > >  A host SHOULD silently discard a datagr

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-09 Thread Linus Lüssing
On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote: > Am 09.01.2017 um 09:08 schrieb Johannes Berg: > > Does it make sense to implement the two in separate layers though? > > > > Clearly, this part needs to be implemented in the bridge layer due to > > the snooping knowledge, but the code

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-09 Thread Linus Lüssing
On Mon, Jan 09, 2017 at 09:05:49AM +0100, Johannes Berg wrote: > On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote: > > > Actually, I do not quite understand that remark in the mac80211 > > multicast-to-unicast patch. IP should not care about the ethernet > >

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote: > How does this compare and/or relate to the multicast-to-unicast feature > we were going to add to the wifi stack, particularly mac80211? Do we > perhaps not need that feature at all, if bridging will have it? > > I suppose that the

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote: > On Mon, 2 Jan 2017 20:32:14 +0100 > Linus Lüssing <linus.luess...@c0d3.blue> wrote: > > > This feature is intended for interface types which have a more reliable > > and/or efficient way to d

Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote: > Am 06.01.2017 um 14:54 schrieb Johannes Berg: > > > >> The bridge layer can use IGMP snooping to ensure that the multicast > >> stream is only transmitted to clients that are actually a member of > >> the group. Can the mac80211 feature

[PATCH net-next] bridge: multicast to unicast

2017-01-02 Thread Linus Lüssing
packets than broadcast ones (e.g. wifi). However, it should only be enabled on interfaces where no IGMPv2/MLDv1 report suppression takes place. This feature is disabled by default. The initial patch and idea is from Felix Fietkau. Cc: Felix Fietkau <n...@nbd.name> Signed-off-by: Linus L

Re: [PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation

2016-10-17 Thread Linus Lüssing
On Mon, Oct 17, 2016 at 11:39:04AM +0200, Johannes Berg wrote: > On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote: > > For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the > > more modern, netlink based driver instead of wext. > > Makes sense, applie

[PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation

2016-10-16 Thread Linus Lüssing
For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the more modern, netlink based driver instead of wext. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- Actually, I wasn't even able to make a connection with the configuration files and information pr

Re: [Bridge] [PATCH net-next v2 2/2] net: bridge: add per-port multicast flood flag

2016-08-31 Thread Linus Lüssing
On Wed, Aug 31, 2016 at 08:02:22AM +0200, Nikolay Aleksandrov wrote: > On 31/08/16 03:37, Linus Lüssing wrote: > > On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge > > wrote: > >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c > >>

Re: [Bridge] [PATCH net-next v2 2/2] net: bridge: add per-port multicast flood flag

2016-08-30 Thread Linus Lüssing
On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge wrote: > diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c > index 1da3221845f1..ed0dd3340084 100644 > --- a/net/bridge/br_if.c > +++ b/net/bridge/br_if.c > @@ -362,7 +362,7 @@ static struct net_bridge_port *new_nbp(struct

[PATCH] cfg80211: Add stub for cfg80211_get_station()

2016-08-19 Thread Linus Lüssing
This allows modules using this function (currently: batman-adv) to compile even if cfg80211 is not built at all, thus relaxing dependencies. Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- include/net/cfg80211.h | 9 + 1 file changed, 9 insertions(+) diff --git a/inclu

Re: [PATCH net] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

2016-06-28 Thread Linus Lüssing
On Tue, Jun 28, 2016 at 08:04:42AM -0400, David Miller wrote: > From: Linus Lüssing <linus.luess...@c0d3.blue> > [...] > > Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()") > > You're missing an initial 'd' in that SHA1-ID. > >

Re: [Bridge] [PATCH net-next] net: bridge: add support for IGMP/MLD stats and export them via netlink

2016-06-28 Thread Linus Lüssing
On Mon, Jun 27, 2016 at 08:10:48PM +0200, Nikolay Aleksandrov via Bridge wrote: > These are invaluable when monitoring or debugging complex multicast setups > with bridges. Indeed! Great patch :). Especially if people are unable to provide pcap files for debugging (due to whatever reason).

Re: [PATCH net] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

2016-06-25 Thread Linus Lüssing
On Fri, Jun 24, 2016 at 12:35:18PM +0200, Daniel Danzberger wrote: > The bridge is falsly dropping ipv6 mulitcast packets if there is: > 1. No ipv6 address assigned on the brigde. > 2. No external mld querier present. > 3. The internal querier enabled. > > When the bridge fails to build mld

Re: [PATCH net] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

2016-06-24 Thread Linus Lüssing
ddress assinged to the bridge > and returns a false state for the local querier in > __br_multicast_querier_exists(). Acked-by: Linus Lüssing <linus.luess...@c0d3.blue>

Re: [PATCH] Bridge: Fix ipv6 mc snooping if it has no ipv6 address.

2016-06-23 Thread Linus Lüssing
Hi Daniel, Thanks for submitting this patch here :). On Thu, Jun 23, 2016 at 11:28:55AM +0200, daniel wrote: > The bridge is falsly dropping ipv6 mulitcast packets > if there is no ipv6 address assigned on the brigde and no > external mld querier is present. and if the bridge internal querier

[PATCHv2 net] bridge: fix igmp / mld query parsing

2016-05-04 Thread Linus Lüssing
this by taking the offset between IP and IGMP/MLD header into account, too. Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code") Reported-by: Simon Wunderlich <s...@simonwunderlich.de> Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- v2: changed "i

Re: [PATCH net] bridge: fix igmp / mld query parsing

2016-05-04 Thread Linus Lüssing
On Tue, May 03, 2016 at 01:26:23PM -0700, Stephen Hemminger wrote: > On Tue, 3 May 2016 22:18:54 +0200 > Linus Lüssing <linus.luess...@c0d3.blue> wrote: > > > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > > index 03661d9..7105cdf 100644 > >

[PATCH net] bridge: fix igmp / mld query parsing

2016-05-03 Thread Linus Lüssing
this by taking the offset between IP and IGMP/MLD header into account, too. Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code") Reported-by: Simon Wunderlich <s...@simonwunderlich.de> Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- net/bridge

[PATCHv3] net: fix bridge multicast packet checksum validation

2016-02-23 Thread Linus Lüssing
lticast_rcv+0x5dc/0xd00) [ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>] (br_handle_frame_finish+0xac/0x51c) [...] Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code") Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com> Signed-off-by: Lin

[PATCHv2] net: fix bridge multicast packet checksum validation

2016-02-23 Thread Linus Lüssing
lticast_rcv+0x5dc/0xd00) [ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>] (br_handle_frame_finish+0xac/0x51c) [...] Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code") Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com> Signed-off-by: Linus

Re: [PATCH] net: fix bridge multicast packet checksum validation

2016-02-18 Thread Linus Lüssing
On Thu, Feb 18, 2016 at 01:51:34PM +0100, Steinar H. Gunderson wrote: > On Mon, Feb 15, 2016 at 03:07:06AM +0100, Linus Lüssing wrote: > > Steinar, can you check whether this fixes the bridge issues you reported on > > bugzilla #99081? Not quite sure whether it is the same as your

[PATCH] net: fix bridge multicast packet checksum validation

2016-02-14 Thread Linus Lüssing
sh+0xac/0x51c) [...] Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code") Reported-by: Álvaro Fernández Rojas <nolt...@gmail.com> Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- Steinar, can you check whether this fixes the bridge issues you reporte

[PATCH net] bridge: fix igmpv3 / mldv2 report parsing

2015-09-11 Thread Linus Lüssing
Powalowski <tobias.powalow...@googlemail.com> Tested-by: Tobias Powalowski <tobias.powalow...@googlemail.com> Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue> --- net/bridge/br_multicast.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_multicast.c

[PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code

2015-08-12 Thread Linus Lüssing
of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to additionally check whether the returned skb_trimmed is a clone. Fixes: 9afd85c9e455 (net: Export IGMP/MLD message validation code) Reported-by: Brenden Blanco bbla...@plumgrid.com Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- net

Re: ipv6_mc_check_mld - kernel BUG at net/core/skbuff.c:1128

2015-08-11 Thread Linus Lüssing
On Mon, Aug 10, 2015 at 02:56:12PM -0700, Brenden Blanco wrote: Doing some code reading with Alexei, we found a suspect commit, which introduces an skb_get and skb_may_pull of the same skb, which leads to the BUG when skb-len == len. Urgh, didn't know that pskb_may_pull() doesn't like an skb

Re: ipv6_mc_check_mld - kernel BUG at net/core/skbuff.c:1128

2015-08-11 Thread Linus Lüssing
On Tue, Aug 11, 2015 at 10:51:40PM +0200, Linus Lüssing wrote: On Mon, Aug 10, 2015 at 02:56:12PM -0700, Brenden Blanco wrote: Doing some code reading with Alexei, we found a suspect commit, which introduces an skb_get and skb_may_pull of the same skb, which leads to the BUG when skb-len

Caller or callee setting skb-network_header?

2015-06-29 Thread Linus Lüssing
Hi, For an .ndo_start_xmit handler, can the callee rely on the caller setting the skb network header? Or should the callee set it before performing any skb_network_header()/ip_hdr()/ipv6_hdr()/... calls? Cheers, Linus PS: Currently looking at batman-adv's ndo_start_xmit handler interface_tx(),

Re: [PATCH net] bridge: fix br_multicast_query_expired() bug

2015-05-28 Thread Linus Lüssing
On Thu, May 28, 2015 at 04:42:54AM -0700, Eric Dumazet wrote: Intent of the code was to clear port field, not the pointer to querier. Acked-by: Linus Lüssing linus.luess...@c0d3.blue -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord

[PATCHv3 net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-22 Thread Linus Lüssing
. But since br_multicast_init() doesn't start any timers and only sets default values and initializes timers it should be save to reconfigure the default values after that, before things actually get active after the bridge is set up. Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- Changelog v3

[PATCHv2 net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-22 Thread Linus Lüssing
. But since br_multicast_init() doesn't start any timers and only sets default values and initializes timers it should be save to reconfigure the default values after that, before things actually get active after the bridge is set up. Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- Changelog v2

Re: [RFC PATCH net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-21 Thread Linus Lüssing
On Thu, May 21, 2015 at 11:49:21AM +0800, Herbert Xu wrote: The timer operations are all supposed to be idempotent. So enabling a port twice or stopping it twice should be OK. Oki doki. * Might calls to br_multicast_add_router() via br_multicast_enable_port() cause unintended

[PATCH net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-21 Thread Linus Lüssing
even if the according bridge (port) is down, just like other other bridge (port) attributes allow too. Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- Changelog: * [RFC PATCH net-next] - [PATCH net-next] net/bridge/br_multicast.c | 15 ++- 1 file changed, 2 insertions

[RFC PATCH net-next] bridge: allow setting hash_max + multicast_router if interface is down

2015-05-20 Thread Linus Lüssing
even if the according bridge (port) is down, just like other other bridge (port) attributes allow too. Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue --- I'm currently a little unsure about a few things (that's why I'm sending this as an RFC): * For i=br_multicast_init(), e