19 Apr, 2018

1 commit

  • commit 082f2300cfa1a3d9d5221c38c5eba85d4ab98bd8 upstream.

    Local random address needs to be updated before creating connection if
    RPA from LE Direct Advertising Report was resolved in host. Otherwise
    remote device might ignore connection request due to address mismatch.

    This was affecting following qualification test cases:
    GAP/CONN/SCEP/BV-03-C, GAP/CONN/GCEP/BV-05-C, GAP/CONN/DCEP/BV-05-C

    Before patch:
    < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #11350 [hci0] 84680.231216
    Address: 56:BC:E8:24:11:68 (Resolvable)
    Identity type: Random (0x01)
    Identity: F2:F1:06:3D:9C:42 (Static)
    > HCI Event: Command Complete (0x0e) plen 4 #11351 [hci0] 84680.246022
    LE Set Random Address (0x08|0x0005) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #11352 [hci0] 84680.246417
    Type: Passive (0x00)
    Interval: 60.000 msec (0x0060)
    Window: 30.000 msec (0x0030)
    Own address type: Random (0x01)
    Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
    > HCI Event: Command Complete (0x0e) plen 4 #11353 [hci0] 84680.248854
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11354 [hci0] 84680.249466
    Scanning: Enabled (0x01)
    Filter duplicates: Enabled (0x01)
    > HCI Event: Command Complete (0x0e) plen 4 #11355 [hci0] 84680.253222
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 18 #11356 [hci0] 84680.458387
    LE Direct Advertising Report (0x0b)
    Num reports: 1
    Event type: Connectable directed - ADV_DIRECT_IND (0x01)
    Address type: Random (0x01)
    Address: 53:38:DA:46:8C:45 (Resolvable)
    Identity type: Public (0x00)
    Identity: 11:22:33:44:55:66 (OUI 11-22-33)
    Direct address type: Random (0x01)
    Direct address: 7C:D6:76:8C:DF:82 (Resolvable)
    Identity type: Random (0x01)
    Identity: F2:F1:06:3D:9C:42 (Static)
    RSSI: -74 dBm (0xb6)
    < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11357 [hci0] 84680.458737
    Scanning: Disabled (0x00)
    Filter duplicates: Disabled (0x00)
    > HCI Event: Command Complete (0x0e) plen 4 #11358 [hci0] 84680.469982
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Create Connection (0x08|0x000d) plen 25 #11359 [hci0] 84680.470444
    Scan interval: 60.000 msec (0x0060)
    Scan window: 60.000 msec (0x0060)
    Filter policy: White list is not used (0x00)
    Peer address type: Random (0x01)
    Peer address: 53:38:DA:46:8C:45 (Resolvable)
    Identity type: Public (0x00)
    Identity: 11:22:33:44:55:66 (OUI 11-22-33)
    Own address type: Random (0x01)
    Min connection interval: 30.00 msec (0x0018)
    Max connection interval: 50.00 msec (0x0028)
    Connection latency: 0 (0x0000)
    Supervision timeout: 420 msec (0x002a)
    Min connection length: 0.000 msec (0x0000)
    Max connection length: 0.000 msec (0x0000)
    > HCI Event: Command Status (0x0f) plen 4 #11360 [hci0] 84680.474971
    LE Create Connection (0x08|0x000d) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #11361 [hci0] 84682.545385
    > HCI Event: Command Complete (0x0e) plen 4 #11362 [hci0] 84682.551014
    LE Create Connection Cancel (0x08|0x000e) ncmd 1
    Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 19 #11363 [hci0] 84682.551074
    LE Connection Complete (0x01)
    Status: Unknown Connection Identifier (0x02)
    Handle: 0
    Role: Master (0x00)
    Peer address type: Public (0x00)
    Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
    Connection interval: 0.00 msec (0x0000)
    Connection latency: 0 (0x0000)
    Supervision timeout: 0 msec (0x0000)
    Master clock accuracy: 0x00

    After patch:
    < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #210 [hci0] 667.152459
    Type: Passive (0x00)
    Interval: 60.000 msec (0x0060)
    Window: 30.000 msec (0x0030)
    Own address type: Random (0x01)
    Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
    > HCI Event: Command Complete (0x0e) plen 4 #211 [hci0] 667.153613
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #212 [hci0] 667.153704
    Scanning: Enabled (0x01)
    Filter duplicates: Enabled (0x01)
    > HCI Event: Command Complete (0x0e) plen 4 #213 [hci0] 667.154584
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 18 #214 [hci0] 667.182619
    LE Direct Advertising Report (0x0b)
    Num reports: 1
    Event type: Connectable directed - ADV_DIRECT_IND (0x01)
    Address type: Random (0x01)
    Address: 50:52:D9:A6:48:A0 (Resolvable)
    Identity type: Public (0x00)
    Identity: 11:22:33:44:55:66 (OUI 11-22-33)
    Direct address type: Random (0x01)
    Direct address: 7C:C1:57:A5:B7:A8 (Resolvable)
    Identity type: Random (0x01)
    Identity: F4:28:73:5D:38:B0 (Static)
    RSSI: -70 dBm (0xba)
    < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #215 [hci0] 667.182704
    Scanning: Disabled (0x00)
    Filter duplicates: Disabled (0x00)
    > HCI Event: Command Complete (0x0e) plen 4 #216 [hci0] 667.183599
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #217 [hci0] 667.183645
    Address: 7C:C1:57:A5:B7:A8 (Resolvable)
    Identity type: Random (0x01)
    Identity: F4:28:73:5D:38:B0 (Static)
    > HCI Event: Command Complete (0x0e) plen 4 #218 [hci0] 667.184590
    LE Set Random Address (0x08|0x0005) ncmd 1
    Status: Success (0x00)
    < HCI Command: LE Create Connection (0x08|0x000d) plen 25 #219 [hci0] 667.184613
    Scan interval: 60.000 msec (0x0060)
    Scan window: 60.000 msec (0x0060)
    Filter policy: White list is not used (0x00)
    Peer address type: Random (0x01)
    Peer address: 50:52:D9:A6:48:A0 (Resolvable)
    Identity type: Public (0x00)
    Identity: 11:22:33:44:55:66 (OUI 11-22-33)
    Own address type: Random (0x01)
    Min connection interval: 30.00 msec (0x0018)
    Max connection interval: 50.00 msec (0x0028)
    Connection latency: 0 (0x0000)
    Supervision timeout: 420 msec (0x002a)
    Min connection length: 0.000 msec (0x0000)
    Max connection length: 0.000 msec (0x0000)
    > HCI Event: Command Status (0x0f) plen 4 #220 [hci0] 667.186558
    LE Create Connection (0x08|0x000d) ncmd 1
    Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 19 #221 [hci0] 667.485824
    LE Connection Complete (0x01)
    Status: Success (0x00)
    Handle: 0
    Role: Master (0x00)
    Peer address type: Random (0x01)
    Peer address: 50:52:D9:A6:48:A0 (Resolvable)
    Identity type: Public (0x00)
    Identity: 11:22:33:44:55:66 (OUI 11-22-33)
    Connection interval: 50.00 msec (0x0028)
    Connection latency: 0 (0x0000)
    Supervision timeout: 420 msec (0x002a)
    Master clock accuracy: 0x07
    @ MGMT Event: Device Connected (0x000b) plen 13 {0x0002} [hci0] 667.485996
    LE Address: 11:22:33:44:55:66 (OUI 11-22-33)
    Flags: 0x00000000
    Data length: 0

    Signed-off-by: Szymon Janc
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Szymon Janc
     

