summaryrefslogtreecommitdiffstats
path: root/net/bluetooth (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Add workaround for wrong HCI event in eSCO setupMarcel Holtmann2009-04-191-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | The Broadcom chips with 2.1 firmware handle the fallback case to a SCO link wrongly when setting up eSCO connections. < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 11 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 1 bdaddr 00:1E:3A:xx:xx:xx type SCO encrypt 0x01 The Link Manager negotiates the fallback to SCO, but then sends out a Connect Complete event. This is wrong and the Link Manager should actually send a Synchronous Connection Complete event if the Setup Synchronous Connection has been used. Only the remote side is allowed to use Connect Complete to indicate the missing support for eSCO in the host stack. This patch adds a workaround for this which clearly should not be needed, but reality is that broken Broadcom devices are deployed. Based on a report by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtman <marcel@holtmann.org>
* Bluetooth: Fallback from eSCO to SCO on unspecified errorMarcel Holtmann2009-04-191-9/+17
| | | | | | | | | | | | | | | | | | | | | | Some Bluetooth chips (like the ones from Texas Instruments) don't do proper eSCO negotiations inside the Link Manager. They just return an error code and in case of the Kyocera ED-8800 headset it is just a random error. < HCI Command: Setup Synchronous Connection 0x01|0x0028) plen 17 handle 1 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x1f handle 257 bdaddr 00:14:0A:xx:xx:xx type eSCO Error: Unspecified Error In these cases it is up to the host stack to fallback to a SCO setup and so retry with SCO parameters. Based on a report by Nick Pelly <npelly@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix removing of RFCOMM DLC timer with DEFER_SETUPJohan Hedberg2009-04-191-0/+2
| | | | | | | | | | | | | There is a missing call to rfcomm_dlc_clear_timer in the case that DEFER_SETUP is used and so the connection gets disconnected after the timeout even if it was successfully accepted previously. This patch adds a call to rfcomm_dlc_clear_timer to rfcomm_dlc_accept which will get called when the user accepts the connection by calling read() on the socket. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* proc tty: remove struct tty_operations::read_procAlexey Dobriyan2009-04-011-6/+0
| | | | | | | | | | struct tty_operations::proc_fops took it's place and there is one less create_proc_read_entry() user now! Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2009-03-262-3/+4
|\ | | | | | | | | Conflicts: drivers/net/wimax/i2400m/usb-notif.c
| * Driver core: Fix device_move() vs. dpm list ordering, v2Cornelia Huck2009-03-252-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dpm_list currently relies on the fact that child devices will be registered after their parents to get a correct suspend order. Using device_move() however destroys this assumption, as an already registered device may be moved under a newly registered one. This patch adds a new argument to device_move(), allowing callers to specify how dpm_list should be adapted. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | Bluetooth: Remove some pointless conditionals before kfree_skb()Wei Yongjun2009-02-273-6/+3
| | | | | | | | | | | | | | Remove some pointless conditionals before kfree_skb(). Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too earlyDave Young2009-02-272-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit introduce a regression: commit 7d0db0a373195385a2e0b19d1f5e4b186fdcffac 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: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Permit BT_SECURITY also for L2CAP raw socketsMarcel Holtmann2009-02-271-2/+2
| | | | | | | | | | | | | | | | | | Userspace pairing code can be simplified if it doesn't have to fall back to using L2CAP_LM in the case of L2CAP raw sockets. This patch allows the BT_SECURITY socket option to be used for these sockets. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix RFCOMM usage of in-kernel L2CAP socketsMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | The CID value of L2CAP sockets need to be set to zero. All userspace applications do this via memset() on the sockaddr_l2 structure. The RFCOMM implementation uses in-kernel L2CAP sockets and so it has to make sure that l2_cid is set to zero. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Disallow usage of L2CAP CID setting for nowMarcel Holtmann2009-02-271-6/+10
| | | | | | | | | | | | | | | | | | | | In the future the L2CAP layer will have full support for fixed channels and right now it already can export the channel assignment, but for the functions bind() and connect() the usage of only CID 0 is allowed. This allows an easy detection if the kernel supports fixed channels or not, because otherwise it would impossible for application to tell. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUPMarcel Holtmann2009-02-271-0/+11
| | | | | | | | | | | | | | | | | | When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2 state is designated for incoming connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix poll() misbehavior when using BT_DEFER_SETUPMarcel Holtmann2009-02-271-4/+3
| | | | | | | | | | | | | | | | | | When BT_DEFER_SETUP has been enabled on a Bluetooth socket it keeps signaling POLLIN all the time. This is a wrong behavior. The POLLIN should only be signaled if the client socket is in BT_CONNECT2 state and the parent has been BT_DEFER_SETUP enabled. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Set authentication requirement before requesting itMarcel Holtmann2009-02-271-6/+4
| | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix authentication requirements for L2CAP security checkMarcel Holtmann2009-02-271-10/+20
| | | | | | | | | | | | | | | | | | | | | | The L2CAP layer can trigger the authentication via an ACL connection or later on to increase the security level. When increasing the security level it didn't use the same authentication requirements when triggering a new ACL connection. Make sure that exactly the same authentication requirements are used. The only exception here are the L2CAP raw sockets which are only used for dedicated bonding. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Ask upper layers for HCI disconnect reasonMarcel Holtmann2009-02-274-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add CID field to L2CAP socket address structureMarcel Holtmann2009-02-271-21/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for L2CAP fixed channel support, the CID value of a L2CAP connection needs to be accessible via the socket interface. The CID is the connection identifier and exists as source and destination value. So extend the L2CAP socket address structure with this field and change getsockname() and getpeername() to fill it in. The bind() and connect() functions have been modified to handle L2CAP socket address structures of variable sizes. This makes them future proof if additional fields need to be added. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Request L2CAP fixed channel list if availableMarcel Holtmann2009-02-271-9/+31
| | | | | | | | | | | | | | | | | | | | If the extended features mask indicates support for fixed channels, request the list of available fixed channels. This also enables the fixed channel features bit so remote implementations can request information about it. Currently only the signal channel will be listed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3Marcel Holtmann2009-02-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind of authentication or encryption. So don't trigger authentication for incoming and outgoing SDP connections. For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with Bluetooth 2.1 the initiator is required to enable authentication and encryption first and this gets enforced. So there is no need to trigger an additional authentication step. The RFCOMM service security will make sure that a secure enough link key is present. When the encryption gets enabled after the SDP connection setup, then switch the security level from SDP to low security. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix double L2CAP connection requestMarcel Holtmann2009-02-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | If the remote L2CAP server uses authentication pending stage and encryption is enabled it can happen that a L2CAP connection request is sent twice due to a race condition in the connection state machine. When the remote side indicates any kind of connection pending, then track this state and skip sending of L2CAP commands for this period. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix race condition with L2CAP information requestMarcel Holtmann2009-02-271-3/+14
| | | | | | | | | | | | | | | | | | | | When two L2CAP connections are requested quickly after the ACL link has been established there exists a window for a race condition where a connection request is sent before the information response has been received. Any connection request should only be sent after an exchange of the extended features mask has been finished. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Set authentication requirements if not availableMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Use general bonding whenever possibleMarcel Holtmann2009-02-273-16/+39
| | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add SCO fallback for eSCO connection attemptsMarcel Holtmann2009-02-272-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Don't check encryption for L2CAP raw socketsMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | For L2CAP sockets with medium and high security requirement a missing encryption will enforce the closing of the link. For the L2CAP raw sockets this is not needed, so skip that check. This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices since the L2CAP state machine got confused and then locked up the whole system. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: When encryption is dropped, do not send RFCOMM packetsJaikumar Ganesh2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | During a role change with pre-Bluetooth 2.1 devices, the remote side drops the encryption of the RFCOMM connection. We allow a grace period for the encryption to be re-established, before dropping the connection. During this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag before sending RFCOMM packets. Signed-off-by: Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefsDave Young2009-02-271-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed now. So just remove it here. The following commit fixed the !lockdep build warnings: commit e8f6fbf62de37cbc2e179176ac7010d5f4396b67 Author: Ingo Molnar <mingo@elte.hu> Date: Wed Nov 12 01:38:36 2008 +0000 lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Update version numbersMarcel Holtmann2009-02-273-3/+3
| | | | | | | | | | | | | | | | | | | | | | With the support for the enhanced security model and the support for deferring connection setup, it is a good idea to increase various version numbers. This is purely cosmetic and has no effect on the behavior, but can be really helpful when debugging problems in different kernel versions. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Restrict application of socket optionsMarcel Holtmann2009-02-272-0/+32
| | | | | | | | | | | | | | | | | | | | | | The new socket options should only be evaluated for SOL_BLUETOOTH level and not for every other level. Previously this causes some minor issues when detecting if a kernel with certain features is available. Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for the RFCOMM protocol. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Disconnect L2CAP connections without encryptionMarcel Holtmann2009-02-271-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | For L2CAP connections with high security setting, the link will be immediately dropped when the encryption gets disabled. For L2CAP connections with medium security there will be grace period where the remote device has the chance to re-enable encryption. If it doesn't happen then the link will also be disconnected. The requirement for the grace period with medium security comes from Bluetooth 2.0 and earlier devices that require role switching. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Pause RFCOMM TX when encryption dropsMarcel Holtmann2009-02-271-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A role switch with devices following the Bluetooth pre-2.1 standards or without Encryption Pause and Resume support is not possible if encryption is enabled. Most newer headsets require the role switch, but also require that the connection is encrypted. For connections with a high security mode setting, the link will be immediately dropped. When the connection uses medium security mode setting, then a grace period is introduced where the TX is halted and the remote device gets a change to re-enable encryption after the role switch. If not re-enabled the link will be dropped. Based on initial work by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Replace RFCOMM link mode with security levelMarcel Holtmann2009-02-272-28/+75
| | | | | | | | | | | | | | Change the RFCOMM internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Replace L2CAP link mode with security levelMarcel Holtmann2009-02-271-50/+110
| | | | | | | | | | | | | | Change the L2CAP internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add enhanced security model for Simple PairingMarcel Holtmann2009-02-275-168/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix SCO state handling for incoming connectionsMarcel Holtmann2009-02-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When the remote device supports only SCO connections, on receipt of the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to BT_CONNECTED, but the socket state is not updated. Hence, the connect() call times out even though the SCO connection has been successfully established. Based on a report by Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Reject incoming SCO connections without listenersMarcel Holtmann2009-02-271-2/+22
| | | | | | | | | | | | | | | | All SCO and eSCO connection are auto-accepted no matter if there is a corresponding listening socket for them. This patch changes this and connection requests for SCO and eSCO without any socket are rejected. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add support for deferring L2CAP connection setupMarcel Holtmann2009-02-271-9/+101
| | | | | | | | | | | | | | | | | | In order to decide if listening L2CAP sockets should be accept()ed the BD_ADDR of the remote device needs to be known. This patch adds a socket option which defines a timeout for deferring the actual connection setup. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add support for deferring RFCOMM connection setupMarcel Holtmann2009-02-272-16/+84
| | | | | | | | | | | | | | | | | | | | | | | | In order to decide if listening RFCOMM sockets should be accept()ed the BD_ADDR of the remote device needs to be known. This patch adds a socket option which defines a timeout for deferring the actual connection setup. The connection setup is done after reading from the socket for the first time. Until then writing to the socket returns ENOTCONN. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add global deferred socket parameterMarcel Holtmann2009-02-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The L2CAP and RFCOMM applications require support for authorization and the ability of rejecting incoming connection requests. The socket interface is not really able to support this. This patch does the ground work for a socket option to defer connection setup. Setting this option allows calling of accept() and then the first read() will trigger the final connection setup. Calling close() would reject the connection. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Preparation for usage of SOL_BLUETOOTHMarcel Holtmann2009-02-273-5/+124
| | | | | | | | | | | | | | | | | | | | The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently in use by various Bluetooth applications. Going forward the common option level SOL_BLUETOOTH should be used. This patch prepares the clean split of the old and new option levels while keeping everything backward compatibility. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg()Victor Shcherbatyuk2009-02-271-1/+4
|/ | | | | | | | In case of connection failures the rfcomm_sock_sendmsg() should return an error and not a 0 value. Signed-off-by: Victor Shcherbatyuk <victor.shcherbatyuk@tomtom.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: driver API updateStephen Hemminger2009-01-083-27/+19
| | | | | | | | | | | | Convert to net_device_ops and use internal net_device_stats in bnep device. Note: no need for bnep_net_ioctl since if ioctl is not set, then dev_ifsioc handles it by returning -EOPNOTSUPP Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2008-12-241-2/+0
|\ | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/ppp_generic.c
| * net: Fix module refcount leak in kernel_accept()Wei Yongjun2008-12-191-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel_accept() does not hold the module refcount of newsock->ops->owner, so we need __module_get(newsock->ops->owner) code after call kernel_accept() by hand. In sunrpc, the module refcount is missing to hold. So this cause kernel panic. Used following script to reproduct: while [ 1 ]; do mount -t nfs4 192.168.0.19:/ /mnt touch /mnt/file umount /mnt lsmod | grep ipv6 done This patch fixed the problem by add __module_get(newsock->ops->owner) to kernel_accept(). So we do not need to used __module_get(newsock->ops->owner) in every place when used kernel_accept(). Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bt/rfcomm/tty: join error pathsIlpo Järvinen2008-12-151-6/+7
| | | | | | | | | | Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().David S. Miller2008-12-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Stephen Rothwell points out, we don't want 'sock' here but rather we really do want 'sk'. This local var is protected by all sorts of bluetooth debugging kconfig vars, but BT_DBG() is just a straight pr_debug() call which is unconditional. pr_debug() evaluates it's args only if either DEBUG or CONFIG_DYNAMIC_PRINTK_DEBUG is defined. Solving this inside of the BT_DBG() macro is non-trivial since it's varargs. And these ifdefs are ugly. So, just mark this 'sk' thing __maybe_unused and kill the ifdefs. Signed-off-by: David S. Miller <davem@davemloft.net>
* | bluetooth: Fix rfcomm_sock_ioctl() build failure with debugging enabled.David S. Miller2008-12-091-1/+1
| | | | | | | | | | | | It's 'sock' not 'sk'. Signed-off-by: David S. Miller <davem@davemloft.net>
* | Bluetooth: Fix RFCOMM release oops when device is still in useMarcel Holtmann2008-11-301-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the following sequence of actions will reproduce the oops: 1. Create a new RFCOMM device (using RFCOMMCREATEDEV ioctl) 2. (Try to) open the device 3. Release the RFCOMM device (using RFCOMMRELEASEDEV ioctl) At this point, the "/dev/rfcomm*" device is still in use, but it is gone from the internal list, so the device id can be reused. 4. Create a new RFCOMM device with the same device id as before And now kobject will complain that the TTY already exists. (See http://lkml.org/lkml/2008/7/13/89 for a reproducible test-case.) This patch attempts to correct this by only removing the device from the internal list of devices at the final unregister stage, so that the id won't get reused until the device has been completely destructed. This should be safe as the RFCOMM_TTY_RELEASED bit will be set for the device and prevent the device from being reopened after it has been released. Based on a report from Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix format arguments warningMarcel Holtmann2008-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Newer GCC versions are a little bit picky about how to deal with format arguments: net/bluetooth/hci_sysfs.c: In function ‘hci_register_sysfs’: net/bluetooth/hci_sysfs.c:418: warning: format not a string literal and no format arguments It is simple enough to fix and makes the compiler happy. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Enable per-module dynamic debug messagesMarcel Holtmann2008-11-3020-99/+4
| | | | | | | | | | | | | | | | | | | | | | With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to allow debugging without having to recompile the kernel. This patch turns all BT_DBG() calls into pr_debug() to support dynamic debug messages. As a side effect all CONFIG_BT_*_DEBUG statements are now removed and some broken debug entries have been fixed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 03:31:38 +0100