26 Oct, 2014

4 commits


25 Oct, 2014

9 commits

  • In the error case where credits is greater than max_credits there
    is a missing l2cap_chan_unlock before returning.

    Signed-off-by: Martin Townsend
    Tested-by: Jukka Rissanen
    Signed-off-by: Marcel Holtmann

    Martin Townsend
     
  • Currently there are potentially 2 skb_copy_expand calls in IPHC
    decompression. This patch replaces this with one call to
    skb_cow which will check to see if there is enough headroom
    first to ensure it's only done if necessary and will handle
    alignment issues for cache.
    As skb_cow uses pskb_expand_head we ensure the skb isn't shared from
    bluetooth and ieee802.15.4 code that use the IPHC decompression.

    Signed-off-by: Martin Townsend
    Acked-by: Alexander Aring
    Acked-by: Jukka Rissanen
    Signed-off-by: Marcel Holtmann

    Martin Townsend
     
  • netif_rx() only returns NET_RX_DROP and NET_RX_SUCCESS, not returns
    negative value

    Signed-off-by: Li RongQing
    Acked-by: Jukka Rissanen
    Signed-off-by: Marcel Holtmann

    Li RongQing
     
  • Value returned by this macro might be used as bit value so it should
    return either 0 or 1 to avoid possible bugs (similar to NSC bug)
    when shifting it.

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

    Szymon Janc
     
  • rfcomm_send_nsc expects CR to be either 0 or 1 since it is later
    passed to __mcc_type macro and shitfed. Unfortunatelly CR extracted
    from received frame type was not sanitized and shifted value was passed
    resulting in bogus response.

    Note: shifted value was also passed to other functions but was used
    only in if satements so this bug appears only for NSC case.

    The CR bit in the value octet shall be set to the same value
    as the CR bit in the type field octet of the not supported command
    frame but the CR bit for NCS response should be set to 0 since it is
    always a response.

    This was affecting TC_RFC_BV_25_C PTS qualification test.

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

    Szymon Janc
     
  • Systematically removing the LE connection parameters and autoconnect
    action is inconvenient for rebonding without disconnecting from
    userland (i.e. unpairing followed by repairing without
    disconnecting). The parameters will be lost after unparing and
    userland needs to take care of book-keeping them and re-adding them.

    This patch allows userland to forget about parameter management when
    rebonding without disconnecting. It defers clearing the connection
    parameters when unparing without disconnecting, giving a chance of
    keeping the parameters if a repairing happens before the connection is
    closed.

    Signed-off-by: Alfonso Acosta
    Acked-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Alfonso Acosta
     
  • NULL-checking conn->dev_class is pointless since the variable is
    defined as an array, i.e. it will always be non-NULL.

    Signed-off-by: Alfonso Acosta
    Signed-off-by: Johan Hedberg

    Alfonso Acosta
     
  • There are scenarios when autoconnecting to a device after the
    reception of an ADV_IND report (action 0x02), in which userland
    might want to examine the report's contents.

    For instance, the Service Data might have changed and it would be
    useful to know ahead of time before starting any GATT procedures.
    Also, the ADV_IND may contain Manufacturer Specific data which would
    be lost if not propagated to userland. In fact, this patch results
    from the need to rebond with a device lacking persistent storage which
    notifies about losing its LTK in ADV_IND reports.

    This patch appends the ADV_IND report which triggered the
    autoconnection to the EIR Data in the Device Connected event.

    Signed-off-by: Alfonso Acosta
    Signed-off-by: Johan Hedberg

    Alfonso Acosta
     
  • The values of a lot of the mgmt_device_connected() parameters come
    straight from a hci_conn object. We can simplify the function by passing
    the full hci_conn pointer to it.

    Signed-off-by: Alfonso Acosta
    Signed-off-by: Johan Hedberg

    Alfonso Acosta
     

02 Oct, 2014