17 Feb, 2017

1 commit


13 Jul, 2016

1 commit

  • If link is disconnected due to Authentication Failure (PIN or Key
    Missing status) userspace will be notified about this with proper error
    code. Many LE profiles define "PIN or Key Missing" status as indication
    of remote lost bond so this allows userspace to take action on this.

    @ Device Connected: 88:63:DF:88:0E:83 (1) flags 0x0000
    02 01 1a 05 03 0a 18 0d 18 0b 09 48 65 61 72 74 ...........Heart
    20 52 61 74 65 Rate
    > HCI Event: Command Status (0x0f) plen 4
    LE Read Remote Used Features (0x08|0x0016) ncmd 1
    Status: Success (0x00)
    > ACL Data RX: Handle 3585 flags 0x02 dlen 11
    ATT: Read By Group Type Request (0x10) len 6
    Handle range: 0x0001-0xffff
    Attribute group type: Primary Service (0x2800)
    > HCI Event: LE Meta Event (0x3e) plen 12
    LE Read Remote Used Features (0x04)
    Status: Success (0x00)
    Handle: 3585
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    LE Encryption
    < HCI Command: LE Start Encryption (0x08|0x0019) plen 28
    Handle: 3585
    Random number: 0x0000000000000000
    Encrypted diversifier: 0x0000
    Long term key: 26201cd479a0921b6f949f0b1fa8dc82
    > HCI Event: Command Status (0x0f) plen 4
    LE Start Encryption (0x08|0x0019) ncmd 1
    Status: Success (0x00)
    > HCI Event: Encryption Change (0x08) plen 4
    Status: PIN or Key Missing (0x06)
    Handle: 3585
    Encryption: Disabled (0x00)
    < HCI Command: Disconnect (0x01|0x0006) plen 3
    Handle: 3585
    Reason: Authentication Failure (0x05)
    > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) ncmd 1
    Status: Success (0x00)
    > HCI Event: Disconnect Complete (0x05) plen 4
    Status: Success (0x00)
    Handle: 3585
    Reason: Connection Terminated By Local Host (0x16)
    @ Device Disconnected: 88:63:DF:88:0E:83 (1) reason 4

    @ Device Connected: C4:43:8F:A3:4D:83 (0) flags 0x0000
    08 09 4e 65 78 75 73 20 35 ..Nexus 5
    > HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) ncmd 1
    Status: Success (0x00)
    > HCI Event: Link Key Request (0x17) plen 6
    Address: C4:43:8F:A3:4D:83 (LG Electronics)
    < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
    Address: C4:43:8F:A3:4D:83 (LG Electronics)
    Link key: 080812e4aa97a863d11826f71f65a933
    > HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    Status: Success (0x00)
    Address: C4:43:8F:A3:4D:83 (LG Electronics)
    > HCI Event: Auth Complete (0x06) plen 3
    Status: PIN or Key Missing (0x06)
    Handle: 75
    @ Authentication Failed: C4:43:8F:A3:4D:83 (0) status 0x05
    < HCI Command: Disconnect (0x01|0x0006) plen 3
    Handle: 75
    Reason: Remote User Terminated Connection (0x13)
    > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) ncmd 1
    Status: Success (0x00)
    > HCI Event: Disconnect Complete (0x05) plen 4
    Status: Success (0x00)
    Handle: 75
    Reason: Connection Terminated By Local Host (0x16)
    @ Device Disconnected: C4:43:8F:A3:4D:83 (0) reason 4

    Signed-off-by: Szymon Janc
    Signed-off-by: Johan Hedberg

    Szymon Janc
     

