Changeset 41819


Ignore:
Timestamp:
2014-07-24T11:19:37+02:00 (4 years ago)
Author:
nbd
Message:

kernel: annotate bridge multicast backport patch with upstream commits

Signed-off-by: Felix Fietkau <nbd@…>

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/target/linux/generic/patches-3.10/070-net_bridge_backports.patch

    r41817 r41819  
     1commit 3c3769e63301fd92fcaf51870c371583dd0282ce 
     2Author: Linus LÃŒssing <linus.luessing@web.de> 
     3Date:   Wed Sep 4 02:13:39 2013 +0200 
     4 
     5    bridge: apply multicast snooping to IPv6 link-local, too 
     6     
     7    The multicast snooping code should have matured enough to be safely 
     8    applicable to IPv6 link-local multicast addresses (excluding the 
     9    link-local all nodes address, ff02::1), too. 
     10     
     11    Signed-off-by: Linus LÃŒssing <linus.luessing@web.de> 
     12    Signed-off-by: David S. Miller <davem@davemloft.net> 
     13 
     14commit 8fad9c39f31f9ed7bf3526c43a4537b2fcf1a5d5 
     15Author: Linus LÃŒssing <linus.luessing@web.de> 
     16Date:   Wed Sep 4 02:13:38 2013 +0200 
     17 
     18    bridge: prevent flooding IPv6 packets that do not have a listener 
     19     
     20    Currently if there is no listener for a certain group then IPv6 packets 
     21    for that group are flooded on all ports, even though there might be no 
     22    host and router interested in it on a port. 
     23     
     24    With this commit they are only forwarded to ports with a multicast 
     25    router. 
     26     
     27    Just like commit bd4265fe36 ("bridge: Only flood unregistered groups 
     28    to routers") did for IPv4, let's do the same for IPv6 with the same 
     29    reasoning. 
     30     
     31    Signed-off-by: Linus LÃŒssing <linus.luessing@web.de> 
     32    Signed-off-by: David S. Miller <davem@davemloft.net> 
     33 
     34commit cc0fdd802859eaeb00e1c87dbb655594bed2844c 
     35Author: Linus LÃŒssing <linus.luessing@web.de> 
     36Date:   Fri Aug 30 17:28:17 2013 +0200 
     37 
     38    bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones 
     39     
     40    Currently we would still potentially suffer multicast packet loss if there 
     41    is just either an IGMP or an MLD querier: For the former case, we would 
     42    possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is 
     43    because we are currently assuming that if either an IGMP or MLD querier 
     44    is present that the other one is present, too. 
     45     
     46    This patch makes the behaviour and fix added in 
     47    "bridge: disable snooping if there is no querier" (b00589af3b04) 
     48    to also work if there is either just an IGMP or an MLD querier on the 
     49    link: It refines the deactivation of the snooping to be protocol 
     50    specific by using separate timers for the snooped IGMP and MLD queries 
     51    as well as separate timers for our internal IGMP and MLD queriers. 
     52     
     53    Signed-off-by: Linus LÃŒssing <linus.luessing@web.de> 
     54    Signed-off-by: David S. Miller <davem@davemloft.net> 
     55 
     56commit b00589af3b04736376f24625ab0b394642e89e29 
     57Author: Linus LÃŒssing <linus.luessing@web.de> 
     58Date:   Thu Aug 1 01:06:20 2013 +0200 
     59 
     60    bridge: disable snooping if there is no querier 
     61     
     62    If there is no querier on a link then we won't get periodic reports and 
     63    therefore won't be able to learn about multicast listeners behind ports, 
     64    potentially leading to lost multicast packets, especially for multicast 
     65    listeners that joined before the creation of the bridge. 
     66     
     67    These lost multicast packets can appear since c5c23260594 
     68    ("bridge: Add multicast_querier toggle and disable queries by default") 
     69    in particular. 
     70     
     71    With this patch we are flooding multicast packets if our querier is 
     72    disabled and if we didn't detect any other querier. 
     73     
     74    A grace period of the Maximum Response Delay of the querier is added to 
     75    give multicast responses enough time to arrive and to be learned from 
     76    before disabling the flooding behaviour again. 
     77     
     78    Signed-off-by: Linus LÃŒssing <linus.luessing@web.de> 
     79    Signed-off-by: David S. Miller <davem@davemloft.net> 
     80 
     81commit 6b7df111ece130fa979a0c4f58e53674c1e47d3e 
     82Author: Cong Wang <amwang@redhat.com> 
     83Date:   Tue May 21 21:52:56 2013 +0000 
     84 
     85    bridge: send query as soon as leave is received 
     86     
     87    Continue sending queries when leave is received if the user marks 
     88    it as a querier. 
     89     
     90    Cc: Herbert Xu <herbert@gondor.apana.org.au> 
     91    Cc: Stephen Hemminger <stephen@networkplumber.org> 
     92    Cc: "David S. Miller" <davem@davemloft.net> 
     93    Cc: Adam Baker <linux@baker-net.org.uk> 
     94    Signed-off-by: Cong Wang <amwang@redhat.com> 
     95    Acked-by: Herbert Xu <herbert@gondor.apana.org.au> 
     96    Signed-off-by: David S. Miller <davem@davemloft.net> 
     97 
     98commit 1c8ad5bfa2be5025b0c81e3c2decd0574d453ab1 
     99Author: Cong Wang <amwang@redhat.com> 
     100Date:   Tue May 21 21:52:54 2013 +0000 
     101 
     102    bridge: use the bridge IP addr as source addr for querier 
     103     
     104    Quote from Adam: 
     105    "If it is believed that the use of 0.0.0.0 
     106    as the IP address is what is causing strange behaviour on other devices 
     107    then is there a good reason that a bridge rather than a router shouldn't 
     108    be the active querier? If not then using the bridge IP address and 
     109    having the querier enabled by default may be a reasonable solution 
     110    (provided that our querier obeys the election rules and shuts up if it 
     111    sees a query from a lower IP address that isn't 0.0.0.0). Just because a 
     112    device is the elected querier for IGMP doesn't appear to mean it is 
     113    required to perform any other routing functions." 
     114     
     115    And introduce a new troggle for it, as suggested by Herbert. 
     116     
     117    Suggested-by: Adam Baker <linux@baker-net.org.uk> 
     118    Cc: Herbert Xu <herbert@gondor.apana.org.au> 
     119    Cc: Stephen Hemminger <stephen@networkplumber.org> 
     120    Cc: "David S. Miller" <davem@davemloft.net> 
     121    Cc: Adam Baker <linux@baker-net.org.uk> 
     122    Signed-off-by: Cong Wang <amwang@redhat.com> 
     123    Acked-by: Herbert Xu <herbert@gondor.apana.org.au> 
     124    Signed-off-by: David S. Miller <davem@davemloft.net> 
     125 
    1126--- a/net/bridge/br_device.c 
    2127+++ b/net/bridge/br_device.c 
Note: See TracChangeset for help on using the changeset viewer.