1. 17 9月, 2013 1 次提交
    • A
      Bluetooth: Fix security level for peripheral role · f8776218
      Andre Guedes 提交于
      While playing the peripheral role, the host gets a LE Long Term Key
      Request Event from the controller when a connection is established
      with a bonded device. The host then informs the LTK which should be
      used for the connection. Once the link is encrypted, the host gets
      an Encryption Change Event.
      
      Therefore we should set conn->pending_sec_level instead of conn->
      sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
      properly updated in hci_encrypt_change_evt.
      
      Moreover, since we have a LTK associated to the device, we have at
      least BT_SECURITY_MEDIUM security level.
      
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      f8776218
  2. 21 8月, 2013 2 次提交
    • F
      Bluetooth: Add SCO connection fallback · 2dea632f
      Frédéric Dalleau 提交于
      When initiating a transparent eSCO connection, make use of T2 settings
      at first try. T2 is the recommended settings from HFP 1.6 WideBand
      Speech. Upon connection failure, try T1 settings.
      
      When CVSD is requested and eSCO is supported, try to establish eSCO
      connection using S3 settings. If it fails, fallback in sequence to S2,
      S1, D1, D0 settings.
      
      To know which setting should be used, conn->attempt is used. It
      indicates the currently ongoing SCO connection attempt and can be used
      as the index for the fallback settings table.
      
      These setting and the fallback order are described in Bluetooth HFP 1.6
      specification p. 101.
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      2dea632f
    • F
      Bluetooth: Handle specific error for SCO connection fallback · 1a4c958c
      Frédéric Dalleau 提交于
      Synchronous Connection Complete event can return error "Connection
      Rejected due to Limited resources (0x10)".
      Handling this error is required for SCO connection fallback. This error
      happens when the server tried to accept the connection but failed to
      negotiate settings.
      This error code has been verified experimentally by sending a T2 request
      to a T1 only SCO listener.
      
      Client dump follows :
      
      < HCI Command (0x01|0x0028) plen 17 [hci0] 3.696064
              Handle: 12
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 13
              Setting: 0x0003
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x0380
      > HCI Event (0x0f) plen 4 [hci0] 3.697034
            Setup Synchronous Connection (0x01|0x0028) ncmd 1
              Status: Success (0x00)
      > HCI Event (0x2c) plen 17 [hci0] 3.736059
              Status: Connection Rejected due to Limited Resources (0x0d)
              Handle: 0
              Address: xx:xx:xx:xx:xx:AB (OUI 70-F3-95)
              Link type: eSCO (0x02)
              Transmission interval: 0x0c
              Retransmission window: 0x06
              RX packet length: 60
              TX packet length: 60
              Air mode: Transparent (0x03)
      
      Server dump follows :
      
      > HCI Event (0x04) plen 10 [hci0] 4.741513
              Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
              Class: 0x620100
                Major class: Computer (desktop, notebook, PDA, organizers)
                Minor class: Uncategorized, code for device not assigned
                Networking (LAN, Ad hoc)
                Audio (Speaker, Microphone, Headset)
                Telephony (Cordless telephony, Modem, Headset)
              Link type: eSCO (0x02)
      < HCI Command (0x01|0x0029) plen 21 [hci0] 4.743269
              Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
              Transmit bandwidth: 8000
              Receive bandwidth: 8000
              Max latency: 13
              Setting: 0x0003
              Retransmission effort: Optimize for link quality (0x02)
              Packet type: 0x03c1
      > HCI Event (0x0f) plen 4 [hci0] 4.745517
            Accept Synchronous Connection (0x01|0x0029) ncmd 1
              Status: Success (0x00)
      > HCI Event (0x2c) plen 17 [hci0] 4.749508
              Status: Connection Rejected due to Limited Resources (0x0d)
              Handle: 0
              Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
              Link type: eSCO (0x02)
              Transmission interval: 0x0c
              Retransmission window: 0x06
              RX packet length: 60
              TX packet length: 60
              Air mode: Transparent (0x03)
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      1a4c958c
  3. 25 7月, 2013 2 次提交
  4. 23 6月, 2013 6 次提交
  5. 18 4月, 2013 5 次提交
    • A
      Bluetooth: Rename LE_SCANNING_* macros · 76a388be
      Andre Guedes 提交于
      This patch renames LE_SCANNING_ENABLED and LE_SCANNING_DISABLED
      macros to LE_SCAN_ENABLE and LE_SCAN_DISABLE in order to keep
      the same prefix others LE scan macros have.
      
      It also fixes le_scan_enable_req function so it uses the LE_SCAN_
      ENABLE macro instead of a magic number.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      76a388be
    • J
      Bluetooth: Add reading of all local feature pages · d2c5d77f
      Johan Hedberg 提交于
      With the introduction of CSA4 there is now also a features page number 2
      available. This patch increments the maximum supported page number to 2
      and adds code for reading all available pages (as long as we have
      support for them - indicated by HCI_MAX_PAGES).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      d2c5d77f
    • J
      Bluetooth: Track feature pages in a single table · cad718ed
      Johan Hedberg 提交于
      The local and remote features are organized by page number. Page 0
      are the LMP features, page 1 the host features, and any pages beyond 1
      features that future core specification versions may define. So far
      we've only had the first two pages and two separate variables has been
      convenient enough, however with the introduction of Core Specification
      Addendum 4 there are features defined on page 2.
      
      Instead of requiring the addition of a new variable each time a new page
      number is defined, this patch refactors the code to use a single table
      for the features. The patch needs to update both the hci_dev and
      hci_conn structures since there are macros that depend on the features
      being represented in the same way in both of them.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      cad718ed
    • F
      Bluetooth: Move and rename hci_conn_accept · fa5513be
      Frédéric Dalleau 提交于
      Since this function is only used by sco, move it from hci_event.c to
      sco.c and rename to sco_conn_defer_accept. Make it static.
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      fa5513be
    • J
      Bluetooth: Fix incorrect SSP mode bit for non SSP devices · bbb0eada
      Jaganath Kanakkassery 提交于
      Some faulty non SSP devices send extended inquiry response
      during device discovery which is a violation of 2.1 specification.
      So for these devices we set SSP bit during acl connection
      initiation thinking that it is an SSP device. But for these
      devices, in remote host features event SSP supported bit
      will be off. But we are not clearing the SSP bit in that case
      and eventually SSP bit in conn flag will be incorrectly set for
      these devices.
      
      The software which has caused this issue is MecApp
      http://www.mecel.se/products/bluetooth/downloads/MecApp_download
      
      This patch does a workaround by clearing the SSP bit if it is
      not supported in remote host features event
      
      hcidump log
      ----------
      
      < HCI Command: Inquiry (0x01|0x0001) plen 5
          lap 0x9e8b33 len 4 num 0
      > HCI Event: Command Status (0x0f) plen 4
          Inquiry (0x01|0x0001) status 0x00 ncmd 1
      > HCI Event: Extended Inquiry Result (0x2f) plen 255
          bdaddr 00:1B:DC:05:B5:25 mode 1 clkoffset 0x3263 class 0x3c0000 rssi -77
          Unknown type 0x42 with 8 bytes data
          Unknown type 0x1e with 2 bytes data
      > HCI Event: Inquiry Complete (0x01) plen 1
          status 0x00
      
      < HCI Command: Create Connection (0x01|0x0005) plen 13
          bdaddr 00:1B:DC:05:B5:25 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
          Packet type: DM1 DM3 DM5 DH1 DH3 DH5
      > HCI Event: Command Status (0x0f) plen 4
          Create Connection (0x01|0x0005) status 0x00 ncmd 1
      > HCI Event: Connect Complete (0x03) plen 11
          status 0x00 handle 12 bdaddr 00:1B:DC:05:B5:25 type ACL encrypt 0x00
      < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
      > HCI Event: Read Remote Supported Features (0x0b) plen 11
          status 0x00 handle 12
          Features: 0xff 0xff 0x8f 0x7e 0xd8 0x1f 0x5b 0x87
      < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
          handle 12 page 1
      > HCI Event: Command Status (0x0f) plen 4
          Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
      > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
          bdaddr 00:1B:DC:05:B5:25 mode 1
      > HCI Event: Max Slots Change (0x1b) plen 3
          handle 12 slots 5
      > HCI Event: Read Remote Extended Features (0x23) plen 13
          status 0x00 handle 12 page 1 max 0
          Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
      < HCI Command: Remote Name Request (0x01|0x0019) plen 10
          bdaddr 00:1B:DC:05:B5:25 mode 2 clkoffset 0x0000
      > HCI Event: Command Status (0x0f) plen 4
          Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
      > HCI Event: Remote Name Req Complete (0x07) plen 255
          status 0x00 bdaddr 00:1B:DC:05:B5:25 name 'Bluetooth PTS Radio v4'
      < HCI Command: Authentication Requested (0x01|0x0011) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
      > HCI Event: Link Key Request (0x17) plen 6
          bdaddr 00:1B:DC:05:B5:25
      < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
          bdaddr 00:1B:DC:05:B5:25
      > HCI Event: Command Complete (0x0e) plen 10
          Link Key Request Negative Reply (0x01|0x000c) ncmd 1
          status 0x00 bdaddr 00:1B:DC:05:B5:25
      > HCI Event: PIN Code Request (0x16) plen 6
          bdaddr 00:1B:DC:05:B5:25
      Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      bbb0eada
  6. 17 4月, 2013 1 次提交
    • D
      Bluetooth: remove unneeded hci_conn_hold/put_device() · fc225c3f
      David Herrmann 提交于
      hci_conn_hold/put_device() is used to control when hci_conn->dev is no
      longer needed and can be deleted from the system. Lets first look how they
      are currently used throughout the code (excluding HIDP!).
      
      All code that uses hci_conn_hold_device() looks like this:
          ...
          hci_conn_hold_device();
          hci_conn_add_sysfs();
          ...
      On the other side, hci_conn_put_device() is exclusively used in
      hci_conn_del().
      
      So, considering that hci_conn_del() must not be called twice (which would
      fail horribly), we know that hci_conn_put_device() is only called _once_
      (which is in hci_conn_del()).
      On the other hand, hci_conn_add_sysfs() must not be called twice, either
      (it would call device_add twice, which breaks the device, see
      drivers/base/core.c). So we know that hci_conn_hold_device() is also
      called only once (it's only called directly before hci_conn_add_sysfs()).
      
      So hold and put are known to be called only once. That means we can safely
      remove them and directly call hci_conn_del_sysfs() in hci_conn_del().
      
      But there is one issue left: HIDP also uses hci_conn_hold/put_device().
      However, this case can be ignored and simply removed as it is totally
      broken. The issue is, the only thing HIDP delays with
      hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs.
      But, the hci_conn device has no mechanism to get notified when its own
      parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_
      control when it is removed but only when the device object is created
      and destroyed.
      And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs,
      which itself causes hci_conn_del() to be called, but it does _not_ cause
      hci_conn_del_sysfs() to be called, which is wrong.
      
      Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This
      guarantees that a hci_conn object is removed from sysfs _before_ its
      parent hci_dev is removed.
      
      The changes to HIDP look scary, wrong and broken. However, if you look at
      the HIDP session management, you will notice they're already broken in the
      exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the
      time).
      So this patch only makes HIDP look _scary_ and _obviously broken_. It does
      not break HIDP itself, it already is!
      
      See later patches in this series which fix HIDP to use proper
      session-management.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      fc225c3f
  7. 12 4月, 2013 2 次提交
    • C
      Bluetooth: Fix SCO connection reference · ea323c11
      Claudio Takahasi 提交于
      This patch fixes decrementing SCO connection reference right after
      stablishing the SCO connection with defer setup enabled. The dump below
      shows a disconnection command with handle 0, the connection is still in
      BT_CONNECT2 state and there isn't a handle associated with it.
      
      < HCI Command: Accept Synchronous Connection (0x01|0x0029) plen 21
        bdaddr 78:47:1D:B3:72:6C
      > HCI Event: Command Status (0x0f) plen 4
        Accept Synchronous Connection (0x01|0x0029) status 0x00 ncmd 1
      < HCI Command: Disconnect (0x01|0x0006) plen 3
        handle 0 reason 0x13
        Reason: Remote User Terminated Connection
      > HCI Event: Command Status (0x0f) plen 4
        Disconnect (0x01|0x0006) status 0x00 ncmd 1
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
        status 0x00 handle 46 bdaddr 78:47:1D:B3:72:6C
        type eSCO
        Air mode: CVSD
      < SCO data: handle 46 flags 0x00 dlen 48
      Signed-off-by: NClaudio Takahasi <claudio.takahasi@openbossa.org>
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      ea323c11
    • D
      Bluetooth: rename hci_conn_put to hci_conn_drop · 76a68ba0
      David Herrmann 提交于
      We use _get() and _put() for device ref-counting in the kernel. However,
      hci_conn_put() is _not_ used for ref-counting, hence, rename it to
      hci_conn_drop() so we can later fix ref-counting and introduce
      hci_conn_put().
      
      hci_conn_hold() and hci_conn_put() are currently used to manage how long a
      connection should be held alive. When the last user drops the connection,
      we spawn a delayed work that performs the disconnect. Obviously, this has
      nothing to do with ref-counting for the _object_ but rather for the
      keep-alive of the connection.
      
      But we really _need_ proper ref-counting for the _object_ to allow
      connection-users like rfcomm-tty, HIDP or others.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      76a68ba0
  8. 05 4月, 2013 2 次提交
  9. 04 4月, 2013 2 次提交
    • A
      Bluetooth: Fix hci_inquiry ioctl usage · 3e13fa1e
      Andre Guedes 提交于
      Since the HCI request framework was properly fixed, the hci_req_sync
      call, in hci_inquiry, will return as soon as the HCI command completes
      (not the Inquiry procedure). However, in inquiry ioctl implementation,
      we want to sleep the user process until the inquiry procedure finishes.
      
      This patch changes hci_inquiry so, in case the HCI Inquiry command
      was executed successfully, it waits the HCI_INQUIRY flag to be cleared.
      This way, the user process will sleep until the inquiry procedure
      finishes.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      3e13fa1e
    • A
      Bluetooth: Fix HCI request framework · 33720450
      Andre Guedes 提交于
      Some HCI commands don't send a Command Complete Event once the HCI
      command has completed so they require some special handling from the
      HCI request framework. These HCI commands, however, send a Command
      Status Event to indicate that the command has been received, and
      that the controller is currently performing the task for the command.
      
      So, in order to properly handle those HCI commands, the HCI request
      framework should consider the HCI command has completed once the
      Command Status Event is received.
      
      This way, we fix some issues regarding the Inquiry command support,
      as well as add support for all those HCI commands which would require
      some special handling from the HCI request framework.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      33720450
  10. 19 3月, 2013 5 次提交
  11. 10 3月, 2013 1 次提交
  12. 08 3月, 2013 5 次提交
  13. 02 2月, 2013 1 次提交
  14. 23 1月, 2013 3 次提交
  15. 10 1月, 2013 1 次提交
    • S
      Bluetooth: Fix sending HCI commands after reset · dbccd791
      Szymon Janc 提交于
      After sending reset command wait for its command complete event before
      sending next command. Some chips sends CC event for command received
      before reset if reset was send before chip replied with CC.
      
      This is also required by specification that host shall not send
      additional HCI commands before receiving CC for reset.
      
      < HCI Command: Reset (0x03|0x0003) plen 0                              [hci0] 18.404612
      > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.405850
            Write Extended Inquiry Response (0x03|0x0052) ncmd 1
              Status: Success (0x00)
      < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.406079
      > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.407864
            Reset (0x03|0x0003) ncmd 1
              Status: Success (0x00)
      < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.408062
      > HCI Event: Command Complete (0x0e) plen 12                           [hci0] 18.408835
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Cc: stable@vger.kernel.org
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      dbccd791
  16. 04 12月, 2012 1 次提交