10 Jul, 2016

1 commit

  • The HCI_BREDR naming is confusing since it actually stands for Primary
    Bluetooth Controller. Which is a term that has been used in the latest
    standard. However from a legacy point of view there only really have
    been Basic Rate (BR) and Enhanced Data Rate (EDR). Recent versions of
    Bluetooth introduced Low Energy (LE) and made this terminology a little
    bit confused since Dual Mode Controllers include BR/EDR and LE. To
    simplify this the name HCI_PRIMARY stands for the Primary Controller
    which can be a single mode or dual mode controller.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

09 Apr, 2016

1 commit


06 Jan, 2016

1 commit


10 Dec, 2015

2 commits

  • This paves the way for eventually performing advertising changes
    through the hdev->req_workqueue. Some new APIs need to be exposed from
    mgmt.c to hci_request.c and vice-versa, but many of them will go away
    once hdev->req_workqueue gets used.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • Since Add/Remove Device perform the page scan updates independently
    from the HCI command completion we've introduced a potential race when
    multiple mgmt commands are queued. Doing the page scan updates through
    the req_workqueue ensures that the state changes are performed in a
    race-free manner.

    At the same time, to make the request helper more widely usable,
    extend it to also cover Inquiry Scan changes since those are behind
    the same HCI command. This is also reflected in the new name of the
    API as well as the work struct name.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

26 Oct, 2015

