1. 26 Jul, 2015 1 commit
  2. 02 Jul, 2015 1 commit
  3. 12 May, 2015 3 commits
  4. 29 Apr, 2015 1 commit
    • Nicolas Dichtel's avatar
      bridge/nl: remove wrong use of NLM_F_MULTI · 46c264da
      Nicolas Dichtel authored
      NLM_F_MULTI must be used only when a NLMSG_DONE message is sent. In fact,
      it is sent only at the end of a dump.
      Libraries like libnl will wait forever for NLMSG_DONE.
      Fixes: e5a55a89 ("net: create generic bridge ops")
      Fixes: 815cccbf
       ("ixgbe: add setlink, getlink support to ixgbe and ixgbevf")
      CC: John Fastabend <john.r.fastabend@intel.com>
      CC: Sathya Perla <sathya.perla@emulex.com>
      CC: Subbu Seetharaman <subbu.seetharaman@emulex.com>
      CC: Ajit Khaparde <ajit.khaparde@emulex.com>
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: intel-wired-lan@lists.osuosl.org
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: Scott Feldman <sfeldma@gmail.com>
      CC: Stephen Hemminger <stephen@networkplumber.org>
      CC: bridge@lists.linux-foundation.org
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 02 Apr, 2015 1 commit
  6. 19 Mar, 2015 1 commit
  7. 05 Mar, 2015 1 commit
    • Jouni Malinen's avatar
      bridge: Extend Proxy ARP design to allow optional rules for Wi-Fi · 842a9ae0
      Jouni Malinen authored
      This extends the design in commit 95850116
       ("bridge: Add support for
      IEEE 802.11 Proxy ARP") with optional set of rules that are needed to
      meet the IEEE 802.11 and Hotspot 2.0 requirements for ProxyARP. The
      previously added BR_PROXYARP behavior is left as-is and a new
      BR_PROXYARP_WIFI alternative is added so that this behavior can be
      configured from user space when required.
      In addition, this enables proxyarp functionality for unicast ARP
      requests for both BR_PROXYARP and BR_PROXYARP_WIFI since it is possible
      to use unicast as well as broadcast for these frames.
      The key differences in functionality:
      - uses the flag on the bridge port on which the request frame was
        received to determine whether to reply
      - block bridge port flooding completely on ports that enable proxy ARP
      - uses the flag on the bridge port to which the target device of the
        request belongs
      - block bridge port flooding selectively based on whether the proxyarp
        functionality replied
      Signed-off-by: default avatarJouni Malinen <jouni@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 04 Mar, 2015 1 commit
  9. 26 Feb, 2015 1 commit
    • Roopa Prabhu's avatar
      bridge: fix link notification skb size calculation to include vlan ranges · fed0a159
      Roopa Prabhu authored
      my previous patch skipped vlan range optimizations during skb size
      calculations for simplicity.
      This incremental patch considers vlan ranges during
      skb size calculations. This leads to a bit of code duplication
      in the fill and size calculation functions. But, I could not find a
      prettier way to do this. will take any suggestions.
      Previously, I had reused the existing br_get_link_af_size size calculation
      function to calculate skb size for notifications. Reusing it this time
      around creates some change in behaviour issues for the usual
      .get_link_af_size callback.
      This patch adds a new br_get_link_af_size_filtered() function to
      base the size calculation on the incoming filter flag and include
      vlan ranges.
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Reviewed-by: default avatarScott Feldman <sfeldma@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 23 Feb, 2015 1 commit
    • Roopa Prabhu's avatar
      bridge: add vlan info to bridge setlink and dellink notification messages · b7853d73
      Roopa Prabhu authored
      vlan add/deletes are not notified to userspace today. This patch adds
      vlan info to bridge newlink/dellink notifications generated from the
      bridge driver. Notifications use the RTEXT_FILTER_BRVLAN_COMPRESSED
      flag to compress vlans into ranges whereever applicable.
      The size calculations does not take ranges into account for
      simplicity.  This has the potential for allocating a larger skb than
      There is an existing inconsistency with bridge NEWLINK and DELLINK
      change notifications. Both generate NEWLINK notifications.  Since its
      always a NEWLINK notification, this patch includes all vlans the port
      belongs to in the notification. The NEWLINK and DELLINK request
      messages however only include the vlans to be added and deleted.
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 08 Feb, 2015 1 commit
    • Roopa Prabhu's avatar
      bridge: add missing bridge port check for offloads · 1fd0bddb
      Roopa Prabhu authored
      This patch fixes a missing bridge port check caught by smatch.
      setlink/dellink of attributes like vlans can come for a bridge device
      and there is no need to offload those today. So, this patch adds a bridge
      port check. (In these cases however, the BRIDGE_SELF flags will always be set
      and we may not hit a problem with the current code).
      smatch complaint:
      The patch 68e331c7
      : "bridge: offload bridge port attributes to
      switch asic if feature flag set" from Jan 29, 2015, leads to the
      following Smatch complaint:
      net/bridge/br_netlink.c:552 br_setlink()
      	 error: we previously assumed 'p' could be null (see line 518)
         518		if (p && protinfo) {
      Check for NULL.
      Reported-By: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  12. 02 Feb, 2015 2 commits
  13. 31 Jan, 2015 1 commit
  14. 26 Jan, 2015 1 commit
  15. 18 Jan, 2015 2 commits
    • Johannes Berg's avatar
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg authored
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      This makes the very common pattern of
        if (genlmsg_end(...) < 0) { ... }
      be a whole bunch of dead code. Many places also simply do
        return nlmsg_end(...);
      and the caller is expected to deal with it.
      This also commonly (at least for me) causes errors, because it is very
      common to write
        if (my_function(...))
          /* error condition */
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Roopa Prabhu's avatar
      bridge: fix setlink/dellink notifications · 02dba438
      Roopa Prabhu authored
      problems with bridge getlink/setlink notifications today:
              - bridge setlink generates two notifications to userspace
                      - one from the bridge driver
                      - one from rtnetlink.c (rtnl_bridge_notify)
              - dellink generates one notification from rtnetlink.c. Which
      	means bridge setlink and dellink notifications are not
              - Looking at the code it appears,
      	If both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF were set,
              the size calculation in rtnl_bridge_notify can be wrong.
              Example: if you set both BRIDGE_FLAGS_MASTER and BRIDGE_FLAGS_SELF
              in a setlink request to rocker dev, rtnl_bridge_notify will
      	allocate skb for one set of bridge attributes, but,
      	both the bridge driver and rocker dev will try to add
      	attributes resulting in twice the number of attributes
      	being added to the skb.  (rocker dev calls ndo_dflt_bridge_getlink)
      There are multiple options:
      1) Generate one notification including all attributes from master and self:
         But, I don't think it will work, because both master and self may use
         the same attributes/policy. Cannot pack the same set of attributes in a
         single notification from both master and slave (duplicate attributes).
      2) Generate one notification from master and the other notification from
         self (This seems to be ideal):
           For master: the master driver will send notification (bridge in this
           For self: the self driver will send notification (rocker in the above
      	example. It can use helpers from rtnetlink.c to do so. Like the
      	ndo_dflt_bridge_getlink api).
      This patch implements 2) (leaving the 'rtnl_bridge_notify' around to be used
      with 'self').
      v1->v2 :
      	- rtnl_bridge_notify is now called only for self,
      	so, remove 'BRIDGE_FLAGS_SELF' check and cleanup a few things
      	- rtnl_bridge_dellink used to always send a RTM_NEWLINK msg
      	earlier. So, I have changed the notification from br_dellink to
      	go as RTM_NEWLINK
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  16. 13 Jan, 2015 1 commit
  17. 12 Jan, 2015 2 commits
  18. 26 Nov, 2014 1 commit
  19. 27 Oct, 2014 1 commit
    • Kyeyoon Park's avatar
      bridge: Add support for IEEE 802.11 Proxy ARP · 95850116
      Kyeyoon Park authored
      This feature is defined in IEEE Std 802.11-2012, 10.23.13. It allows
      the AP devices to keep track of the hardware-address-to-IP-address
      mapping of the mobile devices within the WLAN network.
      The AP will learn this mapping via observing DHCP, ARP, and NS/NA
      frames. When a request for such information is made (i.e. ARP request,
      Neighbor Solicitation), the AP will respond on behalf of the
      associated mobile device. In the process of doing so, the AP will drop
      the multicast request frame that was intended to go out to the wireless
      It was recommended at the LKS workshop to do this implementation in
      the bridge layer. vxlan.c is already doing something very similar.
      The DHCP snooping code will be added to the userspace application
      (hostapd) per the recommendation.
      This RFC commit is only for IPv4. A similar approach in the bridge
      layer will be taken for IPv6 as well.
      Signed-off-by: default avatarKyeyoon Park <kyeyoonp@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  20. 02 Oct, 2014 1 commit
  21. 26 Sep, 2014 1 commit
    • Pablo Neira Ayuso's avatar
      netfilter: bridge: move br_netfilter out of the core · 34666d46
      Pablo Neira Ayuso authored
      Jesper reported that br_netfilter always registers the hooks since
      this is part of the bridge core. This harms performance for people that
      don't need this.
      This patch modularizes br_netfilter so it can be rmmod'ed, thus,
      the hooks can be unregistered. I think the bridge netfilter should have
      been a separated module since the beginning, Patrick agreed on that.
      Note that this is breaking compatibility for users that expect that
      bridge netfilter is going to be available after explicitly 'modprobe
      bridge' or via automatic load through brctl.
      However, the damage can be easily undone by modprobing br_netfilter.
      The bridge core also spots a message to provide a clue to people that
      didn't notice that this has been deprecated.
      On top of that, the plan is that nftables will not rely on this software
      layer, but integrate the connection tracking into the bridge layer to
      enable stateful filtering and NAT, which is was bridge netfilter users
      seem to require.
      This patch still keeps the fake_dst_ops in the bridge core, since this
      is required by when the bridge port is initialized. So we can safely
      modprobe/rmmod br_netfilter anytime.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
  22. 09 Sep, 2014 5 commits
  23. 04 Aug, 2014 1 commit
  24. 16 May, 2014 1 commit
  25. 27 Apr, 2014 1 commit
  26. 02 Jan, 2014 1 commit
  27. 20 Dec, 2013 1 commit
  28. 11 Dec, 2013 1 commit
  29. 18 Oct, 2013 1 commit
  30. 16 Sep, 2013 1 commit
  31. 21 Aug, 2013 1 commit