[Bridge] [PATCH net-next 2/4] bridge: adhere to querier election mechanism specified by RFCs

2014-05-21 Thread Linus Lüssing
MLDv1 (RFC2710 section 6), MLDv2 (RFC3810 section 7.6.2), IGMPv2 (RFC2236 section 3) and IGMPv3 (RFC3376 section 6.6.2) specify that the querier with lowest source address shall become the selected querier. So far the bridge stopped its querier as soon as it heard another querier regardless of its

[Bridge] bridge: multicast snooping patches / exports

2014-05-21 Thread Linus Lüssing
Hi, The first patch is simply a cosmetic patch. So far I (and maybe others too?) have been regularly confusing these two structs, therefore I'd suggest renaming them and therefore making the follow-up patches easier to understand and nicer to fit in. The second patch fixes a minor issue, but prob

[Bridge] [PATCH net-next 1/4] bridge: rename struct bridge_mcast_query/querier

2014-05-21 Thread Linus Lüssing
The current naming of these two structs is very random, in that reversing their naming would not make any semantical difference. This patch tries to make the naming less confusing by giving them a more specific, distinguishable naming. This is also useful for the upcoming patches reintroducing th

[Bridge] [PATCH net-next 3/4] bridge: add export of multicast database adjacent to net_dev

2014-05-21 Thread Linus Lüssing
With this new, exported function br_multicast_list_adjacent(net_dev) a list of IPv4/6 addresses is returned. This list contains all multicast addresses sensed by the bridge multicast snooping feature on all bridge ports of the bridge interface of net_dev, excluding addresses from the specified net_

[Bridge] [PATCH net-next 4/4] bridge: memorize and export selected IGMP/MLD querier port

2014-05-21 Thread Linus Lüssing
Adding bridge support to the batman-adv multicast optimization requires batman-adv knowing about the existence of bridged-in IGMP/MLD queriers to be able to reliably serve any multicast listener behind this same bridge. Signed-off-by: Linus Lüssing --- include/linux/if_bridge.h |1 + net/bri

Re: [Bridge] Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)

2014-05-21 Thread Bart De Schuymer
David Newall schreef op 21/05/2014 9:49: An alternative would be to make sure that the data pointed to by IPCB and BR_INPUT_SKB_CB don't overlap. If this were the case, we could indeed just revert the commit that was referred to. They are identical spaces, but you imply a good point: the cb are

Re: [Bridge] Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)

2014-05-21 Thread David Miller
From: David Newall Date: Wed, 21 May 2014 17:40:25 +0930 > On 20/05/14 14:25, valdis.kletni...@vt.edu wrote: >> So yes, we*do* need to do something sensible there - either frag the >> packet >> on the way out, or something. > > I think the problem is that a bridge cannot be used across > incompa

Re: [Bridge] Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)

2014-05-21 Thread David Miller
From: Bart De Schuymer Date: Wed, 21 May 2014 20:51:14 +0200 > David Newall schreef op 21/05/2014 9:49: >>> An alternative would be to make sure that the data pointed to by IPCB >>> and BR_INPUT_SKB_CB don't overlap. If this were the case, we could >>> indeed just revert the commit that was refer