1. 11 6月, 2014 4 次提交
    • L
      bridge: memorize and export selected IGMP/MLD querier port · 2cd41431
      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: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cd41431
    • L
      bridge: add export of multicast database adjacent to net_dev · 07f8ac4a
      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_device itself.
      
      Adding bridge support to the batman-adv multicast optimization requires
      batman-adv knowing about the existence of bridged-in multicast
      listeners to be able to reliably serve them with multicast packets.
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07f8ac4a
    • L
      bridge: adhere to querier election mechanism specified by RFCs · dc4eb53a
      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 source address. This results in the "wrong"
      querier potentially becoming the active querier or a potential,
      unnecessary querying delay.
      
      With this patch the bridge memorizes the source address of the currently
      selected querier and ignores queries from queriers with a higher source
      address than the currently selected one. This slight optimization is
      supposed to make it more RFC compliant (but is rather uncritical and
      therefore probably not necessary to be queued for stable kernels).
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc4eb53a
    • L
      bridge: rename struct bridge_mcast_query/querier · 90010b36
      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 the
      "struct bridge_mcast_querier" but for storing information about the
      selected querier (no matter if our own or a foreign querier).
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90010b36
  2. 06 6月, 2014 1 次提交
  3. 03 6月, 2014 2 次提交
    • R
      bridge: Add bridge ifindex to bridge fdb notify msgs · 41c389d7
      Roopa Prabhu 提交于
      (This patch was previously posted as RFC at
      http://patchwork.ozlabs.org/patch/352677/)
      
      This patch adds NDA_MASTER attribute to neighbour attributes enum for
      bridge/master ifindex. And adds NDA_MASTER to bridge fdb notify msgs.
      
      Today bridge fdb notifications dont contain bridge information.
      Userspace can derive it from the port information in the fdb
      notification. However this is tricky in some scenarious.
      
      Example, bridge port delete notification comes before bridge fdb
      delete notifications. And we have seen problems in userspace
      when using libnl where, the bridge fdb delete notification handling code
      does not understand which bridge this fdb entry is part of because
      the bridge and port association has already been deleted.
      And these notifications (port membership and fdb) are generated on
      separate rtnl groups.
      
      Fixing the order of notifications could possibly solve the problem
      for some cases (I can submit a separate patch for that).
      
      This patch chooses to add NDA_MASTER to bridge fdb notify msgs
      because it not only solves the problem described above, but also helps
      userspace avoid another lookup into link msgs to derive the master index.
      Signed-off-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41c389d7
    • T
      bridge: Prevent insertion of FDB entry with disallowed vlan · e0d7968a
      Toshiaki Makita 提交于
      br_handle_local_finish() is allowing us to insert an FDB entry with
      disallowed vlan. For example, when port 1 and 2 are communicating in
      vlan 10, and even if vlan 10 is disallowed on port 3, port 3 can
      interfere with their communication by spoofed src mac address with
      vlan id 10.
      
      Note: Even if it is judged that a frame should not be learned, it should
      not be dropped because it is destined for not forwarding layer but higher
      layer. See IEEE 802.1Q-2011 8.13.10.
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0d7968a
  4. 02 6月, 2014 2 次提交
  5. 26 5月, 2014 1 次提交
    • P
      netfilter: bridge: fix Kconfig unmet dependencies · 1708803e
      Pablo Neira 提交于
      Before f5efc696 ("netfilter: nf_tables: Add meta expression key for
      bridge interface name"), the entire net/bridge/netfilter/ directory
      depended on BRIDGE_NF_EBTABLES, ie. on ebtables. However, that
      directory already contained the nf_tables bridge extension that
      we should allow to compile separately. In f5efc696, we tried to
      generalize this by using CONFIG_BRIDGE_NETFILTER which was not a good
      idea since this option already existed and it is dedicated to enable
      the Netfilter bridge IP/ARP filtering.
      
      Let's try to fix this mess by:
      
      1) making net/bridge/netfilter/ dependent on the toplevel
         CONFIG_NETFILTER option, just like we do with the net/netfilter and
         net/ipv{4,6}/netfilter/ directories.
      
      2) Changing 'selects' to 'depends on' NETFILTER_XTABLES for
         BRIDGE_NF_EBTABLES. I believe this problem was already before
         f5efc696:
      
      warning: (BRIDGE_NF_EBTABLES) selects NETFILTER_XTABLES which has
      unmet direct dependencies (NET && INET && NETFILTER)
      
      3) Fix ebtables/nf_tables bridge dependencies by making NF_TABLES_BRIDGE
         and BRIDGE_NF_EBTABLES dependent on BRIDGE and NETFILTER:
      
      warning: (NF_TABLES_BRIDGE && BRIDGE_NF_EBTABLES) selects
      BRIDGE_NETFILTER which has unmet direct dependencies (NET && BRIDGE &&
      NETFILTER && INET && NETFILTER_ADVANCED)
      
      net/built-in.o: In function `br_parse_ip_options':
      br_netfilter.c:(.text+0x4a5ba): undefined reference to `ip_options_compile'
      br_netfilter.c:(.text+0x4a5ed): undefined reference to `ip_options_rcv_srr'
      net/built-in.o: In function `br_nf_pre_routing_finish':
      br_netfilter.c:(.text+0x4a8a4): undefined reference to `ip_route_input_noref'
      br_netfilter.c:(.text+0x4a987): undefined reference to `ip_route_output_flow'
      make: *** [vmlinux] Error 1
      Reported-by: NJim Davis <jim.epost@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1708803e
  6. 23 5月, 2014 1 次提交
  7. 19 5月, 2014 2 次提交
  8. 17 5月, 2014 6 次提交
    • V
      bridge: Automatically manage port promiscuous mode. · 2796d0c6
      Vlad Yasevich 提交于
      There exist configurations where the administrator or another management
      entity has the foreknowledge of all the mac addresses of end systems
      that are being bridged together.
      
      In these environments, the administrator can statically configure known
      addresses in the bridge FDB and disable flooding and learning on ports.
      This makes it possible to turn off promiscuous mode on the interfaces
      connected to the bridge.
      
      Here is why disabling flooding and learning allows us to control
      promiscuity:
       Consider port X.  All traffic coming into this port from outside the
      bridge (ingress) will be either forwarded through other ports of the
      bridge (egress) or dropped.  Forwarding (egress) is defined by FDB
      entries and by flooding in the event that no FDB entry exists.
      In the event that flooding is disabled, only FDB entries define
      the egress.  Once learning is disabled, only static FDB entries
      provided by a management entity define the egress.  If we provide
      information from these static FDBs to the ingress port X, then we'll
      be able to accept all traffic that can be successfully forwarded and
      drop all the other traffic sooner without spending CPU cycles to
      process it.
       Another way to define the above is as following equations:
          ingress = egress + drop
       expanding egress
          ingress = static FDB + learned FDB + flooding + drop
       disabling flooding and learning we a left with
          ingress = static FDB + drop
      
      By adding addresses from the static FDB entries to the MAC address
      filter of an ingress port X, we fully define what the bridge can
      process without dropping and can thus turn off promiscuous mode,
      thus dropping packets sooner.
      
      There have been suggestions that we may want to allow learning
      and update the filters with learned addresses as well.  This
      would require mac-level authentication similar to 802.1x to
      prevent attacks against the hw filters as they are limited
      resource.
      
      Additionally, if the user places the bridge device in promiscuous mode,
      all ports are placed in promiscuous mode regardless of the changes
      to flooding and learning.
      
      Since the above functionality depends on full static configuration,
      we have also require that vlan filtering be enabled to take
      advantage of this.  The reason is that the bridge has to be
      able to receive and process VLAN-tagged frames and the there
      are only 2 ways to accomplish this right now: promiscuous mode
      or vlan filtering.
      Suggested-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2796d0c6
    • V
      bridge: Add addresses from static fdbs to non-promisc ports · 145beee8
      Vlad Yasevich 提交于
      When a static fdb entry is created, add the mac address
      from this fdb entry to any ports that are currently running
      in non-promiscuous mode.  These ports need this data so that
      they can receive traffic destined to these addresses.
      By default ports start in promiscuous mode, so this feature
      is disabled.
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      145beee8
    • V
      bridge: Introduce BR_PROMISC flag · f3a6ddf1
      Vlad Yasevich 提交于
      Introduce a BR_PROMISC per-port flag that will help us track if the
      current port is supposed to be in promiscuous mode or not.  For now,
      always start in promiscuous mode.
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3a6ddf1
    • V
      bridge: Add functionality to sync static fdb entries to hw · 8db24af7
      Vlad Yasevich 提交于
      Add code that allows static fdb entires to be synced to the
      hw list for a specified port.  This will be used later to
      program ports that can function in non-promiscuous mode.
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8db24af7
    • V
      bridge: Keep track of ports capable of automatic discovery. · e028e4b8
      Vlad Yasevich 提交于
      By default, ports on the bridge are capable of automatic
      discovery of nodes located behind the port.  This is accomplished
      via flooding of unknown traffic (BR_FLOOD) and learning the
      mac addresses from these packets (BR_LEARNING).
      If the above functionality is disabled by turning off these
      flags, the port requires static configuration in the form
      of static FDB entries to function properly.
      
      This patch adds functionality to keep track of all ports
      capable of automatic discovery.  This will later be used
      to control promiscuity settings.
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e028e4b8
    • V
      bridge: Turn flag change macro into a function. · 63c3a622
      Vlad Yasevich 提交于
      Turn the flag change macro into a function to allow
      easier updates and to reduce space.
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63c3a622
  9. 14 5月, 2014 1 次提交
  10. 13 5月, 2014 1 次提交
  11. 05 5月, 2014 1 次提交
    • V
      bridge: superfluous skb->nfct check in br_nf_dev_queue_xmit · aff09ce3
      Vasily Averin 提交于
      Currently bridge can silently drop ipv4 fragments.
      If node have loaded nf_defrag_ipv4 module but have no nf_conntrack_ipv4,
      br_nf_pre_routing defragments incoming ipv4 fragments
      but nfct check in br_nf_dev_queue_xmit does not allow re-fragment combined
      packet back, and therefore it is dropped in br_dev_queue_push_xmit without
      incrementing of any failcounters
      
      It seems the only way to hit the ip_fragment code in the bridge xmit
      path is to have a fragment list whose reassembled fragments go over
      the mtu. This only happens if nf_defrag is enabled. Thanks to
      Florian Westphal for providing feedback to clarify this.
      
      Defragmentation ipv4 is required not only in conntracks but at least in
      TPROXY target and socket match, therefore #ifdef is changed from
      NF_CONNTRACK_IPV4 to NF_DEFRAG_IPV4
      Signed-off-by: NVasily Averin <vvs@openvz.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      aff09ce3
  12. 28 4月, 2014 1 次提交
  13. 24 4月, 2014 1 次提交
  14. 12 4月, 2014 1 次提交
  15. 05 4月, 2014 1 次提交
    • T
      netfilter: Can't fail and free after table replacement · c58dd2dd
      Thomas Graf 提交于
      All xtables variants suffer from the defect that the copy_to_user()
      to copy the counters to user memory may fail after the table has
      already been exchanged and thus exposed. Return an error at this
      point will result in freeing the already exposed table. Any
      subsequent packet processing will result in a kernel panic.
      
      We can't copy the counters before exposing the new tables as we
      want provide the counter state after the old table has been
      unhooked. Therefore convert this into a silent error.
      
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      c58dd2dd
  16. 01 4月, 2014 1 次提交
  17. 30 3月, 2014 1 次提交
  18. 29 3月, 2014 3 次提交
  19. 27 3月, 2014 1 次提交
  20. 15 3月, 2014 1 次提交
  21. 12 3月, 2014 2 次提交
  22. 07 3月, 2014 1 次提交
  23. 06 3月, 2014 1 次提交
  24. 25 2月, 2014 2 次提交
  25. 15 2月, 2014 1 次提交