1. 06 Jan, 2014 6 commits
    • Gianluca Anzolin's avatar
      Bluetooth: Remove rfcomm_carrier_raised() · f86772af
      Gianluca Anzolin authored
      Remove the rfcomm_carrier_raised() definition as that function isn't
      used anymore.
      Signed-off-by: default avatarGianluca Anzolin <gianluca@sottospazio.it>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f86772af
    • Gianluca Anzolin's avatar
      Bluetooth: Always wait for a connection on RFCOMM open() · 4a2fb3ec
      Gianluca Anzolin authored
      This patch fixes two regressions introduced with the recent rfcomm tty
      rework.
      
      The current code uses the carrier_raised() method to wait for the
      bluetooth connection when a process opens the tty.
      
      However processes may open the port with the O_NONBLOCK flag or set the
      CLOCAL termios flag: in these cases the open() syscall returns
      immediately without waiting for the bluetooth connection to
      complete.
      
      This behaviour confuses userspace which expects an established bluetooth
      connection.
      
      The patch restores the old behaviour by waiting for the connection in
      rfcomm_dev_activate() and removes carrier_raised() from the tty_port ops.
      
      As a side effect the new code also fixes the case in which the rfcomm
      tty device is created with the flag RFCOMM_REUSE_DLC: the old code
      didn't call device_move() and ModemManager skipped the detection
      probe. Now device_move() is always called inside rfcomm_dev_activate().
      Signed-off-by: default avatarGianluca Anzolin <gianluca@sottospazio.it>
      Reported-by: default avatarAndrey Vihrov <andrey.vihrov@gmail.com>
      Reported-by: default avatarBeson Chow <blc+bluez@mail.vanade.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4a2fb3ec
    • Gianluca Anzolin's avatar
      Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate() · e228b633
      Gianluca Anzolin authored
      This is a preparatory patch which moves the rfcomm_get_device()
      definition before rfcomm_dev_activate() where it will be used.
      Signed-off-by: default avatarGianluca Anzolin <gianluca@sottospazio.it>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e228b633
    • Gianluca Anzolin's avatar
      Bluetooth: Release RFCOMM port when the last user closes the TTY · 5b899241
      Gianluca Anzolin authored
      This patch fixes a userspace regression introduced by the commit
      29cd718b.
      
      If the rfcomm device was created with the flag RFCOMM_RELEASE_ONHUP the
      user space expects that the tty_port is released as soon as the last
      process closes the tty.
      
      The current code attempts to release the port in the function
      rfcomm_dev_state_change(). However it won't get a reference to the
      relevant tty to send a HUP: at that point the tty is already destroyed
      and therefore NULL.
      
      This patch fixes the regression by taking over the tty refcount in the
      tty install method(). This way the tty_port is automatically released as
      soon as the tty is destroyed.
      
      As a consequence the check for RFCOMM_RELEASE_ONHUP flag in the hangup()
      method is now redundant. Instead we have to be careful with the reference
      counting in the rfcomm_release_dev() function.
      Signed-off-by: default avatarGianluca Anzolin <gianluca@sottospazio.it>
      Reported-by: default avatarAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5b899241
    • Johan Hedberg's avatar
      Bluetooth: Default to no security with L2CAP RAW sockets · cb6ca8e1
      Johan Hedberg authored
      L2CAP RAW sockets can be used for things which do not involve
      establishing actual connection oriented L2CAP channels. One example of
      such usage is the l2ping tool. The default security level for L2CAP
      sockets is LOW, which implies that for SSP based connection
      authentication is still requested (although with no MITM requirement),
      which is not what we want (or need) for things like l2ping. Therefore,
      default to one lower level, i.e. BT_SECURITY_SDP, for L2CAP RAW sockets
      in order not to trigger unwanted authentication requests.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cb6ca8e1
    • Johan Hedberg's avatar
      Bluetooth: Fix NULL pointer dereference when disconnecting · 8cef8f50
      Johan Hedberg authored
      When disconnecting it is possible that the l2cap_conn pointer is already
      NULL when bt_6lowpan_del_conn() is entered. Looking at l2cap_conn_del
      also verifies this as there's a NULL check there too. This patch adds
      the missing NULL check without which the following bug may occur:
      
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<c131e9c7>] bt_6lowpan_del_conn+0x19/0x12a
      *pde = 00000000
      Oops: 0000 [#1] SMP
      CPU: 1 PID: 52 Comm: kworker/u5:1 Not tainted 3.12.0+ #196
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Workqueue: hci0 hci_rx_work
      task: f6259b00 ti: f48c0000 task.ti: f48c0000
      EIP: 0060:[<c131e9c7>] EFLAGS: 00010282 CPU: 1
      EIP is at bt_6lowpan_del_conn+0x19/0x12a
      EAX: 00000000 EBX: ef094e10 ECX: 00000000 EDX: 00000016
      ESI: 00000000 EDI: f48c1e60 EBP: f48c1e50 ESP: f48c1e34
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      CR0: 8005003b CR2: 00000000 CR3: 30c65000 CR4: 00000690
      Stack:
       f4d38000 00000000 f4d38000 00000002 ef094e10 00000016 f48c1e60 f48c1e70
       c1316bed f48c1e84 c1316bed 00000000 00000001 ef094e10 f48c1e84 f48c1ed0
       c1303cc6 c1303c7b f31f331a c1303cc6 f6e7d1c0 f3f8ea16 f3f8f380 f4d38008
      Call Trace:
       [<c1316bed>] l2cap_disconn_cfm+0x3f/0x5b
       [<c1316bed>] ? l2cap_disconn_cfm+0x3f/0x5b
       [<c1303cc6>] hci_event_packet+0x645/0x2117
       [<c1303c7b>] ? hci_event_packet+0x5fa/0x2117
       [<c1303cc6>] ? hci_event_packet+0x645/0x2117
       [<c12681bd>] ? __kfree_skb+0x65/0x68
       [<c12681eb>] ? kfree_skb+0x2b/0x2e
       [<c130d3fb>] ? hci_send_to_sock+0x18d/0x199
       [<c12fa327>] hci_rx_work+0xf9/0x295
       [<c12fa327>] ? hci_rx_work+0xf9/0x295
       [<c1036d25>] process_one_work+0x128/0x1df
       [<c1346a39>] ? _raw_spin_unlock_irq+0x8/0x12
       [<c1036d25>] ? process_one_work+0x128/0x1df
       [<c103713a>] worker_thread+0x127/0x1c4
       [<c1037013>] ? rescuer_thread+0x216/0x216
       [<c103aec6>] kthread+0x88/0x8d
       [<c1040000>] ? task_rq_lock+0x37/0x6e
       [<c13474b7>] ret_from_kernel_thread+0x1b/0x28
       [<c103ae3e>] ? __kthread_parkme+0x50/0x50
      Code: 05 b8 f4 ff ff ff 8d 65 f4 5b 5e 5f 5d 8d 67 f8 5f c3 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 89 e5 57 56f
      EIP: [<c131e9c7>] bt_6lowpan_del_conn+0x19/0x12a SS:ESP 0068:f48c1e34
      CR2: 0000000000000000
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8cef8f50
  2. 04 Jan, 2014 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Deal with USB devices that are faking CSR vendor · 81cac64b
      Marcel Holtmann authored
      There exists a set of Bluetooth USB devices that show up on the USB
      bus as 0a12:0001 and identify themselves as devices from CSR. However
      they are not. When sending Read Local Version command they now have
      a split personality and say they are from Broadcom.
      
        < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
        > HCI Event: Command Complete (0x0e) plen 12
            Read Local Version Information (0x04|0x0001) ncmd 1
            status 0x00
            HCI Version: 2.0 (0x3) HCI Revision: 0x3000
            LMP Version: 2.0 (0x3) LMP Subversion: 0x420b
            Manufacturer: Broadcom Corporation (15)
      
      The assumption is that they are neither CSR nor Broadcom based devices
      and that they are designed and manufactured by someone else.
      
      For the most parts they follow the Bluetooth HCI specification and
      can be used as standard Bluetooth devices. However they have the
      minor problem that the Delete Stored Link Key command is not working
      as it should.
      
      During the Bluetooth controller setup, this command is needed if
      stored link keys are supported. For these devices it has to be
      assumed that this is broken and so just set a quirk to clearly
      indicate the behavior. After that the setup can just proceed.
      
      Now the trick part is to detect these faulty devices since we do
      not want to punish all CSR and all Broadcom devices. The original
      devices do actually work according to the specification.
      
      What is known so far is that these broken devices set the USB bcdDevice
      revision information to 1.0 or less.
      
      T:  Bus=02 Lev=01 Prnt=01 Port=08 Cnt=03 Dev#=  9 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0a12 ProdID=0001 Rev= 1.00
      S:  Manufacturer=Bluetooth v2.0
      S:  Product=Bluetooth V2.0 Dongle
      
      T:  Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0a12 ProdID=0001 Rev= 0.07
      
      In case of CSR devices, the bcdDevice revision contains the firmware
      build ID and that is normally a higher value. If the bcdDevice revision
      is 1.0 or less, then an extra setup stage is checking if Read Local
      Version returns CSR manufacturer information. If not then it will be
      assumed that this is a broken device and the Delete Stored Link Key
      command will be marked as broken.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      81cac64b
    • Marcel Holtmann's avatar
      Bluetooth: Add quirk for disabling Delete Stored Link Key command · f9f462fa
      Marcel Holtmann authored
      Some controller pretend they support the Delete Stored Link Key command,
      but in reality they really don't support it.
      
        < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
            bdaddr 00:00:00:00:00:00 all 1
        > HCI Event: Command Complete (0x0e) plen 4
            Delete Stored Link Key (0x03|0x0012) ncmd 1
            status 0x11 deleted 0
            Error: Unsupported Feature or Parameter Value
      
      Not correctly supporting this command causes the controller setup to
      fail and will make a device not work. However sending the command for
      controller that handle stored link keys is important. This quirk
      allows a driver to disable the command if it knows that this command
      handling is broken.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      f9f462fa
  3. 29 Dec, 2013 2 commits
  4. 23 Dec, 2013 1 commit
  5. 17 Dec, 2013 8 commits
  6. 14 Dec, 2013 2 commits
  7. 12 Dec, 2013 3 commits
  8. 11 Dec, 2013 5 commits
  9. 10 Dec, 2013 1 commit
  10. 08 Dec, 2013 1 commit
  11. 07 Dec, 2013 1 commit
  12. 06 Dec, 2013 2 commits
  13. 05 Dec, 2013 6 commits