linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 2/2] Bluetooth: Introduce new HCI socket channel for user operation
Date: Sun, 1 Sep 2013 17:45:44 +0100	[thread overview]
Message-ID: <20130901164544.GI7440@joana> (raw)
In-Reply-To: <1377578452-7316-2-git-send-email-marcel@holtmann.org>

Hi Marcel,

2013-08-26 Marcel Holtmann <marcel@holtmann.org>:

> This patch introcuces a new HCI socket channel that allows user
> applications to take control over a specific HCI device. The application
> gains exclusive access to this device and forces the kernel to stay away
> and not manage it. In case of the management interface it will actually
> hide the device.
> 
> Such operation is useful for security testing tools that need to operate
> underneath the Bluetooth stack and need full control over a device. The
> advantage here is that the kernel still provides the service of hardware
> abstraction and HCI level access. The use of Bluetooth drivers for
> hardware access also means that sniffing tools like btmon or hcidump
> are still working and the whole set of transaction can be traced with
> existing tools.
> 
> With the new channel it is possible to send HCI commands, ACL and SCO
> data packets and receive HCI events, ACL and SCO packets from the
> device. The format follows the well established H:4 protocol.
> 
> The new HCI user channel can only be established when a device has been
> through its setup routine and is currently powered down. This is
> enforced to not cause any problems with current operations. In addition
> only one user channel per HCI device is allowed. It is exclusive access
> for one user application. Access to this channel is limited to process
> with CAP_NET_RAW capability.
> 
> Using this new facility does not require any external library or special
> ioctl or socket filters. Just create the socket and bind it. After that
> the file descriptor is ready to speak H:4 protocol.
> 
>         struct sockaddr_hci addr;
>         int fd;
> 
>         fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
> 
>         memset(&addr, 0, sizeof(addr));
>         addr.hci_family = AF_BLUETOOTH;
>         addr.hci_dev = 0;
>         addr.hci_channel = HCI_CHANNEL_USER;
> 
>         bind(fd, (struct sockaddr *) &addr, sizeof(addr));
> 
> The example shows on how to create a user channel for hci0 device. Error
> handling has been left out of the example. However with the limitations
> mentioned above it is advised to handle errors. Binding of the user
> cahnnel socket can fail for various reasons. Specifically if the device
> is currently activated by BlueZ or if the access permissions are not
> present.
> 
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
>  include/net/bluetooth/hci.h |  1 +
>  net/bluetooth/hci_sock.c    | 86 ++++++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 82 insertions(+), 5 deletions(-)
> 
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 128157d..30c88b5 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -1571,6 +1571,7 @@ struct sockaddr_hci {
>  #define HCI_DEV_NONE	0xffff
>  
>  #define HCI_CHANNEL_RAW		0
> +#define HCI_CHANNEL_USER	1
>  #define HCI_CHANNEL_MONITOR	2
>  #define HCI_CHANNEL_CONTROL	3

Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is
the CONTROL one but it is not. I think we need to redefine this to 4.
I can do this when applying the patch if you are okay with it.

	Gustavo

  reply	other threads:[~2013-09-01 16:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27  4:40 [PATCH 2/2] Bluetooth: Introduce new HCI socket channel for user operation Marcel Holtmann
2013-09-01 16:45 ` Gustavo Padovan [this message]
2013-09-01 17:27   ` Marcel Holtmann
2013-09-01 17:44     ` Gustavo Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130901164544.GI7440@joana \
    --to=gustavo@padovan.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).