1. 19 3月, 2014 1 次提交
  2. 15 3月, 2014 1 次提交
  3. 13 3月, 2014 1 次提交
  4. 10 3月, 2014 2 次提交
  5. 01 3月, 2014 2 次提交
  6. 28 2月, 2014 3 次提交
  7. 27 2月, 2014 3 次提交
  8. 26 2月, 2014 1 次提交
    • J
      Bluetooth: Ignore IRKs with no Identity Address · a9a58f86
      Johan Hedberg 提交于
      The Core Specification (4.1) leaves room for sending an SMP Identity
      Address Information PDU with an all-zeros BD_ADDR value. This
      essentially means that we would not have an Identity Address for the
      device and the only means of identifying it would be the IRK value
      itself.
      
      Due to lack of any known implementations behaving like this it's best to
      keep our implementation as simple as possible as far as handling such
      situations is concerned. This patch updates the Identity Address
      Information handler function to simply ignore the IRK received from such
      a device.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a9a58f86
  9. 24 2月, 2014 2 次提交
  10. 23 2月, 2014 2 次提交
  11. 20 2月, 2014 3 次提交
  12. 19 2月, 2014 5 次提交
  13. 18 2月, 2014 5 次提交
  14. 13 2月, 2014 2 次提交
    • J
      Bluetooth: Fix differentiating stored master vs slave LTK types · 98a0b845
      Johan Hedberg 提交于
      If LTK distribution happens in both directions we will have two LTKs for
      the same remote device: one which is used when we're connecting as
      master and another when we're connecting as slave. When looking up LTKs
      from the locally stored list we shouldn't blindly return the first match
      but also consider which type of key is in question. If we do not do this
      we may end up selecting an incorrect encryption key for a connection.
      
      This patch fixes the issue by always specifying to the LTK lookup
      functions whether we're looking for a master or a slave key.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      98a0b845
    • J
      Bluetooth: Enable LTK distribution to slave devices · 0cf73b9f
      Johan Hedberg 提交于
      So far we've only been requesting the LTK to be distributed to the
      master (initiator) of pairing, which is usually enough since it's the
      master that will establish future connections and initiate encryption.
      However, in the case that both devices support switching to the opposing
      role (which seems to be increasingly common) pairing will have to
      performed again since the "new" master will not have all information.
      
      As there is no real harm in it, this patch updates the code to always
      try distributing the LTK also to the slave device, thereby enabling role
      switches for future connections.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: NVinicius Gomes <vcgomes@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0cf73b9f
  15. 05 12月, 2013 1 次提交
  16. 04 12月, 2013 3 次提交
  17. 13 11月, 2013 1 次提交
  18. 18 10月, 2013 1 次提交
  19. 16 10月, 2013 1 次提交