1. 28 2月, 2014 12 次提交
  2. 27 2月, 2014 20 次提交
    • A
      Bluetooth: Update background scan parameters · dd2ef8e2
      Andre Guedes 提交于
      If new scanning parameters are set while background scan is running,
      we should restart background scanning so these parameters are updated.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      dd2ef8e2
    • A
      Bluetooth: Create hci_req_add_le_passive_scan helper · 8ef30fd3
      Andre Guedes 提交于
      This patches creates the public hci_req_add_le_passive_scan helper so
      it can be re-used outside hci_core.c in the next patch.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8ef30fd3
    • A
      Bluetooth: Add le_auto_conn file on debugfs · 7d474e06
      Andre Guedes 提交于
      This patch adds to debugfs the le_auto_conn file. This file will be
      used to test LE auto connection infrastructure.
      
      This file accept writes in the following format:
        "add <address> <address_type> [auto_connect]"
        "del <address> <address_type>"
        "clr"
      
      The <address type> values are:
        * 0 for public address
        * 1 for random address
      
      The [auto_connect] values are (for more details see struct hci_
      conn_params):
        * 0 for disabled (default)
        * 1 for always
        * 2 for link loss
      
      So for instance, if you want the kernel autonomously establishes
      connections with device AA:BB:CC:DD:EE:FF (public address) every
      time the device enters in connectable mode (starts advertising),
      you should run the command:
      $ echo "add AA:BB:CC:DD:EE:FF 0 1" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn
      
      To delete the connection parameters for that device, run the command:
      $ echo "del AA:BB:CC:DD:EE:FF 0" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn
      
      To clear the connection parameters list, run the command:
      $ echo "clr" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn
      
      Finally. to get the list of connection parameters configured in kernel,
      read the le_auto_conn file:
      $ cat /sys/kernel/debug/bluetooth/hci0/le_auto_conn
      
      This file is created only if LE is enabled.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7d474e06
    • A
      Bluetooth: Support resolvable private addresses · 5b906a84
      Andre Guedes 提交于
      Only identity addresses are inserted into hdev->pend_le_conns. So,
      in order to support resolvable private addresses in auto connection
      mechanism, we should resolve the address before checking for pending
      connections.
      
      Thus, this patch adds an extra check in check_pending_le_conn() and
      updates 'addr' and 'addr_type' variables before hci_pend_le_conn_
      lookup().
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      5b906a84
    • A
      Bluetooth: Connection parameters and resolvable address · a9b0a04c
      Andre Guedes 提交于
      We should only accept connection parameters from identity addresses
      (public or random static). Thus, we should check the address type
      in hci_conn_params_add().
      
      Additionally, since the IRK is removed during unpair, we should also
      remove the connection parameters from that device.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a9b0a04c
    • A
      Bluetooth: Auto connection and power on · 6046dc3e
      Andre Guedes 提交于
      When hdev is closed (e.g. Mgmt power off command, RFKILL or controller
      is reset), the ongoing active connections are silently dropped by the
      controller (no Disconnection Complete Event is sent to host). For that
      reason, the devices that require HCI_AUTO_CONN_ALWAYS are not added to
      hdev->pend_le_conns list and they won't auto connect.
      
      So to fix this issue, during hdev closing, we remove all pending LE
      connections. After adapter is powered on, we add a pending LE connection
      for each HCI_AUTO_CONN_ALWAYS address.
      
      This way, the auto connection mechanism works propely after a power
      off and power on sequence as well as RFKILL block/unblock.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6046dc3e
    • A
      Bluetooth: Temporarily stop background scanning on discovery · c54c3860
      Andre Guedes 提交于
      If the user sends a mgmt start discovery command while the background
      scanning is running, we should temporarily stop it. Once the discovery
      finishes, we start the background scanning again.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c54c3860
    • A
      Bluetooth: Connection parameters and auto connection · cef952ce
      Andre Guedes 提交于
      This patch modifies hci_conn_params_add() and hci_conn_params_del() so
      they also add/delete pending LE connections according to the auto_
      connect option. This way, background scan is automatically triggered/
      untriggered when connection parameters are added/removed.
      
      For instance, when a new connection parameters with HCI_AUTO_CONN_ALWAYS
      option is added and we are not connected to the device, we add a pending
      LE connection for that device.
      
      Likewise, when the connection parameters are updated we add or delete
      a pending LE connection according to its new auto_connect option.
      
      Finally, when the connection parameter is deleted we also delete the
      pending LE connection (if any).
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cef952ce
    • A
      Bluetooth: Introduce LE auto connect options · 9fcb18ef
      Andre Guedes 提交于
      This patch introduces the LE auto connection options: HCI_AUTO_CONN_
      ALWAYS and HCI_AUTO_CONN_LINK_LOSS. Their working mechanism are
      described as follows:
      
      The HCI_AUTO_CONN_ALWAYS option configures the kernel to always re-
      establish the connection, no matter the reason the connection was
      terminated. This feature is required by some LE profiles such as
      HID over GATT, Health Thermometer and Blood Pressure. These profiles
      require the host autonomously connect to the device as soon as it
      enters in connectable mode (start advertising) so the device is able
      to delivery notifications or indications.
      
      The BT_AUTO_CONN_LINK_LOSS option configures the kernel to re-
      establish the connection in case the connection was terminated due
      to a link loss. This feature is required by the majority of LE
      profiles such as Proximity, Find Me, Cycling Speed and Cadence and
      Time.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9fcb18ef
    • A
      Bluetooth: Introduce LE auto connection infrastructure · a4790dbd
      Andre Guedes 提交于
      This patch introduces the LE auto connection infrastructure which
      will be used to implement the LE auto connection options.
      
      In summary, the auto connection mechanism works as follows: Once the
      first pending LE connection is created, the background scanning is
      started. When the target device is found in range, the kernel
      autonomously starts the connection attempt. If connection is
      established successfully, that pending LE connection is deleted and
      the background is stopped.
      
      To achieve that, this patch introduces the hci_update_background_scan()
      which controls the background scanning state. This function starts or
      stops the background scanning based on the hdev->pend_le_conns list. If
      there is no pending LE connection, the background scanning is stopped.
      Otherwise, we start the background scanning.
      
      Then, every time a pending LE connection is added we call hci_update_
      background_scan() so the background scanning is started (in case it is
      not already running). Likewise, every time a pending LE connection is
      deleted we call hci_update_background_scan() so the background scanning
      is stopped (in case this was the last pending LE connection) or it is
      started again (in case we have more pending LE connections). Finally,
      we also call hci_update_background_scan() in hci_le_conn_failed() so
      the background scan is restarted in case the connection establishment
      fails. This way the background scanning keeps running until all pending
      LE connection are established.
      
      At this point, resolvable addresses are not support by this
      infrastructure. The proper support is added in upcoming patches.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a4790dbd
    • A
      Bluetooth: Introduce hdev->pend_le_conn list · 77a77a30
      Andre Guedes 提交于
      This patch introduces the hdev->pend_le_conn list which holds the
      device addresses the kernel should autonomously connect. It also
      introduces some helper functions to manipulate the list.
      
      The list and helper functions will be used by the next patch which
      implements the LE auto connection infrastructure.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77a77a30
    • A
      Bluetooth: Move address type conversion to outside hci_connect_le · 6f77d8c7
      Andre Guedes 提交于
      This patch moves address type conversion (L2CAP address type to HCI
      address type) to outside hci_connect_le. This way, we avoid back and
      forth address type conversion in a comming patch.
      
      So hci_connect_le() now expects 'dst_type' parameter in HCI address
      type convention.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6f77d8c7
    • A
      Bluetooth: Refactor HCI connection code · 04a6c589
      Andre Guedes 提交于
      hci_connect() is a very simple and useless wrapper of hci_connect_acl
      and hci_connect_le functions. Addtionally, all places where hci_connect
      is called the link type value is passed explicitly. This way, we can
      safely delete hci_connect, declare hci_connect_acl and hci_connect_le
      in hci_core.h and call them directly.
      
      No functionality is changed by this patch.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      04a6c589
    • A
      Bluetooth: Remove unused function · c99ed834
      Andre Guedes 提交于
      This patch removes hci_create_le_conn() since it is not used anymore.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c99ed834
    • A
      Bluetooth: Stop scanning on LE connection · 2acf3d90
      Andre Guedes 提交于
      Some LE controllers don't support scanning and creating a connection
      at the same time. So we should always stop scanning in order to
      establish the connection.
      
      Since we may prematurely stop the discovery procedure in favor of
      the connection establishment, we should also cancel hdev->le_scan_
      disable delayed work and set the discovery state to DISCOVERY_STOPPED.
      
      This change does a small improvement since it is not mandatory the
      user stops scanning before connecting anymore. Moreover, this change
      is required by upcoming LE auto connection mechanism in order to work
      properly with controllers that don't support background scanning and
      connection establishment at the same time.
      
      In future, we might want to do a small optimization by checking if
      controller is able to scan and connect at the same time. For now,
      we want the simplest approach so we always stop scanning (even if
      the controller is able to carry out both operations).
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2acf3d90
    • A
      Bluetooth: Declare le_conn_failed in hci_core.h · 06c053fb
      Andre Guedes 提交于
      This patch adds the "hci_" prefix to le_conn_failed() helper and
      declares it in hci_core.h so it can be reused in hci_event.c.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      06c053fb
    • A
      Bluetooth: Create hci_req_add_le_scan_disable helper · b1efcc28
      Andre Guedes 提交于
      This patch moves stop LE scanning duplicate code to one single
      place and reuses it. This will avoid more duplicate code in
      upcoming patches.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b1efcc28
    • J
      Bluetooth: Remove unneeded "force" parameter from smp_distribute_keys() · 4bd6d38e
      Johan Hedberg 提交于
      Now that to-be-received keys are properly tracked we no-longer need the
      "force" parameter to smp_distribute_keys(). It was essentially acting as
      an indicator whether all keys have been received, but now it's just
      redundant together with smp->remote_key_dist.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4bd6d38e
    • J
      Bluetooth: Simplify logic for checking for SMP completion · efabba37
      Johan Hedberg 提交于
      Now that smp->remote_key_dist is tracking the keys we're still waiting
      for we can use it to simplify the logic for checking whether we're done
      with key distribution or not. At the same time the reliance on the
      "force" parameter of smp_distribute_keys goes away and it can completely
      be removed in a subsequent patch.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      efabba37
    • J
      Bluetooth: Track not yet received keys in SMP · 9747a9f3
      Johan Hedberg 提交于
      To make is easier to track which keys we've received and which ones
      we're still waiting for simply clear the corresponding key bits from
      smp->remote_key_dist as they get received. This will allow us to
      simplify the code for checking for SMP completion in subsequent patches.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9747a9f3
  3. 26 2月, 2014 3 次提交
    • 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
    • J
      Bluetooth: Fix advertising address type when toggling connectable · a4858cb9
      Johan Hedberg 提交于
      When the connectable setting is toggled using mgmt_set_connectable the
      HCI_CONNECTABLE flag will only be set once the related HCI commands
      succeed. When determining what kind of advertising to do we need to
      therefore also check whether there is a pending Set Connectable command
      in addition to the current flag value.
      
      The enable_advertising function was already taking care of this for the
      advertising type with the help of the get_adv_type function, but was
      failing to do the same for the address type selection. This patch
      converts the get_adv_type function to be more generic in that it returns
      the expected connectable state and updates the enable_advertising
      function to use the return value both for the advertising type as well
      as the advertising address type.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a4858cb9
    • A
      Bluetooth: Fix NULL pointer dereference when sending data · ede81a2a
      Andrzej Kaczmarek 提交于
      When trying to allocate skb for new PDU, l2cap_chan is unlocked so we
      can sleep waiting for memory as otherwise there's possible deadlock as
      fixed in e454c844. However, in a6a5568c lock was moved from socket
      to channel level and it's no longer safe to just unlock and lock again
      without checking l2cap_chan state since channel can be disconnected
      when lock is not held.
      
      This patch adds missing checks for l2cap_chan state when returning from
      call which allocates skb.
      
      Scenario is easily reproducible by running rfcomm-tester in a loop.
      
      BUG: unable to handle kernel NULL pointer dereference at         (null)
      IP: [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth]
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU: 7 PID: 4038 Comm: krfcommd Not tainted 3.14.0-rc2+ #15
      Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A10 11/24/2011
      task: ffff8802bdd731c0 ti: ffff8801ec986000 task.ti: ffff8801ec986000
      RIP: 0010:[<ffffffffa0442169>]  [<ffffffffa0442169>] l2cap_do_send+0x29/0x120
      RSP: 0018:ffff8801ec987ad8  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff8800c5796800 RCX: 0000000000000000
      RDX: ffff880410e7a800 RSI: ffff8802b6c1da00 RDI: ffff8800c5796800
      RBP: ffff8801ec987af8 R08: 00000000000000c0 R09: 0000000000000300
      R10: 000000000000573b R11: 000000000000573a R12: ffff8802b6c1da00
      R13: 0000000000000000 R14: ffff8802b6c1da00 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88042dce0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000041257c000 CR4: 00000000000407e0
      Stack:
       ffff8801ec987d78 ffff8800c5796800 ffff8801ec987d78 0000000000000000
       ffff8801ec987ba8 ffffffffa0449e37 0000000000000004 ffff8801ec987af0
       ffff8801ec987d40 0000000000000282 0000000000000000 ffffffff00000004
      Call Trace:
       [<ffffffffa0449e37>] l2cap_chan_send+0xaa7/0x1120 [bluetooth]
       [<ffffffff81770100>] ? _raw_spin_unlock_bh+0x20/0x40
       [<ffffffffa045188b>] l2cap_sock_sendmsg+0xcb/0x110 [bluetooth]
       [<ffffffff81652b0f>] sock_sendmsg+0xaf/0xc0
       [<ffffffff810a8381>] ? update_curr+0x141/0x200
       [<ffffffff810a8961>] ? dequeue_entity+0x181/0x520
       [<ffffffff81652b60>] kernel_sendmsg+0x40/0x60
       [<ffffffffa04a8505>] rfcomm_send_frame+0x45/0x70 [rfcomm]
       [<ffffffff810766f0>] ? internal_add_timer+0x20/0x50
       [<ffffffffa04a8564>] rfcomm_send_cmd+0x34/0x60 [rfcomm]
       [<ffffffffa04a8605>] rfcomm_send_disc+0x75/0xa0 [rfcomm]
       [<ffffffffa04aacec>] rfcomm_run+0x8cc/0x1a30 [rfcomm]
       [<ffffffffa04aa420>] ? rfcomm_check_accept+0xc0/0xc0 [rfcomm]
       [<ffffffff8108e3a9>] kthread+0xc9/0xe0
       [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0
       [<ffffffff817795fc>] ret_from_fork+0x7c/0xb0
       [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0
      Code: 00 00 66 66 66 66 90 55 48 89 e5 48 83 ec 20 f6 05 d6 a3 02 00 04
      RIP  [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth]
       RSP <ffff8801ec987ad8>
      CR2: 0000000000000000
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ede81a2a
  4. 25 2月, 2014 5 次提交