1 commit

  • The SKB context buffer for HCI request is really not just for requests,
    information in their are preserved for the whole HCI layer. So it makes
    more sense to actually rename it into bt_cb()->hci and also call it then
    struct hci_ctrl.

    In addition that allows moving the decoded opcode for outgoing packets
    into that struct. So far it was just consuming valuable space from the
    main shared items. And opcode are not valid for L2CAP packets.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

22 Oct, 2015

1 commit


20 Oct, 2015

1 commit


16 Oct, 2015

2 commits

  • We can't use hci_explicit_connect_lookup() since that would only cover
    explicit connections, leaving normal reconnections completely
    untouched. Not using it in turn means leaving out entries in
    pend_le_reports.

    To fix this and simplify the logic move conn params from the reports
    list to the pend_le_conns list for the duration of an explicit
    connect. Once the connect is complete move the params back to the
    pend_le_reports list. This also means that the explicit connect lookup
    function only needs to look into the pend_le_conns list.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • When disable/enable scan command is issued twice, some controllers
    will return an error for the second request, i.e. requests with this
    command will fail on some controllers, and succeed on others.

    This patch makes sure that unnecessary scan disable/enable commands
    are not issued.

    When adding device to the auto connect whitelist when there is pending
    connect attempt, there is no need to update scan.

    hci_connect_le_scan_cleanup is conditionally executing
    hci_conn_params_del, that is calling hci_update_background_scan. Make
    the other case also update scan, and remove reduntand call from
    hci_connect_le_scan_remove.

    When stopping interleaved discovery the state should be set to stopped
    only when both LE scanning and discovery has stopped.

    Signed-off-by: Jakub Pawlowski
    Acked-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Jakub Pawlowski
     

18 Sep, 2015

1 commit

  • Some remote devices (ie Gigaset G-Tag) misbehave with ADV data length.
    This can lead to incorrect EIR format in device found event when
    ADV_DATA and SCAN_RSP are merged (terminator field before SCAN_RSP
    part).

    Fix this by inspecting ADV_DATA and correct its length if terminator
    is found.

    > HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 32.172182
    LE Advertising Report (0x02)
    Num reports: 1
    Event type: Connectable undirected - ADV_IND (0x00)
    Address type: Public (0x00)
    Address: 7C:2F:80:94:97:5A (Gigaset Communications GmbH)
    Data length: 30
    Flags: 0x06
    LE General Discoverable Mode
    BR/EDR Not Supported
    Company: Gigaset Communications GmbH (384)
    Data: 021512348094975abbc5
    16-bit Service UUIDs (partial): 1 entry
    Battery Service (0x180f)
    RSSI: -65 dBm (0xbf)
    > HCI Event: LE Meta Event (0x3e) plen 27 [hci0] 32.172191
    LE Advertising Report (0x02)
    Num reports: 1
    Event type: Scan response - SCAN_RSP (0x04)
    Address type: Public (0x00)
    Address: 7C:2F:80:94:97:5A (Gigaset Communications GmbH)
    Data length: 15
    Name (complete): Gigaset G-tag
    RSSI: -59 dBm (0xc5)

    Note "Data length: 30" in ADV_DATA which results in 9 extra zero bytes
    after Battery Service UUID. Terminator field present in the middle of
    EIR in Device Found event resulted in userspace stop parsing EIR and
    skipping device name.

    @ Device Found: 7C:2F:80:94:97:5A (1) rssi -59 flags 0x0000
    02 01 06 0d ff 80 01 02 15 12 34 80 94 97 5a bb ..........4...Z.
    c5 03 02 0f 18 00 00 00 00 00 00 00 00 00 0e 09 ................
    47 69 67 61 73 65 74 20 47 2d 74 61 67 Gigaset G-tag

    With this fix EIR with merged ADV_DATA and SCAN_RSP in device found
    event is properly formatted:

    @ Device Found: 7C:2F:80:94:97:5A (1) rssi -59 flags 0x0000
    02 01 06 0d ff 80 01 02 15 12 34 80 94 97 5a bb ..........4...Z.
    c5 03 02 0f 18 0e 09 47 69 67 61 73 65 74 20 47 .......Gigaset G
    2d 74 61 67 -tag

    Signed-off-by: Szymon Janc
    Signed-off-by: Marcel Holtmann

    Szymon Janc
     

29 Aug, 2015

