1. 15 Jun, 2011 1 commit
  2. 13 Jun, 2011 1 commit
  3. 11 May, 2011 1 commit
  4. 28 Apr, 2011 2 commits
  5. 27 Feb, 2011 1 commit
  6. 21 Feb, 2011 2 commits
  7. 16 Feb, 2011 4 commits
  8. 07 Feb, 2011 1 commit
  9. 19 Jan, 2011 3 commits
  10. 01 Dec, 2010 1 commit
  11. 27 Jul, 2010 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Defer SCO setup if mode change is pending · e73439d8
      Marcel Holtmann authored
      
      
      Certain headsets such as the Motorola H350 will reject SCO and eSCO
      connection requests while the ACL is transitioning from sniff mode
      to active mode. Add synchronization so that SCO and eSCO connection
      requests will wait until the ACL has fully transitioned to active mode.
      
      < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
      < HCI Command:  Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 12 voice setting 0x0040
      > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      > HCI Event: Number of Completed Packets (0x13) plen 5
          handle 12 packets 1
      > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 12 mode 0x00 interval 0
          Mode: Active
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
          Error: Connection Accept Timeout Exceeded
      Signed-off-by: default avatarRon Shaffer <rshaffer@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e73439d8
  12. 21 Jul, 2010 1 commit
  13. 08 Jul, 2010 1 commit
  14. 03 Feb, 2010 1 commit
    • Nick Pelly's avatar
      Bluetooth: Enter active mode before establishing a SCO link. · c390216b
      Nick Pelly authored
      
      
      When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
      to establish a SCO link. Fix by requesting active mode before requesting
      SCO connection. This improves SCO setup time to ~500ms.
      
      Bluetooth headsets that use a long interval time, and exhibit the long
      SCO connection time include Motorola H790, HX1 and H17. They have a
      CSR 2.1 chipset.
      
      Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
      TI1271.
      
      2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 1 mode 0x02 interval 2048
          Mode: Sniff
      2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 1 voice setting 0x0060
      2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
          status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
          Air mode: CVSD
      Signed-off-by: default avatarNick Pelly <npelly@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c390216b
  15. 15 Nov, 2009 1 commit
  16. 22 Aug, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Add extra device reference counting for connections · 9eba32b8
      Marcel Holtmann authored
      
      
      The device model itself has no real usable reference counting at the
      moment and this causes problems if parents are deleted before their
      children. The device model itself handles the memory details of this
      correctly, but the uevent order is not consistent. This causes various
      problems for systems like HAL or even X.
      
      So until device_put() does a proper cleanup, the device for Bluetooth
      connection will be protected with an extra reference counting to ensure
      the correct order of uevents when connections are terminated.
      
      This is not an automatic feature. Higher Bluetooth layers like HIDP or
      BNEP should grab this new reference to ensure that their uevents are
      send before the ones from the parent device.
      
      Based on a report by Brian Rogers <brian@xyzw.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9eba32b8
  17. 09 May, 2009 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections · 1b0336bb
      Marcel Holtmann authored
      
      
      The connection setup phase takes around 2 seconds or longer and in
      that time it is possible that the need for an ACL connection is no
      longer present. If that happens then, the connection attempt will
      be canceled.
      
      This only applies to outgoing connections, but currently it can also
      be triggered by incoming connection. Don't call hci_acl_connect_cancel()
      on incoming connection since these have to be either accepted or rejected
      in this state. Once they are successfully connected they need to be
      fully disconnected anyway.
      
      Also remove the wrong hci_acl_disconn() call for SCO and eSCO links
      since at this stage they can't be disconnected either, because the
      connection handle is still unknown.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJohan Hedberg <johan.hedberg@nokia.com>
      1b0336bb
    • Marcel Holtmann's avatar
      Bluetooth: Fix wrong module refcount when connection setup fails · 384943ec
      Marcel Holtmann authored
      
      
      The module refcount is increased by hci_dev_hold() call in hci_conn_add()
      and decreased by hci_dev_put() call in del_conn(). In case the connection
      setup fails, hci_dev_put() is never called.
      
      Procedure to reproduce the issue:
      
        # hciconfig hci0 up
        # lsmod | grep btusb                   -> "used by" refcount = 1
      
        # hcitool cc <non-exisiting bdaddr>    -> will get timeout
      
        # lsmod | grep btusb                   -> "used by" refcount = 2
        # hciconfig hci0 down
        # lsmod | grep btusb                   -> "used by" refcount = 1
        # rmmod btusb                          -> ERROR: Module btusb is in use
      
      The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
      to fix an issue with hci_dev going away before hci_conn. However that
      change was wrong and introduced this problem.
      
      When calling hci_conn_del() it has to call hci_dev_put() after freeing
      the connection details. This handling should be fully symmetric. The
      execution of del_conn() is done in a work queue and needs it own calls
      to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
      until the connection cleanup has been finished.
      
      Based on a report by Bing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarBing Zhao <bzhao@marvell.com>
      384943ec
  18. 04 May, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann authored
      
      
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: default avatarMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
  19. 28 Apr, 2009 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      
      
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3fdca1e1
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      
      
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      052b30b0
  20. 26 Feb, 2009 7 commits
    • Dave Young's avatar
      Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early · 2ae9a6be
      Dave Young authored
      The following commit introduce a regression:
      
      	commit 7d0db0a3
      
      
      	Author: Marcel Holtmann <marcel@holtmann.org>
      	Date:   Mon Jul 14 20:13:51 2008 +0200
      
      		[Bluetooth] Use a more unique bus name for connections
      
      I get panic as following (by netconsole):
      
      [ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4
      [ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice
      [ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4
      [ 2709.570169] usbcore: registered new interface driver btusb
      [ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f
      [ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80
      [ 2845.743087] *pde = 00000000
      [ 2845.743206] Oops: 0002 [#1] SMP
      [ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742]
      [ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051
      [ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0
      [ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80
      [ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002
      [ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8
      [ 2845.743742]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000)
      [ 2845.743742] Stack:
      [ 2845.743742]  c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400
      [ 2845.743742]  6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50
      [ 2845.743742]  00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] ? lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] ? _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] ? skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] ? tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] ? __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] ? do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] ? irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] ? do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] ? common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] ? cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] ? rest_init+0x4e/0x60
      [ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00
      [ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8
      [ 2845.743742] ---[ end trace 4c985b38f022279f ]---
      [ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt
      [ 2845.743742] ------------[ cut here ]------------
      [ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200()
      [ 2845.743742] Hardware name: Dell DM051
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742] Pid: 0, comm: swapper Tainted: G      D    2.6.29-rc5-smp #54
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
      [ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
      [ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160
      [ 2845.743742]  [<c046a563>] ? mutex_trylock+0xb3/0x180
      [ 2845.743742]  [<c046a4a8>] ? mutex_unlock+0x8/0x10
      [ 2845.743742]  [<c015b991>] smp_call_function_many+0x151/0x200
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
      [ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
      [ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
      [ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
      [ 2845.743742]  [<c010668f>] die+0x4f/0x70
      [ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
      [ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
      [ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
      [ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
      [ 2845.743742] ---[ end trace 4c985b38f02227a0 ]---
      [ 2845.743742] ------------[ cut here ]------------
      [ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110()
      [ 2845.743742] Hardware name: Dell DM051
      [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
      [ 2845.743742] Pid: 0, comm: swapper Tainted: G      D W  2.6.29-rc5-smp #54
      [ 2845.743742] Call Trace:
      [ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
      [ 2845.743742]  [<c012e000>] ? warn_slowpath+0x10/0xa0
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
      [ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
      [ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
      [ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
      [ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
      [ 2845.743742]  [<c0146384>] ? up+0x14/0x40
      [ 2845.743742]  [<c015b7be>] smp_call_function_single+0x8e/0x110
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c026d23f>] ? cpumask_next_and+0x1f/0x40
      [ 2845.743742]  [<c015b95a>] smp_call_function_many+0x11a/0x200
      [ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
      [ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
      [ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
      [ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
      [ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
      [ 2845.743742]  [<c010668f>] die+0x4f/0x70
      [ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
      [ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
      [ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
      [ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
      [ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
      [ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
      [ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
      [ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
      [ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
      [ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
      [ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
      [ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
      [ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
      [ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
      [ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
      [ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
      [ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
      [ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
      [ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
      [ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
      [ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
      [ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
      [ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
      [ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
      [ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
      [ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
      [ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
      [ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
      [ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
      [ 2845.743742] ---[ end trace 4c985b38f02227a1 ]---
      [ 2845.743742] Rebooting in 3 seconds..
      
      My logitec bluetooth mouse trying connect to pc, but
      pc side reject the connection again and again. then panic happens.
      
      The reason is due to hci_conn_del_sysfs now called in hci_event_packet,
      the del work is done in a workqueue, so it's possible done before
      skb_queue_purge called.
      
      I move the hci_conn_del_sysfs after skb_queue_purge just as that before
      marcel's commit.
      
      Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to
      hci_conn_del will deal with the work.
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2ae9a6be
    • Marcel Holtmann's avatar
      Bluetooth: Set authentication requirement before requesting it · 96a31833
      Marcel Holtmann authored
      
      
      The authentication requirement got only updated when the security level
      increased. This is a wrong behavior. The authentication requirement is
      read by the Bluetooth daemon to make proper decisions when handling the
      IO capabilities exchange. So set the value that is currently expected by
      the higher layers like L2CAP and RFCOMM.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      96a31833
    • Marcel Holtmann's avatar
      Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
      Marcel Holtmann authored
      
      
      Some of the qualification tests demand that in case of failures in L2CAP
      the HCI disconnect should indicate a reason why L2CAP fails. This is a
      bluntly layer violation since multiple L2CAP connections could be using
      the same ACL and thus forcing a disconnect reason is not a good idea.
      
      To comply with the Bluetooth test specification, the disconnect reason
      is now stored in the L2CAP connection structure and every time a new
      L2CAP channel is added it will set back to its default. So only in the
      case where the L2CAP channel with the disconnect reason is really the
      last one, it will propagated to the HCI layer.
      
      The HCI layer has been extended with a disconnect indication that allows
      it to ask upper layers for a disconnect reason. The upper layer must not
      support this callback and in that case it will nicely default to the
      existing behavior. If an upper layer like L2CAP can provide a disconnect
      reason that one will be used to disconnect the ACL or SCO link.
      
      No modification to the ACL disconnect timeout have been made. So in case
      of Linux to Linux connection the initiator will disconnect the ACL link
      before the acceptor side can signal the specific disconnect reason. That
      is perfectly fine since Linux doesn't make use of this value anyway. The
      L2CAP layer has a perfect valid error code for rejecting connection due
      to a security violation. It is unclear why the Bluetooth specification
      insists on having specific HCI disconnect reason.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2950f21a
    • Marcel Holtmann's avatar
      Bluetooth: Set authentication requirements if not available · 657e17b0
      Marcel Holtmann authored
      
      
      When no authentication requirements are selected, but an outgoing or
      incoming connection has requested any kind of security enforcement,
      then set these authentication requirements.
      
      This ensures that the userspace always gets informed about the
      authentication requirements (if available). Only when no security
      enforcement has happened, the kernel will signal invalid requirements.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      657e17b0
    • Marcel Holtmann's avatar
      Bluetooth: Use general bonding whenever possible · 0684e5f9
      Marcel Holtmann authored
      
      
      When receiving incoming connection to specific services, always use
      general bonding. This ensures that the link key gets stored and can be
      used for further authentications.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0684e5f9
    • Marcel Holtmann's avatar
      Bluetooth: Add SCO fallback for eSCO connection attempts · efc7688b
      Marcel Holtmann authored
      
      
      When attempting to setup eSCO connections it can happen that some link
      manager implementations fail to properly negotiate the eSCO parameters
      and thus fail the eSCO setup. Normally the link manager is responsible
      for the negotiation of the parameters and actually fallback to SCO if
      no agreement can be reached. In cases where the link manager is just too
      stupid, then at least try to establish a SCO link if eSCO fails.
      
      For the Bluetooth devices with EDR support this includes handling packet
      types of EDR basebands. This is particular tricky since for the EDR the
      logic of enabling/disabling one specific packet type is turned around.
      This fix contains an extra bitmask to disable eSCO EDR packet when
      trying to fallback to a SCO connection.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      efc7688b
    • Marcel Holtmann's avatar
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann authored
      
      
      The current security model is based around the flags AUTH, ENCRYPT and
      SECURE. Starting with support for the Bluetooth 2.1 specification this is
      no longer sufficient. The different security levels are now defined as
      SDP, LOW, MEDIUM and SECURE.
      
      Previously it was possible to set each security independently, but this
      actually doesn't make a lot of sense. For Bluetooth the encryption depends
      on a previous successful authentication. Also you can only update your
      existing link key if you successfully created at least one before. And of
      course the update of link keys without having proper encryption in place
      is a security issue.
      
      The new security levels from the Bluetooth 2.1 specification are now
      used internally. All old settings are mapped to the new values and this
      way it ensures that old applications still work. The only limitation
      is that it is no longer possible to set authentication without also
      enabling encryption. No application should have done this anyway since
      this is actually a security issue. Without encryption the integrity of
      the authentication can't be guaranteed.
      
      As default for a new L2CAP or RFCOMM connection, the LOW security level
      is used. The only exception here are the service discovery sessions on
      PSM 1 where SDP level is used. To have similar security strength as with
      a Bluetooth 2.0 and before combination key, the MEDIUM level should be
      used. This is according to the Bluetooth specification. The MEDIUM level
      will not require any kind of man-in-the-middle (MITM) protection. Only
      the HIGH security level will require this.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
  21. 30 Nov, 2008 1 commit
  22. 08 Sep, 2008 2 commits
    • Marcel Holtmann's avatar
      [Bluetooth] Reject L2CAP connections on an insecure ACL link · e7c29cb1
      Marcel Holtmann authored
      
      
      The Security Mode 4 of the Bluetooth 2.1 specification has strict
      authentication and encryption requirements. It is the initiators job
      to create a secure ACL link. However in case of malicious devices, the
      acceptor has to make sure that the ACL is encrypted before allowing
      any kind of L2CAP connection. The only exception here is the PSM 1 for
      the service discovery protocol, because that is allowed to run on an
      insecure ACL link.
      
      Previously it was enough to reject a L2CAP connection during the
      connection setup phase, but with Bluetooth 2.1 it is forbidden to
      do any L2CAP protocol exchange on an insecure link (except SDP).
      
      The new hci_conn_check_link_mode() function can be used to check the
      integrity of an ACL link. This functions also takes care of the cases
      where Security Mode 4 is disabled or one of the devices is based on
      an older specification.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e7c29cb1
    • Marcel Holtmann's avatar
      [Bluetooth] Enforce correct authentication requirements · 09ab6f4c
      Marcel Holtmann authored
      
      
      With the introduction of Security Mode 4 and Simple Pairing from the
      Bluetooth 2.1 specification it became mandatory that the initiator
      requires authentication and encryption before any L2CAP channel can
      be established. The only exception here is PSM 1 for the service
      discovery protocol (SDP). It is meant to be used without any encryption
      since it contains only public information. This is how Bluetooth 2.0
      and before handle connections on PSM 1.
      
      For Bluetooth 2.1 devices the pairing procedure differentiates between
      no bonding, general bonding and dedicated bonding. The L2CAP layer
      wrongly uses always general bonding when creating new connections, but it
      should not do this for SDP connections. In this case the authentication
      requirement should be no bonding and the just-works model should be used,
      but in case of non-SDP connection it is required to use general bonding.
      
      If the new connection requires man-in-the-middle (MITM) protection, it
      also first wrongly creates an unauthenticated link key and then later on
      requests an upgrade to an authenticated link key to provide full MITM
      protection. With Simple Pairing the link key generation is an expensive
      operation (compared to Bluetooth 2.0 and before) and doing this twice
      during a connection setup causes a noticeable delay when establishing
      a new connection. This should be avoided to not regress from the expected
      Bluetooth 2.0 connection times. The authentication requirements are known
      up-front and so enforce them.
      
      To fulfill these requirements the hci_connect() function has been extended
      with an authentication requirement parameter that will be stored inside
      the connection information and can be retrieved by userspace at any
      time. This allows the correct IO capabilities exchange and results in
      the expected behavior.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      09ab6f4c
  23. 14 Jul, 2008 2 commits
    • Marcel Holtmann's avatar
      [Bluetooth] Use a more unique bus name for connections · 7d0db0a3
      Marcel Holtmann authored
      
      
      When attaching Bluetooth low-level connections to the bus, the bus name
      is constructed from the remote address since at that time the connection
      handle is not assigned yet. This has worked so far, but also caused a
      lot of troubles. It is better to postpone the creation of the sysfs
      entry to the time when the connection actually has been established
      and then use its connection handle as unique identifier.
      
      This also fixes the case where two different adapters try to connect
      to the same remote device.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7d0db0a3
    • Marcel Holtmann's avatar
      [Bluetooth] Export details about authentication requirements · 40be492f
      Marcel Holtmann authored
      
      
      With the Simple Pairing support, the authentication requirements are
      an explicit setting during the bonding process. Track and enforce the
      requirements and allow higher layers like L2CAP and RFCOMM to increase
      them if needed.
      
      This patch introduces a new IOCTL that allows to query the current
      authentication requirements. It is also possible to detect Simple
      Pairing support in the kernel this way.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      40be492f