1. 23 2月, 2015 1 次提交
    • R
      bridge: add vlan info to bridge setlink and dellink notification messages · b7853d73
      Roopa Prabhu 提交于
      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
      required.
      
      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: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7853d73
  2. 13 2月, 2015 1 次提交
  3. 10 2月, 2015 1 次提交
    • T
      bridge: Fix inability to add non-vlan fdb entry · 25d3b493
      Toshiaki Makita 提交于
      Bridge's default_pvid adds a vid by default, by which we cannot add a
      non-vlan fdb entry by default, because br_fdb_add() adds fdb entries for
      all vlans instead of a non-vlan one when any vlan is configured.
      
       # ip link add br0 type bridge
       # ip link set eth0 master br0
       # bridge fdb add 12:34:56:78:90:ab dev eth0 master temp
       # bridge fdb show brport eth0 | grep 12:34:56:78:90:ab
       12:34:56:78:90:ab dev eth0 vlan 1 static
      
      We expect a non-vlan fdb entry as well as vlan 1:
       12:34:56:78:90:ab dev eth0 static
      
      To fix this, we need to insert a non-vlan fdb entry if vlan is not
      specified, even when any vlan is configured.
      
      Fixes: 5be5a2df ("bridge: Add filtering support for default_pvid")
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25d3b493
  4. 08 2月, 2015 1 次提交
    • R
      bridge: add missing bridge port check for offloads · 1fd0bddb
      Roopa Prabhu 提交于
      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)
      
      net/bridge/br_netlink.c
         517
         518		if (p && protinfo) {
                          ^
      Check for NULL.
      Reported-By: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1fd0bddb
  5. 05 2月, 2015 2 次提交
  6. 02 2月, 2015 2 次提交
  7. 31 1月, 2015 1 次提交
  8. 26 1月, 2015 1 次提交
  9. 20 1月, 2015 1 次提交
    • F
      net: bridge: reject DSA-enabled master netdevices as bridge members · 8db0a2ee
      Florian Fainelli 提交于
      DSA-enabled master network devices with a switch tagging protocol should
      strip the protocol specific format before handing the frame over to
      higher layer.
      
      When adding such a DSA master network device as a bridge member, we go
      through the following code path when receiving a frame:
      
      __netif_receive_skb_core
      	-> first ptype check against ptype_all is not returning any
      	   handler for this skb
      
      	-> check and invoke rx_handler:
      		-> deliver frame to the bridge layer: br_handle_frame
      
      DSA registers a ptype handler with the fake ETH_XDSA ethertype, which is
      called *after* the bridge-layer rx_handler has run. br_handle_frame()
      tries to parse the frame it received from the DSA master network device,
      and will not be able to match any of its conditions and jumps straight
      at the end of the end of br_handle_frame() and returns
      RX_HANDLER_CONSUMED there.
      
      Since we returned RX_HANDLER_CONSUMED, __netif_receive_skb_core() stops
      RX processing for this frame and returns NET_RX_SUCCESS, so we never get
      a chance to call our switch tag packet processing logic and deliver
      frames to the DSA slave network devices, and so we do not get any
      functional bridge members at all.
      
      Instead of cluttering the bridge receive path with DSA-specific checks,
      and rely on assumptions about how __netif_receive_skb_core() is
      processing frames, we simply deny adding the DSA master network device
      (conduit interface) as a bridge member, leaving only the slave DSA
      network devices to be bridge members, since those will work correctly in
      all circumstances.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8db0a2ee
  10. 19 1月, 2015 1 次提交
  11. 18 1月, 2015 3 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
    • J
      net: replace br_fdb_external_learn_* calls with switchdev notifier events · 3aeb6617
      Jiri Pirko 提交于
      This patch benefits from newly introduced switchdev notifier and uses it
      to propagate fdb learn events from rocker driver to bridge. That avoids
      direct function calls and possible use by other listeners (ovs).
      Suggested-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3aeb6617
    • R
      bridge: fix setlink/dellink notifications · 02dba438
      Roopa Prabhu 提交于
      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
      	consistent
      
              - 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
      	example)
           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: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02dba438
  12. 16 1月, 2015 1 次提交
  13. 15 1月, 2015 1 次提交
    • A
      bridge: only provide proxy ARP when CONFIG_INET is enabled · d92cfdbb
      Arnd Bergmann 提交于
      When IPV4 support is disabled, we cannot call arp_send from
      the bridge code, which would result in a kernel link error:
      
      net/built-in.o: In function `br_handle_frame_finish':
      :(.text+0x59914): undefined reference to `arp_send'
      :(.text+0x59a50): undefined reference to `arp_tbl'
      
      This makes the newly added proxy ARP support in the bridge
      code depend on the CONFIG_INET symbol and lets the compiler
      optimize the code out to avoid the link error.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 95850116 ("bridge: Add support for IEEE 802.11 Proxy ARP")
      Cc: Kyeyoon Park <kyeyoonp@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d92cfdbb
  14. 14 1月, 2015 2 次提交
  15. 13 1月, 2015 3 次提交
  16. 06 1月, 2015 1 次提交
    • H
      net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined · 6cb69742
      Hubert Sokolowski 提交于
      Add checking whether the call to ndo_dflt_fdb_dump is needed.
      It is not expected to call ndo_dflt_fdb_dump unconditionally
      by some drivers (i.e. qlcnic or macvlan) that defines
      own ndo_fdb_dump. Other drivers define own ndo_fdb_dump
      and don't want ndo_dflt_fdb_dump to be called at all.
      At the same time it is desirable to call the default dump
      function on a bridge device.
      Fix attributes that are passed to dev->netdev_ops->ndo_fdb_dump.
      Add extra checking in br_fdb_dump to avoid duplicate entries
      as now filter_dev can be NULL.
      
      Following tests for filtering have been performed before
      the change and after the patch was applied to make sure
      they are the same and it doesn't break the filtering algorithm.
      
      [root@localhost ~]# cd /root/iproute2-3.18.0/bridge
      [root@localhost bridge]# modprobe dummy
      [root@localhost bridge]# ./bridge fdb add f1:f2:f3:f4:f5:f6 dev dummy0
      [root@localhost bridge]# brctl addbr br0
      [root@localhost bridge]# brctl addif  br0 dummy0
      [root@localhost bridge]# ip link set dev br0 address 02:00:00:12:01:04
      [root@localhost bridge]# # show all
      [root@localhost bridge]# ./bridge fdb show
      33:33:00:00:00:01 dev p2p1 self permanent
      01:00:5e:00:00:01 dev p2p1 self permanent
      33:33:ff:ac:ce:32 dev p2p1 self permanent
      33:33:00:00:02:02 dev p2p1 self permanent
      01:00:5e:00:00:fb dev p2p1 self permanent
      33:33:00:00:00:01 dev p7p1 self permanent
      01:00:5e:00:00:01 dev p7p1 self permanent
      33:33:ff:79:50:53 dev p7p1 self permanent
      33:33:00:00:02:02 dev p7p1 self permanent
      01:00:5e:00:00:fb dev p7p1 self permanent
      f2:46:50:85:6d:d9 dev dummy0 master br0 permanent
      f2:46:50:85:6d:d9 dev dummy0 vlan 1 master br0 permanent
      33:33:00:00:00:01 dev dummy0 self permanent
      f1:f2:f3:f4:f5:f6 dev dummy0 self permanent
      33:33:00:00:00:01 dev br0 self permanent
      02:00:00:12:01:04 dev br0 vlan 1 master br0 permanent
      02:00:00:12:01:04 dev br0 master br0 permanent
      [root@localhost bridge]# # filter by bridge
      [root@localhost bridge]# ./bridge fdb show br br0
      f2:46:50:85:6d:d9 dev dummy0 master br0 permanent
      f2:46:50:85:6d:d9 dev dummy0 vlan 1 master br0 permanent
      33:33:00:00:00:01 dev dummy0 self permanent
      f1:f2:f3:f4:f5:f6 dev dummy0 self permanent
      33:33:00:00:00:01 dev br0 self permanent
      02:00:00:12:01:04 dev br0 vlan 1 master br0 permanent
      02:00:00:12:01:04 dev br0 master br0 permanent
      [root@localhost bridge]# # filter by port
      [root@localhost bridge]# ./bridge fdb show brport dummy0
      f2:46:50:85:6d:d9 master br0 permanent
      f2:46:50:85:6d:d9 vlan 1 master br0 permanent
      33:33:00:00:00:01 self permanent
      f1:f2:f3:f4:f5:f6 self permanent
      [root@localhost bridge]# # filter by port + bridge
      [root@localhost bridge]# ./bridge fdb show br br0 brport dummy0
      f2:46:50:85:6d:d9 master br0 permanent
      f2:46:50:85:6d:d9 vlan 1 master br0 permanent
      33:33:00:00:00:01 self permanent
      f1:f2:f3:f4:f5:f6 self permanent
      [root@localhost bridge]#
      Signed-off-by: NHubert Sokolowski <hubert.sokolowski@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cb69742
  17. 03 12月, 2014 6 次提交
  18. 27 11月, 2014 3 次提交
  19. 22 11月, 2014 1 次提交
  20. 17 11月, 2014 1 次提交
    • L
      bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries · f0b4eece
      Linus Lüssing 提交于
      Ebtables on the OUTPUT chain (NF_BR_LOCAL_OUT) would not work as expected
      for both locally generated IGMP and MLD queries. The IP header specific
      filter options are off by 14 Bytes for netfilter (actual output on
      interfaces is fine).
      
      NF_HOOK() expects the skb->data to point to the IP header, not the
      ethernet one (while dev_queue_xmit() does not). Luckily there is an
      br_dev_queue_push_xmit() helper function already - let's just use that.
      
      Introduced by eb1d1641
      ("bridge: Add core IGMP snooping support")
      
      Ebtables example:
      
      $ ebtables -I OUTPUT -p IPv6 -o eth1 --logical-out br0 \
      	--log --log-level 6 --log-ip6 --log-prefix="~EBT: " -j DROP
      
      before (broken):
      
      ~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
      	MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
      	SRC=64a4:39c2:86dd:6000:0000:0020:0001:fe80 IPv6 \
      	DST=0000:0000:0000:0004:64ff:fea4:39c2:ff02, \
      	IPv6 priority=0x3, Next Header=2
      
      after (working):
      
      ~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
      	MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
      	SRC=fe80:0000:0000:0000:0004:64ff:fea4:39c2 IPv6 \
      	DST=ff02:0000:0000:0000:0000:0000:0000:0001, \
      	IPv6 priority=0x0, Next Header=0
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      f0b4eece
  21. 13 11月, 2014 1 次提交
    • F
      netfilter: fix various sparse warnings · 56768644
      Florian Westphal 提交于
      net/bridge/br_netfilter.c:870:6: symbol 'br_netfilter_enable' was not declared. Should it be static?
        no; add include
      net/ipv4/netfilter/nft_reject_ipv4.c:22:6: symbol 'nft_reject_ipv4_eval' was not declared. Should it be static?
        yes
      net/ipv6/netfilter/nf_reject_ipv6.c:16:6: symbol 'nf_send_reset6' was not declared. Should it be static?
        no; add include
      net/ipv6/netfilter/nft_reject_ipv6.c:22:6: symbol 'nft_reject_ipv6_eval' was not declared. Should it be static?
        yes
      net/netfilter/core.c:33:32: symbol 'nf_ipv6_ops' was not declared. Should it be static?
        no; add include
      net/netfilter/xt_DSCP.c:40:57: cast truncates bits from constant value (ffffff03 becomes 3)
      net/netfilter/xt_DSCP.c:57:59: cast truncates bits from constant value (ffffff03 becomes 3)
        add __force, 3 is what we want.
      net/ipv4/netfilter/nf_log_arp.c:77:6: symbol 'nf_log_arp_packet' was not declared. Should it be static?
        yes
      net/ipv4/netfilter/nf_reject_ipv4.c:17:6: symbol 'nf_send_reset' was not declared. Should it be static?
        no; add include
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      56768644
  22. 04 11月, 2014 1 次提交
  23. 31 10月, 2014 3 次提交
    • P
      netfilter: nft_reject_bridge: restrict reject to prerouting and input · 127917c2
      Pablo Neira Ayuso 提交于
      Restrict the reject expression to the prerouting and input bridge
      hooks. If we allow this to be used from forward or any other later
      bridge hook, if the frame is flooded to several ports, we'll end up
      sending several reject packets, one per cloned packet.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      127917c2
    • P
      netfilter: nft_reject_bridge: don't use IP stack to reject traffic · 523b929d
      Pablo Neira Ayuso 提交于
      If the packet is received via the bridge stack, this cannot reject
      packets from the IP stack.
      
      This adds functions to build the reject packet and send it from the
      bridge stack. Comments and assumptions on this patch:
      
      1) Validate the IPv4 and IPv6 headers before further processing,
         given that the packet comes from the bridge stack, we cannot assume
         they are clean. Truncated packets are dropped, we follow similar
         approach in the existing iptables match/target extensions that need
         to inspect layer 4 headers that is not available. This also includes
         packets that are directed to multicast and broadcast ethernet
         addresses.
      
      2) br_deliver() is exported to inject the reject packet via
         bridge localout -> postrouting. So the approach is similar to what
         we already do in the iptables reject target. The reject packet is
         sent to the bridge port from which we have received the original
         packet.
      
      3) The reject packet is forged based on the original packet. The TTL
         is set based on sysctl_ip_default_ttl for IPv4 and per-net
         ipv6.devconf_all hoplimit for IPv6.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      523b929d
    • P
      netfilter: nf_tables_bridge: update hook_mask to allow {pre,post}routing · 4d87716c
      Pablo Neira Ayuso 提交于
      Fixes: 36d2af59 ("netfilter: nf_tables: allow to filter from prerouting and postrouting")
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      4d87716c
  24. 28 10月, 2014 1 次提交
    • K
      bridge: Add support for IEEE 802.11 Proxy ARP · 95850116
      Kyeyoon Park 提交于
      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
      medium.
      
      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: NKyeyoon Park <kyeyoonp@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      95850116