1 commit

  • Synchronous connections are initially created with type eSCO.
    Link manager may reject proposed link parameters, which triggers
    connection setup retry with a different set. Link type embedded
    in responses should be disregarded until Synchronous Connect Complete
    returns Success (0x00). Current code updates link type every time
    which creates an issue when link type changes to SCO and back to eSCO
    on further attepts.

    Issue happens with BlackBerry 9100 and 9700 with Intel WilkinsPeak
    on third connection setup attept

    2015-05-18 01:27:57.332242 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    handle 256 voice setting 0x0060 ptype 0x0380
    2015-05-18 01:27:57.333604 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
    2015-05-18 01:27:57.334614 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    status 0x1a handle 0 bdaddr 30:7C:30:B3:A8:86 type SCO
    Error: Unsupported Remote Feature / Unsupported LMP Feature
    2015-05-18 01:27:57.334895 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    handle 256 voice setting 0x0060 ptype 0x0380
    2015-05-18 01:27:57.335601 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
    2015-05-18 01:27:57.336610 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    status 0x1a handle 0 bdaddr 30:7C:30:B3:A8:86 type SCO
    Error: Unsupported Remote Feature / Unsupported LMP Feature
    2015-05-18 01:27:57.336685 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    handle 256 voice setting 0x0060 ptype 0x03c8
    2015-05-18 01:27:57.337603 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
    2015-05-18 01:27:57.342608 > HCI Event: Max Slots Change (0x1b) plen 3
    handle 256 slots 1
    2015-05-18 01:27:57.377631 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    status 0x00 handle 257 bdaddr 30:7C:30:B3:A8:86 type eSCO
    Air mode: CVSD

    Signed-off-by: Kuba Pawlak
    Signed-off-by: Marcel Holtmann

    Kuba Pawlak
     

11 Aug, 2015

2 commits

  • Currently, when trying to connect to already paired device that just
    rotated its RPA MAC address, old address would be used and connection
    would fail. In order to fix that, kernel must scan and receive
    advertisement with fresh RPA before connecting.

    This path makes sure that after advertisement is received from device that
    we try to connect to, it is properly handled in check_pending_le_conn and
    trigger connect attempt.

    It also modifies hci_le_connect to make sure that connect attempt will be
    properly continued.

    Signed-off-by: Jakub Pawlowski
    Signed-off-by: Marcel Holtmann

    Jakub Pawlowski
     
  • This patch adds hci_lookup_le_connect method, that will be used to check
    wether outgoing le connection attempt is in progress.

    Signed-off-by: Jakub Pawlowski
    Signed-off-by: Marcel Holtmann

    Jakub Pawlowski
     

30 Jul, 2015

4 commits


12 Jun, 2015

3 commits


09 Jun, 2015

1 commit

  • The encryption key size for LTKs is supposed to be applied only at the
    moment of encryption. When generating a Link Key (using LE SC) from
    the LTK the full non-shortened value should be used. This patch
    modifies the code to always keep the full value around and only apply
    the key size when passing the value to HCI.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

09 Apr, 2015

1 commit

  • When establishing a Bluetooth LE connection, read the remote used
    features mask to determine which features are supported. This was
    not really needed with Bluetooth 4.0, but since Bluetooth 4.1 and
    also 4.2 have introduced new optional features, this becomes more
    important.

    This works the same as with BR/EDR where the connection enters the
    BT_CONFIG stage and hci_connect_cfm call is delayed until the remote
    features have been retrieved. Only after successfully receiving the
    remote features, the connection enters the BT_CONNECTED state.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

02 Apr, 2015

