| Age | Commit message (Collapse) | Author |
|---|
|
This adds support for generating and distributing all the keys
specified in the third phase of SMP.
This will make possible to re-establish secure connections, resolve
private addresses and sign commands.
For now, the values generated are random.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
The ERTM receive buffer is now handled in a way that does not require
the busy queue and the associated polling code.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This change moves most L2CAP ERTM receive buffer handling out of the
L2CAP core and in to the socket code. It's up to the higher layer
(the socket code, in this case) to tell the core when its buffer is
full or has space available. The recv op should always accept
incoming ERTM data or else the connection will go down.
Within the socket layer, an skb that does not fit in the socket
receive buffer will be temporarily stored. When the socket is read
from, that skb will be placed in the receive buffer if possible. Once
adequate buffer space becomes available, the L2CAP core is informed
and the ERTM local busy state is cleared.
Receive buffer management for non-ERTM modes is unchanged.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
The local busy state is entered and exited based on buffer status in
the socket layer (or other upper layer). This change is in
preparation for general buffer status reports from the socket layer,
which will then be used to change the local busy status.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
All threads running in process context should disable local bottom
halve before locking hdev->lock.
This patch fix the following message generated when Bluetooh module
is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).
[ 107.880781] =================================
[ 107.881631] [ INFO: inconsistent lock state ]
[ 107.881631] 2.6.39+ #1
[ 107.881631] ---------------------------------
[ 107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
[ 107.881631] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] {SOFTIRQ-ON-W} state was registered at:
[ 107.881631] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 107.881631] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 107.881631] [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
[ 107.881631] [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[ 107.881631] [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
[ 107.881631] [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
[ 107.881631] [<ffffffff810a3beb>] vfs_write+0xaa/0xca
[ 107.881631] [<ffffffff810a3d80>] sys_write+0x45/0x69
[ 107.881631] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[ 107.881631] irq event stamp: 2100876
[ 107.881631] hardirqs last enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
[ 107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[ 107.881631] softirqs last enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[ 107.881631]
[ 107.881631] other info that might help us debug this:
[ 107.881631] Possible unsafe locking scenario:
[ 107.881631]
[ 107.881631] CPU0
[ 107.881631] ----
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631] <Interrupt>
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631]
[ 107.881631] *** DEADLOCK ***
[ 107.881631]
[ 107.881631] 1 lock held by rcuc0/7:
[ 107.881631] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 107.881631]
[ 107.881631] stack backtrace:
[ 107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
[ 107.881631] Call Trace:
[ 107.881631] <IRQ> [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[ 107.881631] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[ 107.881631] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 107.881631] [<ffffffff810504bb>] mark_lock+0x106/0x258
[ 107.881631] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[ 107.881631] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffff81052615>] ? lock_release+0x16c/0x179
[ 107.881631] [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
[ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
[ 107.881631] [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
[ 107.881631] [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[ 107.881631] [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
[ 107.881631] [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[ 107.881631] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 107.881631] [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
[ 107.881631] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[ 107.881631] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[ 107.881631] [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[ 107.881631] <EOI> [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
[ 107.881631] [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
[ 107.881631] [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
[ 107.881631] [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
[ 107.881631] [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
[ 107.881631] [<ffffffff81040f0a>] kthread+0x7f/0x87
[ 107.881631] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[ 107.881631] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 107.881631] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[ 107.881631] [<ffffffff812b55c0>] ? gs_change+0x13/0x13
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Since hdev->lock may be acquired by threads runnning in interrupt
context, all threads running in process context should disable
local bottom halve before locking hdev->lock. This can be done by
using hci_dev_lock_bh macro.
This way, we avoid potencial deadlocks like this one reported by
CONFIG_PROVE_LOCKING=y.
[ 304.788780] =================================
[ 304.789686] [ INFO: inconsistent lock state ]
[ 304.789686] 2.6.39+ #1
[ 304.789686] ---------------------------------
[ 304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 304.789686] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] {SOFTIRQ-ON-W} state was registered at:
[ 304.789686] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
[ 304.789686] [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[ 304.789686] [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
[ 304.789686] [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
[ 304.789686] [<ffffffff810b1059>] sys_ioctl+0x42/0x65
[ 304.789686] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[ 304.789686] irq event stamp: 9768
[ 304.789686] hardirqs last enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
[ 304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[ 304.789686] softirqs last enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
[ 304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[ 304.789686]
[ 304.789686] other info that might help us debug this:
[ 304.789686] Possible unsafe locking scenario:
[ 304.789686]
[ 304.789686] CPU0
[ 304.789686] ----
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686] <Interrupt>
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686]
[ 304.789686] *** DEADLOCK ***
[ 304.789686]
[ 304.789686] 1 lock held by ksoftirqd/0/3:
[ 304.789686] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 304.789686]
[ 304.789686] stack backtrace:
[ 304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
[ 304.789686] Call Trace:
[ 304.789686] [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[ 304.789686] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[ 304.789686] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 304.789686] [<ffffffff810504bb>] mark_lock+0x106/0x258
[ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 304.789686] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[ 304.789686] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[ 304.789686] [<ffffffff812ae126>] ? printk+0x3c/0x3e
[ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
[ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
[ 304.789686] [<ffffffff81052615>] ? lock_release+0x16c/0x179
[ 304.789686] [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
[ 304.789686] [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[ 304.789686] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 304.789686] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[ 304.789686] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[ 304.789686] [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[ 304.789686] [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
[ 304.789686] [<ffffffff81040f0a>] kthread+0x7f/0x87
[ 304.789686] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 304.789686] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[ 304.789686] [<ffffffff812b55c0>] ? gs_change+0x13/0x13
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
The enable_smp parameter is no longer needed. It can be replaced by
checking lmp_host_le_capable.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Since we have the extended LMP features properly implemented, we
should check the LMP_HOST_LE bit to know if the host supports LE.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch adds a new module parameter to enable/disable host LE
support. By default host LE support is disabled.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch adds a handler to Write LE Host Supported command complete
events. Once this commands has completed successfully, we should
read the extended LMP features and update the extfeatures field in
hci_dev.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This new field holds the extended LMP features value. Some LE
mechanism such as discovery procedure needs to read the extended
LMP features to work properly.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Even when the received tx_seq is expected, the frame still needs to be
dropped if the TX window is exceeded or the receiver is in the local
busy state.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Add a local logging function to emit bluetooth specific
messages. Using vsprintf extension %pV saves code/text
space.
Convert the current BT_INFO and BT_ERR macros to use bt_printk.
Remove __func__ from BT_ERR macro (and the uses).
Prefix "Bluetooth: " to BT_ERR
Remove __func__ from BT_DBG as function can be prefixed when
using dynamic_debug.
With allyesconfig:
text data bss dec hex filename
129956 8632 36096 174684 2aa5c drivers/bluetooth/built-in.o.new2
134402 8632 36064 179098 2bb9a drivers/bluetooth/built-in.o.old
14778 1012 3408 19198 4afe net/bluetooth/bnep/built-in.o.new2
15067 1012 3408 19487 4c1f net/bluetooth/bnep/built-in.o.old
346595 19163 86080 451838 6e4fe net/bluetooth/built-in.o.new2
353751 19163 86064 458978 700e2 net/bluetooth/built-in.o.old
18483 1172 4264 23919 5d6f net/bluetooth/cmtp/built-in.o.new2
18927 1172 4264 24363 5f2b net/bluetooth/cmtp/built-in.o.old
19237 1172 5152 25561 63d9 net/bluetooth/hidp/built-in.o.new2
19581 1172 5152 25905 6531 net/bluetooth/hidp/built-in.o.old
59461 3884 14464 77809 12ff1 net/bluetooth/rfcomm/built-in.o.new2
61206 3884 14464 79554 136c2 net/bluetooth/rfcomm/built-in.o.old
with x86 defconfig (and just bluetooth):
$ size net/bluetooth/built-in.o.defconfig.*
text data bss dec hex filename
66358 933 100 67391 1073f net/bluetooth/built-in.o.defconfig.new
66643 933 100 67676 1085c net/bluetooth/built-in.o.defconfig.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Make it easier to use more normal logging styles later.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
ERTM timeouts are defined in milliseconds, but need to be converted
to jiffies when passed to mod_timer().
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO
to make sure that those interfaces are present.
Fixes these build errors when CRYPTO is not enabled:
net/built-in.o: In function `hci_register_dev':
(.text+0x4cf86): undefined reference to `crypto_alloc_base'
net/built-in.o: In function `hci_unregister_dev':
(.text+0x4f912): undefined reference to `crypto_destroy_tfm'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
net/bluetooth/smp.c: In function 'smp_e':
net/bluetooth/smp.c:49:21: error: storage size of 'sg' isn't known
net/bluetooth/smp.c:67:2: error: implicit declaration of function 'sg_init_one'
net/bluetooth/smp.c:49:21: warning: unused variable 'sg'
Caused by commit d22ef0bc83c5 ("Bluetooth: Add LE SMP Cryptoolbox
functions"). Missing include file, presumably. This batch has been in
the bluetooth tree since June 14, so it may have been exposed by the
removal of linux/mm.h from netdevice.h ...
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Use the new consistent dump feature from (generic) netlink
to advertise when dumps are incomplete.
Readers may note that this does not initialize the
rdev->bss_generation counter to a non-zero value. This is
still OK since the value is modified only under spinlock
when the list is modified. Since the dump code holds the
spinlock, the value will either be > 0 already, or the
list will still be empty in which case a consistent dump
will actually be made (and be empty).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Consider the following situation:
* a dump that would show 8 entries, four in the first
round, and four in the second
* between the first and second rounds, 6 entries are
removed
* now the second round will not show any entry, and
even if there is a sequence/generation counter the
application will not know
To solve this problem, add a new flag NLM_F_DUMP_INTR
to the netlink header that indicates the dump wasn't
consistent, this flag can also be set on the MSG_DONE
message that terminates the dump, and as such above
situation can be detected.
To achieve this, add a sequence counter to the netlink
callback struct. Of course, netlink code still needs
to use this new functionality. The correct way to do
that is to always set cb->seq when a dumpit callback
is invoked and call nl_dump_check_consistent() for
each new message. The core code will also call this
function for the final MSG_DONE message.
To make it usable with generic netlink, a new function
genlmsg_nlhdr() is needed to obtain the netlink header
from the genetlink user header.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6
|
|
When the connection is ready we should set the connection
to CONNECTED so userspace can use it.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Conflicts:
net/bluetooth/l2cap_core.c
|
|
Cancel all relevant timers/works before suspending (wowlan).
This patch handles the following warning:
WARNING: at net/mac80211/util.c:565 queueing ieee80211 work while going to suspend
Backtrace:
[<bf07b598>] (ieee80211_can_queue_work+0x0/0x4c [mac80211])
[<bf07c28c>] (ieee80211_queue_work+0x0/0x30 [mac80211])
[<bf0690dc>] (ieee80211_sta_timer+0x0/0x3c [mac80211])
[<c00a3008>] (run_timer_softirq+0x0/0x220)
[<c009e530>] (__do_softirq+0x0/0x130)
[<c009e660>] (irq_exit+0x0/0xb4)
[<c004c4a0>] (ipi_timer+0x0/0x4c)
[<c0046350>] (do_local_timer+0x0/0x88)
[<c00488ec>] (cpu_idle+0x0/0xe0)
[<c05294e8>] (rest_init+0x0/0xe0)
[<c0008958>] (start_kernel+0x0/0x314)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We already have access to the chan, we don't have to access the
socket to get its imtu.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
We should not try to do any other type of configuration for
LE links when they become ready.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
There was no unlock call on the errors path
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
When suspending, __ieee80211_suspend() calls ieee80211_scan_cancel(),
which will only cancel sw scan. In order to cancel hw scan, the
low-level driver has to cancel it in the suspend() callback. however,
this is too late, as a new scan_work will be enqueued (while the driver
is going into suspend).
Add a new cancel_hw_scan() callback, asking the driver to cancel an
active hw scan, and call it in ieee80211_scan_cancel().
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Trigger connection monitor on resume from suspend. Since we
have been sleeping, there is reason to suspect that we might
not still be associated. The speed of detecting loss of
{connection,authentication} is worth the cost of the small
additional traffic at resume.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Instead of setting bits manually we use set_bit, test_bit, etc.
Also remove L2CAP_ prefix from macros.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Instead of making the bit operations manually, we now use set_bit,
test_bit, etc.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Management interface commands for blocking and unblocking devices.
Signed-off-by: Antti Julku <antti.julku@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Move blacklisting functions to hci_core.c, so that they can
be used by both management interface and hci socket interface.
Signed-off-by: Antti Julku <antti.julku@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
In hci_conn_security ( which is used during L2CAP connection
establishment ) test for HCI_CONN_ENCRYPT_PEND state also
sets this state, which is bogus and leads to connection time-out
on L2CAP sockets in certain situations (especially when
using non-ssp devices )
Signed-off-by: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch implements a check in smp cmd pairing request and pairing
response to verify if encryption key maximum size is compatible in both
slave and master when SMP Pairing is requested. Keys are also masked to
the correct negotiated size.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch adds support for disconnecting the link when SMP procedure
takes more than 30 seconds.
SMP begins when either the Pairing Request command is sent or the
Pairing Response is received, and it ends when the link is encrypted
(or terminated). Vol 3, Part H Section 3.4.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
When authentication completes we shouldn't blindly accept any pending
L2CAP connect requests. If the socket has the defer_setup feature
enabled it should still wait for user space acceptance of the connect
request. The issue only happens for non-SSP connections since with SSP
the L2CAP Connect request may not be sent for non-SDP PSMs before
authentication has completed successfully.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
The "dc" variable is initialized but not passed to hci_send_cmd().
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Bruna Moreira <bruna.moreira@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch implements a simple version of the SMP Pairing Features
exchange procedure (Vol. 3 Part H, Section 2.3.5.1).
For now, everything that would cause a Pairing Method different of
Just Works to be chosen is rejected.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Before we are able to do a proper exchange of pairing parameters,
we need a unified way of building pairing requests and responses.
For IO Capability we use the value that was set by userspace,
using the management interface.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
As the default security level (BT_SECURITY_SDP) doesn't make sense for
LE links, initialize LE links with something that makes sense.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This adds support for resuming the user space traffic when SMP
negotiation is complete.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Now that these commands are sent to the controller we can use hcidump
to verify that the correct values are produced.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This adds support for starting SMP Phase 2 Encryption, when the initial
SMP negotiation is successful. This adds the LE Start Encryption and LE
Long Term Key Request commands and related events.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch includes support for generating and sending the random value
used to produce the confirmation value.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch adds initial support for verifying the confirmation value
that the remote side has sent.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This patch implements SMP crypto functions called ah, c1, s1 and e.
It also implements auxiliary functions. All These functions are needed
for SMP keys generation.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Bruna Moreira <bruna.moreira@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This will allow using the crypto subsystem for encrypting data. As SMP
(Security Manager Protocol) is implemented almost entirely on the host
side and the crypto module already implements the needed methods
(AES-128), it makes sense to use it.
There's now a new module option to enable/disable SMP support.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
This implementation only exchanges SMP messages between the Host and the
Remote. No keys are being generated. TK and STK generation will be
provided in further patches.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