5 commits

  • We did not return error if multicast packet transmit failed.
    This might not be desired so return error also in this case.
    If there are multiple 6lowpan devices where the multicast packet
    is sent, then return error even if sending to only one of them fails.

    Signed-off-by: Jukka Rissanen
    Signed-off-by: Johan Hedberg

    Jukka Rissanen
     
  • Make sure that we are able to return EAGAIN from l2cap_chan_send()
    even for multicast packets. The error code was ignored unncessarily.

    Signed-off-by: Jukka Rissanen
    Signed-off-by: Johan Hedberg

    Jukka Rissanen
     
  • If skb_unshare() returns NULL, then we leak the original skb.
    Solution is to use temp variable to hold the new skb.

    Signed-off-by: Jukka Rissanen
    Signed-off-by: Johan Hedberg

    Jukka Rissanen
     
  • The earlier multicast commit 36b3dd250dde ("Bluetooth: 6lowpan:
    Ensure header compression does not corrupt IPv6 header") lost one
    skb free which then caused memory leak.

    Signed-off-by: Jukka Rissanen
    Signed-off-by: Johan Hedberg

    Jukka Rissanen
     
  • The L2CAP connection's channel list lock (conn->chan_lock) must never be
    taken while already holding a channel lock (chan->lock) in order to
    avoid lock-inversion and lockdep warnings. So far the l2cap_chan_connect
    function has acquired the chan->lock early in the function and then
    later called l2cap_chan_add(conn, chan) which will try to take the
    conn->chan_lock. This violates the correct order of taking the locks and
    may lead to the following type of lockdep warnings:

    -> #1 (&conn->chan_lock){+.+...}:
    [] lock_acquire+0x9d/0x140
    [] mutex_lock_nested+0x6c/0x420
    [] l2cap_chan_add+0x1e/0x40 [bluetooth]
    [] l2cap_chan_connect+0x348/0x8f0 [bluetooth]
    [] lowpan_control_write+0x221/0x2d0 [bluetooth_6lowpan]
    -> #0 (&chan->lock){+.+.+.}:
    [] __lock_acquire+0x1a18/0x1d20
    [] lock_acquire+0x9d/0x140
    [] mutex_lock_nested+0x6c/0x420
    [] l2cap_connect_cfm+0x1dd/0x3f0 [bluetooth]
    [] hci_le_meta_evt+0x11a4/0x1260 [bluetooth]
    [] hci_event_packet+0x3ab/0x3120 [bluetooth]
    [] hci_rx_work+0x208/0x4a0 [bluetooth]

    CPU0 CPU1
    ---- ----
    lock(&conn->chan_lock);
    lock(&chan->lock);
    lock(&conn->chan_lock);
    lock(&chan->lock);

    Before calling l2cap_chan_add() the channel is not part of the
    conn->chan_l list, and can therefore only be accessed by the L2CAP user
    (such as l2cap_sock.c). We can therefore assume that it is the
    responsibility of the user to handle mutual exclusion until this point
    (which we can see is already true in l2cap_sock.c by it in many places
    touching chan members without holding chan->lock).

    Since the hci_conn and by exctension l2cap_conn creation in the
    l2cap_chan_connect() function depend on chan details we cannot simply
    add a mutex_lock(&conn->chan_lock) in the beginning of the function
    (since the conn object doesn't yet exist there). What we can do however
    is move the chan->lock taking later into the function where we already
    have the conn object and can that way take conn->chan_lock first.

    This patch implements the above strategy and does some other necessary
    changes such as using __l2cap_chan_add() which assumes conn->chan_lock
    is held, as well as adding a second needed label so the unlocking
    happens as it should.

    Reported-by: Jukka Rissanen
    Signed-off-by: Johan Hedberg
    Tested-by: Jukka Rissanen
    Acked-by: Jukka Rissanen
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

29 Sep, 2014

3 commits


25 Sep, 2014

2 commits


24 Sep, 2014

2 commits

  • The core specification defines valid values for the
    HCI_Reject_Synchronous_Connection_Request command to be 0x0D-0x0F. So
    far the code has been using HCI_ERROR_REMOTE_USER_TERM (0x13) which is
    not a valid value and is therefore being rejected by some controllers:

    > HCI Event: Connect Request (0x04) plen 10
    bdaddr 40:6F:2A:6A:E5:E0 class 0x000000 type eSCO
    < HCI Command: Reject Synchronous Connection (0x01|0x002a) plen 7
    bdaddr 40:6F:2A:6A:E5:E0 reason 0x13
    Reason: Remote User Terminated Connection
    > HCI Event: Command Status (0x0f) plen 4
    Reject Synchronous Connection (0x01|0x002a) status 0x12 ncmd 1
    Error: Invalid HCI Command Parameters

    This patch introduces a new define for a value from the valid range
    (0x0d == Connection Rejected Due To Limited Resources) and uses it
    instead for rejecting incoming connections.

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

    Johan Hedberg
     
  • No caller or macro uses the return value so make all
    the functions return void.

    Signed-off-by: Joe Perches
    Signed-off-by: Marcel Holtmann

    Joe Perches
     

23 Sep, 2014

1 commit

  • SCO connection cannot be setup to devices that do not support retransmission.
    Patch based on http://permalink.gmane.org/gmane.linux.bluez.kernel/7779 and
    adapted for this kernel version.

    Code changed to check SCO/eSCO type before setting retransmission effort
    and max. latency. The purpose of the patch is to support older devices not
    capable of eSCO.

    Tested on Blackberry 655+ headset which does not support retransmission.
    Credits go to Alexander Sommerhuber.

    Signed-off-by: Bernhard Thaler
    Signed-off-by: Marcel Holtmann

    Bernhard Thaler
     

18 Sep, 2014

1 commit

  • We can only determine the final security level when both pairing request
    and response have been exchanged. When initiating pairing the starting
    target security level is set to MEDIUM unless explicitly specified to be
    HIGH, so that we can still perform pairing even if the remote doesn't
    have MITM capabilities. However, once we've received the pairing
    response we should re-consult the remote and local IO capabilities and
    upgrade the target security level if necessary.

    Without this patch the resulting Long Term Key will occasionally be
    reported to be unauthenticated when it in reality is an authenticated
    one.

    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Johan Hedberg
     

17 Sep, 2014

1 commit


15 Sep, 2014

2 commits

  • The Bluetooth core already does processing of the HCI command header
    and puts it together before sending it to the driver. It is not really
    efficient for the driver to look at the HCI command header again in
    case it has to make certain decisions about certain commands. To make
    this easier, just provide the opcode as part of the SKB control buffer
    information. The extra information about the opcode is optional and
    only provided for HCI commands.

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

    Marcel Holtmann
     
  • The struct bt_skb_cb size needs to stay within the limits of skb->cb
    at all times and to ensure that add a BUILD_BUG_ON to check for it at
    compile time.

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

    Marcel Holtmann
     

13 Sep, 2014

1 commit

  • The hci_update_random_address will clear the RPA_EXPIRED flag and
    proceed with setting a new one if the flag was set. However, the
    set_random_addr() function that is called may choose to defer the update
    to a later moment. In such a case the flag would incorrectly remain
    unset unless set_random_addr() re-sets it. This patch fixes the issue.

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

    Johan Hedberg
     

11 Sep, 2014

8 commits

  • If encryption fails and we're using an RPA it may be because of a
    conflict with another device. To avoid repeated failures the safest
    action is to simply mark the RPA as expired so that a new one gets
    generated as soon as the connection drops.

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

    Johan Hedberg
     
  • This is a trivial change to use a proper define for the NoInputNoOutput
    IO capability instead of hard-coded values.

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

    Johan Hedberg
     
  • Even if we have no connection-oriented channels we should perform the
    L2CAP Information Request procedures before notifying L2CAP channels of
    the connection. This is so that the L2CAP channel implementations can
    perform checks on what the remote side supports (e.g. does it support
    the fixed channel in question).

    So far the code has relied on the l2cap_do_start() function to initiate
    the Information Request, however l2cap_do_start() is used on a
    per-channel basis and only for connection-oriented channels. This means
    that if there are no connection-oriented channels on the system we would
    never start the Information Request procedure.

    This patch creates a new l2cap_request_info() helper function to
    initiate the Information Request procedure, and ensures that it is
    called whenever a BR/EDR connection has been established. The patch also
    updates fixed channels to be notified of connection readiness only once
    the Information Request procedure has completed.

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

    Johan Hedberg
     
  • There are several places that need to determine the security level that
    an LTK can provide. This patch adds a convenience function for this to
    help make the code more readable.

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

    Johan Hedberg
     
  • When the local IO capability is NoInputNoOutput any attempt to convert
    the remote authentication requirement to a target security level is
    futile. This patch makes sure that we set the target security level at
    most to MEDIUM if the local IO capability is NoInputNoOutput.

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

    Johan Hedberg
     
  • All the cases where we mark SMP commands as dissalowed are their
    respective command handlers. We can therefore simplify the code by
    always clearing the bit immediately after testing it. This patch
    converts the corresponding test_bit() call to a test_and_clear_bit()
    call and also removes the now unused SMP_DISALLOW_CMD macro.

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

    Johan Hedberg
     
  • The SMP specification states that we should ignore any unknown bits from
    the authentication requirement. We already have a define for masking out
    unknown bits but we haven't used it in all places so far. This patch
    adds usage of the AUTH_REQ_MASK to all places that need it and ensures
    that we don't pass unknown bits onward to other functions.

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

    Johan Hedberg
     
  • We do nothing else with the auth variable in smp_cmd_pairing_rsp()
    besides passing it to tk_request() which in turn only cares about
    whether one of the sides had the MITM bit set. It is therefore
    unnecessary to assign a value to it until just before calling
    tk_request(), and this value can simply be the bit-wise or of the local
    and remote requirements.

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

    Johan Hedberg
     

10 Sep, 2014

1 commit

  • If the remote side is not distributing its IRK but is distributing the
    CSRK the next PDU after master identification is the Signing
    Information. This patch fixes a missing SMP_ALLOW_CMD() for this in the
    smp_cmd_master_ident() function.

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

    Johan Hedberg