1. 16 12月, 2015 7 次提交
  2. 15 12月, 2015 3 次提交
  3. 12 12月, 2015 1 次提交
  4. 11 12月, 2015 2 次提交
    • D
      Bluetooth: Do not filter multicast addresses by default · 4ada1282
      Danny Schweizer 提交于
      A Linux PC is connected with another device over Bluetooth PAN using a
      BNEP interface.
      
      Whenever a packet is tried to be sent over the BNEP interface, the
      function "bnep_net_xmit()" in "net/bluetooth/bnep/netdev.c" is called.
      This function calls "bnep_net_mc_filter()", which checks (if the
      destination address is multicast) if the address is set in a certain
      multicast filter (&s->mc_filter). If it is not, then it is not sent out.
      
      This filter is only changed in two other functions, found in
      net/bluetooth/bnep/core.c": in "bnep_ctrl_set_mc_filter()", which is
      only called if a message of type "BNEP_FILTER_MULTI_ADDR_SET" is
      received. Otherwise, it is set in "bnep_add_connection()", where it is
      set to a default value which only adds the broadcast address to the
      filter:
      
      set_bit(bnep_mc_hash(dev->broadcast), (ulong *) &s->mc_filter);
      
      To sum up, if the BNEP interface does not receive any message of type
      "BNEP_FILTER_MULTI_ADDR_SET", it will not send out any messages with
      multicast destination addresses except for broadcast.
      
      However, in the BNEP specification (page 27 in
      http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf), it is said
      that per default, all multicast addresses should not be filtered, i.e.
      the BNEP interface should be able to send packets with any multicast
      destination address.
      
      It seems that the default case is wrong: the multicast filter should not
      block almost all multicast addresses, but should not filter out any.
      
      This leads to the problem that e.g. Neighbor Solicitation messages sent
      with Bluetooth PAN over the BNEP interface to a multicast destination
      address other than broadcast are blocked and not sent out.
      
      Therefore, in the default case, we set the mc_filter to ~0LL to not
      filter out any multicast addresses.
      Signed-off-by: NDanny Schweizer <danny.schweizer@proofnet.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4ada1282
    • A
      mac802154: tx: fix synced xmit deadlock · c3838353
      Alexander Aring 提交于
      This patch reverts 6001d522 ("mac802154: tx: don't allow if down while
      sync tx"). This has side effects with stop callback which flush the
      transmit workqueue. The stop callback will wait until the workqueue is
      flushed and holding the rtnl lock. That means it can happen that the stop
      callback waits forever because it try to lock the rtnl mutex which is
      already hold by stop callback.
      
      Cc: Michael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c3838353
  5. 10 12月, 2015 27 次提交
新手
引导
客服 返回
顶部