1. 16 5月, 2014 4 次提交
  2. 10 5月, 2014 1 次提交
  3. 09 5月, 2014 2 次提交
    • M
      Bluetooth: Increment management interface revision · b75cf9cd
      Marcel Holtmann 提交于
      This patch increments the management interface revision due to the
      changes with the Device Found management event and other fixes.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      b75cf9cd
    • P
      Bluetooth: btusb: Add Broadcom patch RAM support · 10d4c673
      Petri Gynther 提交于
      After hardware reset, some BCM Bluetooth adapters obtain their initial firmware
      from OTPROM chip. Once this initial firmware is running, the firmware can be
      further upgraded over HCI interface with .hcd files provided by Broadcom. This
      is also known as "patch RAM" support. This change implements that.
      
      If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues
      to operate with the initial firmware. Sample kernel log:
        hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
        Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-22be.hcd not found
      
      If the .hcd file is found, btusb driver pushes it to the BCM Bluetooth adapter and
      it starts using the new firmware. Sample kernel log:
        hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
        Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e
        Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=1389 lmp_ver=06 lmp_subver=220e
      
      Above, we can see that hci_rev goes from 1000 to 1389 as a result of the upgrade.
      Signed-off-by: NPetri Gynther <pgynther@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      10d4c673
  4. 08 5月, 2014 2 次提交
  5. 06 5月, 2014 1 次提交
  6. 24 4月, 2014 3 次提交
  7. 12 4月, 2014 4 次提交
    • M
      Bluetooth: Request MITM Protection when initiator · b16c6604
      Mikel Astiz 提交于
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is requested or not (Bluetooth Core Specification v4.0
      Volume 3, part C, section 6.5.3) when replying to an
      HCI_EV_IO_CAPA_REQUEST event.
      
      The recommendation is *not* to set this flag "unless the security
      policy of an available local service requires MITM Protection"
      (regardless of the bonding type). However, the kernel doesn't
      necessarily have this information and therefore the safest choice is
      to always use MITM Protection, also for General Bonding.
      
      This patch changes the behavior for the General Bonding initiator
      role, always requesting MITM Protection even if no high security level
      is used. Depending on the remote capabilities, the protection might
      not be actually used, and we will accept this locally unless of course
      a high security level was originally required.
      
      Note that this was already done for Dedicated Bonding. No-Bonding is
      left unmodified because MITM Protection is normally not desired in
      these cases.
      Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: NTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      b16c6604
    • T
      Bluetooth: Use MITM Protection when IO caps allow it · 7e74170a
      Timo Mueller 提交于
      When responding to a remotely-initiated pairing procedure, a MITM
      protected SSP associaton model can be used for pairing if both local
      and remote IO capabilities are set to something other than
      NoInputNoOutput, regardless of the bonding type (Dedicated or
      General).
      
      This was already done for Dedicated Bonding but this patch proposes to
      use the same policy for General Bonding as well.
      
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is used ot not (Bluetooth Core Specification v4.0 Volume 3,
      part C, section 6.5.3).
      
      Note however that the recommendation is *not* to set this flag "unless
      the security policy of an available local service requires MITM
      Protection" (for both Dedicated and General Bonding). However, as we are
      already requiring MITM for Dedicated Bonding, we will follow this
      behaviour also for General Bonding.
      Signed-off-by: NTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      7e74170a
    • M
      Bluetooth: Refactor code for outgoing dedicated bonding · 6fd6b915
      Mikel Astiz 提交于
      Do not always set the MITM protection requirement by default in the
      field conn->auth_type, since this will be added later in
      hci_io_capa_request_evt(), as part of the requirements specified in
      HCI_OP_IO_CAPABILITY_REPLY.
      
      This avoids a hackish exception for the auto-reject case, but doesn't
      change the behavior of the code at all.
      Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      6fd6b915
    • M
      Bluetooth: Refactor hci_get_auth_req() · b7f94c88
      Mikel Astiz 提交于
      Refactor the code without changing its behavior by handling the
      no-bonding cases first followed by General Bonding.
      Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: NTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      b7f94c88
  8. 29 3月, 2014 2 次提交
  9. 28 3月, 2014 5 次提交
  10. 27 3月, 2014 15 次提交
  11. 24 3月, 2014 1 次提交