5 commits

  • Now that there's a HCI request API available where the callback receives
    the resulting skb, we can convert the local OOB data reading to use this
    new API. This patch does the necessary update in mgmt.c (which also
    requires moving the callback higher up since it's now a static function)
    and removes the custom calls from hci_event.c that are no-longer
    necessary.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • To make the hci_req_run_skb() API consistent with hci_cmd_sync_ev()
    the callback should receive the cmd_complete parameters in the 'normal'
    case and the full HCI event if a special event was expected. This patch
    moves the hci_get_cmd_complete() function from hci_core.c to hci_event.c
    where it's used to strip the skb from the needed headers before passing
    it on to the callback.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • Now that the synchronous HCI requests use the new API and a new private
    variable the recv_evt member of hci_dev is no-longer needed. This patch
    removes it.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • This patch adds a second possible callback for HCI requests where the
    callback will receive the full skb of the last successfully completed
    HCI command. This API is useful for cases where we want to use a request
    to read some data and the existing hci_event.c handlers do not store it
    e.g. in the hci_dev struct.

    The reason the patch is a bit bigger than just adding the new API is
    because the hci_req_cmd_complete() functions required some refactoring
    to enable it: now hci_req_cmd_complete() is simply used to request the
    callback pointers if any, and the actual calling of them happens from a
    single place at the end of hci_event_packet(). The reason for this is
    that we need to pass the original skb (without any skb_pull, etc
    modifications done to it) and it's simplest to keep track of it within
    the hci_event_packet() function.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     
  • When dealing with HCI command status events, the reasoning for trying to
    mark a request as complete if no specific event is being waited for and
    status was success is not self-evident. This patch adds a clarifying
    comment above the if-statement.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

31 Mar, 2015

1 commit

  • In order to shrink the size of bt_skb_cb, this patch moves the HCI
    request related variables into their own req_ctrl struct. Additionall
    the L2CAP and HCI request structs are placed inside the same union since
    they will never be used at the same time for the same skb.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

29 Mar, 2015

2 commits

  • Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • During the HCI init phase a completed request might be the last part of
    the setup procedure after which the actual init procedure starts. The
    init procedure begins with a call to hci_reset_req() which sets the
    HCI_RESET flag. The purpose of this flag is to make us ignore any
    updates to ncmd/cmd_cnt as long as we haven't received the command
    complete event for the HCI_Reset. There's a potential race with this
    however:

    hci_req_cmd_complete(hdev, opcode, status);

    if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
    atomic_set(&hdev->cmd_cnt, 1);
    if (!skb_queue_empty(&hdev->cmd_q))
    queue_work(hdev->workqueue, &hdev->cmd_work);
    }

    Since the hci_req_cmd_complete() will trigger the completion of the
    setup stage, it's possible that hci_reset_req() gets called before we
    try to read ev->ncmd and the HCI_RESET flag. Because of this the cmd_cnt
    would never be updated and the hci_reset_req() in practice ends up
    blocking itself.

    This patch fixes the issue by updating cmd_cnt before notifying the
    request completion, and then reading it again to determine whether the
    cmd_work should be queued or not.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

18 Mar, 2015

1 commit

  • When doing scan through mgmt api, some controllers can do both le and
    classic scan at same time. They can be distinguished by
    HCI_QUIRK_SIMULTANEOUS_DISCOVERY set.

    This patch enables them to use this feature when doing dual mode scan.
    Instead of doing le, then classic scan, both scans are run at once.

    Signed-off-by: Jakub Pawlowski
    Signed-off-by: Johan Hedberg

    Jakub Pawlowski
     

16 Mar, 2015

2 commits

  • The HCI_CONN_REMOTE_OOB connection flag is used to indicate if the
    pairing initiator has provided out-of-band data. However since that
    value is no longer used in any decision making, just remove it.

    It is actually unclear what purpose the OOB data present field from
    the HCI IO Capability Response event serves in the first place. If
    either side provided out-of-band data, then that data will be used
    for pairing.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • When only the pairing initiator is providing out-of-band data, then
    the receiver side was ignoring the data. For some reason the code was
    checking if the initiator has received out-of-band data and only then
    also provide the required inidication that the acceptor actually has
    the needed data available.

    For BR/EDR out-of-band pairing it is enough if one side has received
    out-of-band data. There are no extra checks needed here to make this
    work smoothly. The only thing that is needed is to tell the controller
    if data is present (and if it is P-192 or P-256 or both) and then let
    the controller actually figure out the rest.

    This means the check for outgoing connection or if the initiator has
    indicated data are completely pointless and are in fact actually
    causing harm. The check in question is this one:

    if (conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)) {

    After just taking the conditional check out and always executing the
    code for determining the type of out-of-band data, the pairing works
    flawlessly and prodcudes authenticated link keys.

    The patch itself looks more complicated due to the reformatting of the
    indentation, but it essentially just a two-line change.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

14 Mar, 2015

1 commit


13 Mar, 2015

2 commits