* Re: bluetooth kernel to bluez userspace relationship
From: Arun K. Singh @ 2011-02-21 8:04 UTC (permalink / raw)
To: Viswanathan Sankararam; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimbj=p1ecddQsTiun6LUeP8+wPnT0VLCsvsWNRb@mail.gmail.com>
Hi Vish,
> All,
> I'm new to bluetooth so please forgive me for asking this question if
> its already been answered. I understand that the linux kernel has part
> of the bluetooth stack and there is also the rest of it called Bluez
> in userspace which consists of a daemon and library. How would one
> correlate linux kernel version with the bluez userspace version?
> Meaning, how would l know say, linux-2.6.35 would work with
> Bluez-4.68.
>
> Any response would be appreciated.
unless you are looking for a specific feature in bluez-userspace you
must use latest kernel and bluez version. If you are cherry-picking an
old bluez version you need to check recent feature enhancements into
same, which may require a matching kernel version. for example for AMP
manager or Bt 3.0 stuff, you may need an ERTM enabled kernel which
comes only 2.6.35 onwards ...
Even if you intend to use an old Bluez userspace, its always advisable
to pick latest kernel ...else you need to dig ..
> Thanks
> Vish
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Arun K. Singh
www.crazydaks.com
^ permalink raw reply
* Re: [PATCH] work around for l2cap NULL dereference in l2cap_conn_start
From: Liang Bao @ 2011-02-21 6:41 UTC (permalink / raw)
To: David Fries
Cc: Andrei Warkentin, Gustavo F. Padovan, linux-bluetooth,
linux-kernel
In-Reply-To: <20110221043601.GB22204@spacedout.fries.net>
Hi, David, Andrew et al.
2011/2/21 David Fries <david@fries.net>:
> bt_sk(sk)->parent can be NULL in l2cap_conn_start in state BT_CONNECT2
> at least when a headset device pairs and the play button was pressed
> right before pairing.
>
> Signed-off-by: David Fries <david@fries.net>
> ---
> I removed the printk, can this be merged to the bluetooth next tree?
>
> On Mon, Feb 14, 2011 at 03:40:46PM -0600, Andrei Warkentin wrote:
>> FWIW still need it in 2.6.36.
>
> Andrei, I'm curious, what's your hardware hardware and bluetooth
> device that's trigginer the crash?
I once submitted an issue observed with Android+Motorola S305 stereo
headset. It's still open in launchpad:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/513642. Hope this
helps. Thanks.
>
>> On Mon, Feb 14, 2011 at 8:56 AM, Gustavo F. Padovan
>> <padovan@profusion.mobi> wrote:
>> > Hi David,
>> >
>> > * David Fries <david@fries.net> [2011-02-10 21:53:09 -0600]:
>> >
>> >> Here's a patch to avoid a very repeatable crash in the N900. If I
>> >> take a Motorola S305 bluetooth headset that was previously paried with
>> >> the N900, turn it on, and press the play button before the headphones
>> >> automatically pair with the cell phone, the N900 will crash (and
>> >> reboot) in pairing. If I wait until after they have paired there
>> >> isn't any problem. The patch is against the kernel-power
>> >> 2.6.28-maemo46 by Thomas Tanner, the stock Nokia PR1.2 oops looked
>> >> the same, I just haven't gone back to that kernel.
>> >
>> > This is a very old kernel. You need to check this issue against
>> > bluetooth-next-2.6.
>
> net/bluetooth/l2cap.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index ed83c1f..a7aa4d9 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -408,7 +408,8 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
> struct sock *parent = bt_sk(sk)->parent;
> rsp.result = cpu_to_le16(L2CAP_CR_PEND);
> rsp.status = cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
> - parent->sk_data_ready(parent, 0);
> + if(parent)
> + parent->sk_data_ready(parent,0);
>
> } else {
> sk->sk_state = BT_CONFIG;
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] work around for l2cap NULL dereference in l2cap_conn_start
From: David Fries @ 2011-02-21 4:36 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: Gustavo F. Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <AANLkTi==Sh2yc2JjjY5t-NKxQexKPgPwNyWo4SMju92k@mail.gmail.com>
bt_sk(sk)->parent can be NULL in l2cap_conn_start in state BT_CONNECT2
at least when a headset device pairs and the play button was pressed
right before pairing.
Signed-off-by: David Fries <david@fries.net>
---
I removed the printk, can this be merged to the bluetooth next tree?
On Mon, Feb 14, 2011 at 03:40:46PM -0600, Andrei Warkentin wrote:
> FWIW still need it in 2.6.36.
Andrei, I'm curious, what's your hardware hardware and bluetooth
device that's trigginer the crash?
> On Mon, Feb 14, 2011 at 8:56 AM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> > Hi David,
> >
> > * David Fries <david@fries.net> [2011-02-10 21:53:09 -0600]:
> >
> >> Here's a patch to avoid a very repeatable crash in the N900. If I
> >> take a Motorola S305 bluetooth headset that was previously paried with
> >> the N900, turn it on, and press the play button before the headphones
> >> automatically pair with the cell phone, the N900 will crash (and
> >> reboot) in pairing. If I wait until after they have paired there
> >> isn't any problem. The patch is against the kernel-power
> >> 2.6.28-maemo46 by Thomas Tanner, the stock Nokia PR1.2 oops looked
> >> the same, I just haven't gone back to that kernel.
> >
> > This is a very old kernel. You need to check this issue against
> > bluetooth-next-2.6.
net/bluetooth/l2cap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index ed83c1f..a7aa4d9 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -408,7 +408,8 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
struct sock *parent = bt_sk(sk)->parent;
rsp.result = cpu_to_le16(L2CAP_CR_PEND);
rsp.status = cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
- parent->sk_data_ready(parent, 0);
+ if(parent)
+ parent->sk_data_ready(parent,0);
} else {
sk->sk_state = BT_CONFIG;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 2/2] bt hidp: send Output reports using SET_REPORT on the Control channel
From: Alan Ott @ 2011-02-21 3:45 UTC (permalink / raw)
To: Antonio Ospite
Cc: linux-input, linux-bluetooth, Jiri Kosina, Marcel Holtmann,
Gustavo F. Padovan, Bastien Nocera, Jim Paris, pascal@pabr.org
In-Reply-To: <1298222806-19433-3-git-send-email-ospite@studenti.unina.it>
On 02/20/2011 12:26 PM, Antonio Ospite wrote:
> The current implementation of hidp_output_raw_report() relies only on
> the Control channel even for Output reports, and the BT HID
> specification [1] does not mention using the DATA message for Output
> reports on the Control channel (see section 7.9.1 and also Figure 11:
> SET_ Flow Chart), so let us just use SET_REPORT.
>
> This also fixes sending Output reports to some devices (like Sony
> Sixaxis) which are not able to handle DATA messages on the Control
> channel.
>
> Ideally hidp_output_raw_report() could be improved to use this scheme:
> Feature Report -- SET_REPORT on the Control channel
> Output Report -- DATA on the Interrupt channel
> for more efficiency, but as said above, right now only the Control
> channel is used.
>
> [1] http://www.bluetooth.com/Specification%20Documents/HID_SPEC_V10.pdf
>
> case HID_OUTPUT_REPORT:
> - report_type = HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT;
> + report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_OUPUT;
>
I think this is right. Section 7.4[.0] says that SET_ and GET_ requests
return with HANDSHAKE. Section 7.4.9 says that DATA does _not_ return a
HANDSHAKE. My patch to hidp_output_raw_report() relies on getting a
HANDSHAKE back, so it wouldn't have worked with BT devices that take
output reports. Since I don't have any that do, I couldn't test it. (And
it was like that when I got here :) )
For the whole set:
Acked-by: Alan Ott <alan@signal11.us>
Alan.
^ permalink raw reply
* Re: [BUG] usb problems in .38-rc3+
From: Ed Tomlinson @ 2011-02-20 20:49 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-kernel, linux-bluetooth, linux-usb
In-Reply-To: <201102201209.20799.edt@aei.ca>
On Sunday 20 February 2011 12:09:20 Ed Tomlinson wrote:
> On Wednesday 16 February 2011 13:47:27 Gustavo F. Padovan wrote:
> > Hi Ed,
> >
> > * Ed Tomlinson <edt@aei.ca> [2011-02-16 13:38:00 -0500]:
> >
> > > On Wednesday 16 February 2011 09:00:53 Gustavo F. Padovan wrote:
> > > > Hi Ed,
> > > >
> > > > * Ed Tomlinson <edt@aei.ca> [2011-02-05 14:17:57 -0500]:
> > > >
> > > > > Hi,
> > > > >
> > > > > My bluetooth usb dongle has stopped working in .38-rc3+
> > > > >
> > > > > Bus 002 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
> > > > >
> > > > > and in dmesg
> > > > >
> > > > > [108495.369056] usb 5-1: new full speed USB device using ohci_hcd and address 3
> > > > > [108495.573077] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001
> > > > > [108495.580099] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > > > > [108652.971977] usb 5-1: USB disconnect, address 3
> > > > > [108652.972718] btusb_bulk_complete: hci0 urb ffff8800684e99c0 failed to resubmit (19)
> > > > > [108652.973725] btusb_bulk_complete: hci0 urb ffff8800684e9c00 failed to resubmit (19)
> > > > > [108652.974707] btusb_intr_complete: hci0 urb ffff8800684e9840 failed to resubmit (19)
> > > > > [108653.001690] btusb_send_frame: hci0 urb ffff8800bb42a240 submission failed
> > > > > [108657.007541] usb 2-4.7: new full speed USB device using ehci_hcd and address 8
> > > > > [108657.147736] usb 2-4.7: New USB device found, idVendor=0a12, idProduct=0001
> > > > > [108657.154954] usb 2-4.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > > > >
> > > > > Its been working for years here.
> > > > >
> > > > > Any ideas on what to try or additional info to gather?
> > > >
> > > > What's the symptom? what do you mean by stopped to work?
> > >
> > > With .37 kernel my bluetooth apple magicmouse is detected at boot and works as expected & when
> > > kde 4.6 is active bluedevil sees my bluetooth adaptor. With .38-rc my bluetooth mouse is not detected
> > > nor does bluedevil see the bluetooth adaptor.
> > >
> > > > Can you provide me output of "hciconfig -a"?
> > > This gives nothing when the doogle is not plugged (it runs but prints out nothing).
> > >
> > > > And if possible enable dynamic debug for your kernel, mount the debugfs
> > > > and then
> > > >
> > > > echo -n "module btusb +p" > /sys/kernel/debug/dynamic_debug/control
> > > > echo -n "module bluetooth +p" > /sys/kernel/debug/dynamic_debug/control
> > >
> > > Hey a new debug option to enable! With it enabled and the system booted with the bluetooth doogle
> > > unpluged here is what happens when it gets plugged (with 38-rc5):
> > >
> > > grover ed # hciconfig -a
> > > hci0: Type: BR/EDR Bus: USB
> > > BD Address: 00:0A:3A:55:07:5A ACL MTU: 192:8 SCO MTU: 64:8
> > > UP RUNNING
> > > RX bytes:356 acl:0 sco:0 events:13 errors:0
> > > TX bytes:53 acl:0 sco:0 commands:13 errors:0
> > > Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > > Packet type: DM1 DH1 HV1
> > > Link policy:
> > > Link mode: SLAVE ACCEPT
> > > Name: 'grover-0'
> > > Class: 0x000000
> > > Service Classes: Unspecified
> > > Device Class: Miscellaneous,
> > > HCI Version: 1.1 (0x1) Revision: 0x20d
> > > LMP Version: 1.1 (0x1) Subversion: 0x20d
> > > Manufacturer: Cambridge Silicon Radio (10)
> > >
> > > and the device works. So either enabling dynamic debug, something between rc4 and rc5 or booting with the
> > > adaptor unplugged makes things work. Will do some more checking to figure out which.
> >
> > Great that it is working now. It might be a usb bug that you had, because we
> > had no changes in the Bluetooth subsystem between rc4 and rc5.
> >
> > But does booting with the adapter work as well?
>
> I have not been able to get it to work a second time no mater what combo I try - some sort of race I would guess:
>
> Plugged at boot fails
> Plugged after boot fails
> Plugged after, btusb traced fails
> Plugged after, bluetooth traced fails
> Plugged after, both traced fails
Gustavo,
I've figured out how to make things work though I am not sure why it fixes things.
If I power on my bluetooth devices after running an 'hciconifg -a' they work.
I can leave the adapter plugged at boot or plug it after. The important thing seems to
be running the hciconfig before attempting to connect devices. From the manpage
hciconfig -a should just be a query. Instead it seems to initialize something and
makes things work here.
Any idea why?
Ed
^ permalink raw reply
* Re: [PATCH 2/2] Fix Crash where MTU allowed to be set too large
From: Johan Hedberg @ 2011-02-20 18:29 UTC (permalink / raw)
To: Brian Gix; +Cc: linux-bluetooth
In-Reply-To: <1298148343-10535-3-git-send-email-bgix@codeaurora.org>
Hi Brian,
On Sat, Feb 19, 2011, Brian Gix wrote:
> As previously written, a remote device could request, and we would
> accept an MTU larger than what we could support.
> ---
> src/attrib-server.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Both patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] bt hidp: send Output reports using SET_REPORT on the Control channel
From: Antonio Ospite @ 2011-02-20 17:26 UTC (permalink / raw)
To: linux-input
Cc: Antonio Ospite, linux-bluetooth, Jiri Kosina, Marcel Holtmann,
Gustavo F. Padovan, Bastien Nocera, Alan Ott, Jim Paris,
pascal@pabr.org
In-Reply-To: <1298222806-19433-1-git-send-email-ospite@studenti.unina.it>
The current implementation of hidp_output_raw_report() relies only on
the Control channel even for Output reports, and the BT HID
specification [1] does not mention using the DATA message for Output
reports on the Control channel (see section 7.9.1 and also Figure 11:
SET_ Flow Chart), so let us just use SET_REPORT.
This also fixes sending Output reports to some devices (like Sony
Sixaxis) which are not able to handle DATA messages on the Control
channel.
Ideally hidp_output_raw_report() could be improved to use this scheme:
Feature Report -- SET_REPORT on the Control channel
Output Report -- DATA on the Interrupt channel
for more efficiency, but as said above, right now only the Control
channel is used.
[1] http://www.bluetooth.com/Specification%20Documents/HID_SPEC_V10.pdf
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
net/bluetooth/hidp/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 6df8ea1..3c036b0 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -405,7 +405,7 @@ static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, s
report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_FEATURE;
break;
case HID_OUTPUT_REPORT:
- report_type = HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT;
+ report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_OUPUT;
break;
default:
return -EINVAL;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] hid-sony.c: Fix sending Output reports to the Sixaxis
From: Antonio Ospite @ 2011-02-20 17:26 UTC (permalink / raw)
To: linux-input
Cc: Antonio Ospite, linux-bluetooth, Jiri Kosina, Marcel Holtmann,
Gustavo F. Padovan, Bastien Nocera, Alan Ott, Jim Paris,
pascal@pabr.org
In-Reply-To: <1298222806-19433-1-git-send-email-ospite@studenti.unina.it>
The Sixaxis does not want the report_id as part of the data packet in
Output reports, so we have to discard buf[0] when sending the actual
control message.
Add also some documentation about that and about why
hdev->hid_output_raw_report needs to be overridden.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
drivers/hid/hid-sony.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 68d7b36..93819a0 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -46,6 +46,16 @@ static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
return rdesc;
}
+/*
+ * The Sony Sixaxis does not handle HID Output Reports on the Interrupt EP
+ * like it should according to usbhid/hid-core.c::usbhid_output_raw_report()
+ * so we need to override that forcing HID Output Reports on the Control EP.
+ *
+ * There is also another issue about HID Output Reports via USB, the Sixaxis
+ * does not want the report_id as part of the data packet, so we have to
+ * discard buf[0] when sending the actual control message, even for numbered
+ * reports, humpf!
+ */
static int sixaxis_usb_output_raw_report(struct hid_device *hid, __u8 *buf,
size_t count, unsigned char report_type)
{
@@ -55,6 +65,12 @@ static int sixaxis_usb_output_raw_report(struct hid_device *hid, __u8 *buf,
int report_id = buf[0];
int ret;
+ if (report_type == HID_OUTPUT_REPORT) {
+ /* Don't send the Report ID */
+ buf++;
+ count--;
+ }
+
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
HID_REQ_SET_REPORT,
USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
@@ -62,6 +78,10 @@ static int sixaxis_usb_output_raw_report(struct hid_device *hid, __u8 *buf,
interface->desc.bInterfaceNumber, buf, count,
USB_CTRL_SET_TIMEOUT);
+ /* Count also the Report ID, in case of an Output report. */
+ if (ret > 0 && report_type == HID_OUTPUT_REPORT)
+ ret++;
+
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] Fix sending Output reports to the Sony Sixaxis
From: Antonio Ospite @ 2011-02-20 17:26 UTC (permalink / raw)
To: linux-input
Cc: Antonio Ospite, linux-bluetooth, Jiri Kosina, Marcel Holtmann,
Gustavo F. Padovan, Bastien Nocera, Alan Ott, Jim Paris,
pascal@pabr.org
In-Reply-To: <alpine.LNX.2.00.1102180944590.2160@pobox.suse.cz>
Hi,
an Output report is used to set LEDs on the Sony Sixaxis controller, but
the device is quite picky about how it wants the Output report to be
sent, so these patches attempt to overcome the Sixaxis deficiencies.
The first patch is OK to apply, even for 2.6.38 I think.
For the second one I'd really like an actual test with other devices
supporting HID Output reports over BT, I don't want to break anything
even if the change looks sane as per the BT HID specification.
Something equivalent to the second patch should be implemented as an
override in hid-sony.c as well, in order to be protected from future
improvements to hidp_output_raw_report(), but for that to work I need to
make hidp_send_ctrl_message() public and I don't know if you'll like
that, we'll see in a patch to come.
Antonio Ospite (2):
hid-sony.c: Fix sending Output reports to the Sixaxis
bt hidp: send Output reports using SET_REPORT on the Control channel
drivers/hid/hid-sony.c | 20 ++++++++++++++++++++
net/bluetooth/hidp/core.c | 2 +-
2 files changed, 21 insertions(+), 1 deletions(-)
FYI, this is how I am setting leds on the Sixaxis, the same code works
with hidraw via usb and bluetooth after the patches above are applied:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#define LED_1 (0x01 << 1)
#define LED_2 (0x01 << 2)
#define LED_3 (0x01 << 3)
#define LED_4 (0x01 << 4)
void set_leds(int fd, unsigned char led_status[4])
{
int ret;
unsigned char change_leds[] = {
0x01,
0x00, 0x00, 0x00, 0x00, 0x00, // rumble values TBD.
0x00, 0x00, 0x00, 0x00, 0x1e,
0xff, 0x27, 0x10, 0x00, 0x32, // LED 4
0xff, 0x27, 0x10, 0x00, 0x32, // LED 3
0xff, 0x27, 0x10, 0x00, 0x32, // LED 2
0xff, 0x27, 0x10, 0x00, 0x32, // LED 1
0x00, 0x00, 0x00, 0x00, 0x00,
};
int led = 0;
if (led_status[0])
led |= LED_1;
if (led_status[1])
led |= LED_2;
if (led_status[2])
led |= LED_3;
if (led_status[3])
led |= LED_4;
printf("led: 0x%02x\n", led);
change_leds[10] = led;
ret = write(fd, change_leds, sizeof(change_leds));
if (ret < (ssize_t) sizeof(change_leds)) {
close(fd);
perror("Unable to write to hidraw device");
exit(EXIT_FAILURE);
}
}
int main(int argc, char *argv[])
{
int fd;
unsigned char led_status[4] = { 1, 0, 0, 0 };
if (argc != 2) {
fprintf(stderr, "usage: %s </dev/hidrawX>\n", argv[0]);
exit(1);
}
fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
exit(1);
}
set_leds(fd, led_status);
return 0;
}
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* bluetooth kernel to bluez userspace relationship
From: Viswanathan Sankararam @ 2011-02-20 15:26 UTC (permalink / raw)
To: linux-bluetooth
All,
I'm new to bluetooth so please forgive me for asking this question if
its already been answered. I understand that the linux kernel has part
of the bluetooth stack and there is also the rest of it called Bluez
in userspace which consists of a daemon and library. How would one
correlate linux kernel version with the bluez userspace version?
Meaning, how would l know say, linux-2.6.35 would work with
Bluez-4.68.
Any response would be appreciated.
Thanks
Vish
^ permalink raw reply
* [PATCH 2/2] Fix Crash where MTU allowed to be set too large
From: Brian Gix @ 2011-02-19 20:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Brian Gix
In-Reply-To: <1298148343-10535-1-git-send-email-bgix@codeaurora.org>
As previously written, a remote device could request, and we would
accept an MTU larger than what we could support.
---
src/attrib-server.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 6966ad0..4285f6e 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -639,7 +639,7 @@ static uint16_t write_value(struct gatt_channel *channel, uint16_t handle,
static uint16_t mtu_exchange(struct gatt_channel *channel, uint16_t mtu,
uint8_t *pdu, int len)
{
- channel->mtu = MIN(mtu, ATT_MAX_MTU);
+ channel->mtu = MIN(mtu, channel->mtu);
return enc_mtu_resp(channel->mtu, pdu, len);
}
--
1.7.1
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* [PATCH 1/2] Add missing UUID16 field to Included Svc Attribute
From: Brian Gix @ 2011-02-19 20:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Brian Gix
In-Reply-To: <1298148343-10535-1-git-send-email-bgix@codeaurora.org>
---
attrib/example.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/attrib/example.c b/attrib/example.c
index cd18168..395650a 100644
--- a/attrib/example.c
+++ b/attrib/example.c
@@ -124,7 +124,8 @@ static int register_attributes(void)
/* Thermometer: Include */
att_put_u16(0x0550, &atval[0]);
att_put_u16(0x0568, &atval[2]);
- attrib_db_add(0x0202, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 4);
+ att_put_u16(VENDOR_SPECIFIC_SVC_UUID, &atval[4]);
+ attrib_db_add(0x0202, &uuid, ATT_NONE, ATT_NOT_PERMITTED, atval, 6);
/* Thermometer: temperature characteristic */
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
--
1.7.1
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* [PATCH 0/2] Minor bug fixes from UPF38
From: Brian Gix @ 2011-02-19 20:45 UTC (permalink / raw)
To: linux-bluetooth
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC v2 00/14] Store UUID-128 on host order
From: Luiz Augusto von Dentz @ 2011-02-19 18:07 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1298068173-16518-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Sat, Feb 19, 2011 at 12:29 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> It must NOT be included in the next release until proper testing.
>
> Any good soul wants to test it if I am not breaking SDP?
>
> The following patches convert the internal UUID128 values representation
> to host order. Currently, SDP functions use host order to store UUID-16
> /UUID32 and network order to store UUID-128 values. The reason is to
> keep the consistency and re-use the UUID functions for ATT protocol
> which uses little endian.
>
> Changes from the first RFC:
> - Changes sdptool
> - Changes SDP XML parsing function
> - Changes attribute example
>
> Claudio Takahasi (14):
> Move 64 and 128 bits byte order functions to bluetooth.h
> Use host byte order when converting UUID16/32 to UUID128
> Add att_get_u128
> Convert UUID128 value to host order when extracting SDP data
> Convert to network order before use it on sdp_uuid128_to_uuid
> Convert from host to network order before to print UUID128 values
> Convert from network to host order on bt_string2uuid function
> Change UUID128 host order on SDP PDU generation function
> Replace UUID128 values from char array to uint128_t on sdptool
> Create UUID128 on host order on sdptool
> Change SDP XML parser to create UUID128 values on host order
> Convert from little endian to host order when parsing EIR data
> Add att_put_u128
> Change Attribute example to create UUID128 on host order
>
> attrib/att.c | 16 ++++--
> attrib/att.h | 17 ++++++
> attrib/example.c | 24 +++++---
> attrib/gatt.c | 14 +++--
> attrib/gatttool.c | 6 ++-
> attrib/interactive.c | 1 +
> health/hdp_manager.c | 1 +
> health/mcap_sync.c | 17 ------
> lib/bluetooth.h | 41 ++++++++++++++
> lib/sdp.c | 108 ++++++++++++++-----------------------
> lib/sdp.h | 4 --
> src/event.c | 6 +--
> src/glib-helper.c | 31 ++++++-----
> src/sdp-xml.c | 74 +++++++++++--------------
> test/hciemu.c | 16 ------
> tools/sdptool.c | 145 ++++++++++++++++++++++++++++++-------------------
> 16 files changed, 280 insertions(+), 241 deletions(-)
>
> --
> 1.7.4.1
IMO it would be easier to have specific functions for uuid128 that can
take data in host order, so that we don't break existing API. Note
that the internal representation could be changed to host order, that
is fine, but then you convert the existing function to do the
conversion internally without breaking compatibility.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 2/2] Fix bugs found at UPF38 - Las Vegas
From: Johan Hedberg @ 2011-02-19 15:18 UTC (permalink / raw)
To: Brian Gix; +Cc: linux-bluetooth, padovan, anderson.lizardo
In-Reply-To: <1298072261-7232-3-git-send-email-bgix@codeaurora.org>
Hi Brian,
On Fri, Feb 18, 2011, Brian Gix wrote:
> Example Included Service Attribute missing UUID16 field.
> MTU Exchange not bounded by actual size required not to crash.
> ---
> attrib/example.c | 3 ++-
> src/attrib-server.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
Even though these are some quite trivial changes, you essentially have
to independent fixes here and they should therefore be in two separate
patches. Also make sure that the summary line of each patch gives at
least some idea of what is being fixed. The way you formulated it now
just tells us that "something" found at UPF38 was fixed.
Johan
P.S. I think you can stop adding extra people to CC in your patch
submissions. --to linux-bluetooth@vger.kernel.org should be enough.
^ permalink raw reply
* Re: [PATCH 1/2] Add SDP registration of Primary GATT services
From: Johan Hedberg @ 2011-02-19 15:14 UTC (permalink / raw)
To: Brian Gix; +Cc: linux-bluetooth, padovan, anderson.lizardo
In-Reply-To: <1298072261-7232-2-git-send-email-bgix@codeaurora.org>
Hi Brian,
On Fri, Feb 18, 2011, Brian Gix wrote:
> Add capability to register SDP record for Primary Services.
> ---
> attrib/example.c | 24 ++++++++
> src/attrib-server.c | 157 +++++++++++++++++++++++++++++++++++++++------------
> src/attrib-server.h | 3 +-
> 3 files changed, 147 insertions(+), 37 deletions(-)
This patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 8/8] Bluetooth: Fix unnecessary list traversal in mgmt_pending_remove
From: johan.hedberg @ 2011-02-19 15:06 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
All of the places that need to call mgmt_pending_remove already have a
pointer to the pending command, so searching for the command in the list
doesn't make sense. The added benefit is that many places that
previously had to call list_del + mgmt_pending_free can just call
mgmt_pending_remove now.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/mgmt.c | 42 ++++++++++++++----------------------------
1 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 46e2c39..982becd 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -290,14 +290,8 @@ static struct pending_cmd *mgmt_pending_find(u16 opcode, int index)
return NULL;
}
-static void mgmt_pending_remove(u16 opcode, int index)
+static void mgmt_pending_remove(struct pending_cmd *cmd)
{
- struct pending_cmd *cmd;
-
- cmd = mgmt_pending_find(opcode, index);
- if (cmd == NULL)
- return;
-
list_del(&cmd->list);
mgmt_pending_free(cmd);
}
@@ -401,7 +395,7 @@ static int set_discoverable(struct sock *sk, unsigned char *data, u16 len)
err = hci_send_cmd(hdev, HCI_OP_WRITE_SCAN_ENABLE, 1, &scan);
if (err < 0)
- mgmt_pending_remove(MGMT_OP_SET_DISCOVERABLE, dev_id);
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -459,7 +453,7 @@ static int set_connectable(struct sock *sk, unsigned char *data, u16 len)
err = hci_send_cmd(hdev, HCI_OP_WRITE_SCAN_ENABLE, 1, &scan);
if (err < 0)
- mgmt_pending_remove(MGMT_OP_SET_CONNECTABLE, dev_id);
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -881,7 +875,7 @@ static int disconnect(struct sock *sk, unsigned char *data, u16 len)
err = hci_send_cmd(hdev, HCI_OP_DISCONNECT, sizeof(dc), &dc);
if (err < 0)
- mgmt_pending_remove(MGMT_OP_DISCONNECT, dev_id);
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -983,7 +977,7 @@ static int pin_code_reply(struct sock *sk, unsigned char *data, u16 len)
err = hci_send_cmd(hdev, HCI_OP_PIN_CODE_REPLY, sizeof(reply), &reply);
if (err < 0)
- mgmt_pending_remove(MGMT_OP_PIN_CODE_REPLY, dev_id);
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -1026,7 +1020,7 @@ static int pin_code_neg_reply(struct sock *sk, unsigned char *data, u16 len)
err = hci_send_cmd(hdev, HCI_OP_PIN_CODE_NEG_REPLY, sizeof(bdaddr_t),
&cp->bdaddr);
if (err < 0)
- mgmt_pending_remove(MGMT_OP_PIN_CODE_NEG_REPLY, dev_id);
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -1107,8 +1101,7 @@ static void pairing_complete(struct pending_cmd *cmd, u8 status)
hci_conn_put(conn);
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
}
static void pairing_complete_cb(struct hci_conn *conn, u8 status)
@@ -1230,10 +1223,8 @@ static int user_confirm_reply(struct sock *sk, unsigned char *data, u16 len,
}
err = hci_send_cmd(hdev, hci_op, sizeof(cp->bdaddr), &cp->bdaddr);
- if (err < 0) {
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
- }
+ if (err < 0)
+ mgmt_pending_remove(cmd);
failed:
hci_dev_unlock_bh(hdev);
@@ -1494,8 +1485,7 @@ static void disconnect_rsp(struct pending_cmd *cmd, void *data)
*sk = cmd->sk;
sock_hold(*sk);
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
}
int mgmt_disconnected(u16 index, bdaddr_t *bdaddr)
@@ -1528,8 +1518,7 @@ int mgmt_disconnect_failed(u16 index)
err = cmd_status(cmd->sk, MGMT_OP_DISCONNECT, EIO);
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
return err;
}
@@ -1571,8 +1560,7 @@ int mgmt_pin_code_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_REPLY, &rp, sizeof(rp));
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
return err;
}
@@ -1594,8 +1582,7 @@ int mgmt_pin_code_neg_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_NEG_REPLY,
&rp, sizeof(rp));
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
return err;
}
@@ -1629,8 +1616,7 @@ static int confirm_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status,
rp.status = status;
err = cmd_complete(cmd->sk, opcode, &rp, sizeof(rp));
- list_del(&cmd->list);
- mgmt_pending_free(cmd);
+ mgmt_pending_remove(cmd);
return err;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 7/8] Bluetooth: Fix inititial value for remote authentication requirements
From: johan.hedberg @ 2011-02-19 15:06 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
The remote authentication requirements for conections need to be
initialized to 0xff (unknown) since it is possible that we receive a IO
Capability Request before we have received information about the remote
requirements.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/hci_conn.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index a050a69..6d8b988 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -286,6 +286,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->state = BT_OPEN;
conn->auth_type = HCI_AT_GENERAL_BONDING;
conn->io_capability = hdev->io_capability;
+ conn->remote_auth = 0xff;
conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 6/8] Bluetooth: Add mgmt_auth_failed event
From: johan.hedberg @ 2011-02-19 15:06 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
To properly track bonding completion an event to indicate authentication
failure is needed. This event will be sent whenever an authentication
complete HCI event with a non-zero status comes. It will also be sent
when we're acting in acceptor role for SSP authentication in which case
the controller will send a Simple Pairing Complete event.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
include/net/bluetooth/hci_core.h | 1 +
include/net/bluetooth/mgmt.h | 7 +++++++
net/bluetooth/hci_event.c | 19 ++++++++++++++++---
net/bluetooth/mgmt.c | 11 +++++++++++
4 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 05f4706..441dadb 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -766,6 +766,7 @@ int mgmt_user_confirm_request(u16 index, bdaddr_t *bdaddr, __le32 value);
int mgmt_user_confirm_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status);
int mgmt_user_confirm_neg_reply_complete(u16 index, bdaddr_t *bdaddr,
u8 status);
+int mgmt_auth_failed(u16 index, bdaddr_t *bdaddr, u8 status);
/* HCI info for socket */
#define hci_pi(sk) ((struct hci_pinfo *) sk)
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 5aee200..1e63c31 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -264,3 +264,10 @@ struct mgmt_ev_user_confirm_request {
bdaddr_t bdaddr;
__le32 value;
} __packed;
+
+#define MGMT_EV_AUTH_FAILED 0x0010
+struct mgmt_ev_auth_failed {
+ __le16 index;
+ bdaddr_t bdaddr;
+ __u8 status;
+} __packed;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 604c7b5..3fbfa50 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1424,8 +1424,10 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
if (!ev->status) {
conn->link_mode |= HCI_LM_AUTH;
conn->sec_level = conn->pending_sec_level;
- } else
+ } else {
+ mgmt_auth_failed(hdev->id, &conn->dst, ev->status);
conn->sec_level = BT_SECURITY_LOW;
+ }
clear_bit(HCI_CONN_AUTH_PEND, &conn->pend);
@@ -2418,9 +2420,20 @@ static inline void hci_simple_pair_complete_evt(struct hci_dev *hdev, struct sk_
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
- if (conn)
- hci_conn_put(conn);
+ if (!conn)
+ goto unlock;
+
+ /* To avoid duplicate auth_failed events to user space we check
+ * the HCI_CONN_AUTH_PEND flag which will be set if we
+ * initiated the authentication. A traditional auth_complete
+ * event gets always produced as initiator and is also mapped to
+ * the mgmt_auth_failed event */
+ if (!test_bit(HCI_CONN_AUTH_PEND, &conn->pend) && ev->status != 0)
+ mgmt_auth_failed(hdev->id, &conn->dst, ev->status);
+ hci_conn_put(conn);
+
+unlock:
hci_dev_unlock(hdev);
}
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 0d3d613..46e2c39 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1647,3 +1647,14 @@ int mgmt_user_confirm_neg_reply_complete(u16 index, bdaddr_t *bdaddr,
return confirm_reply_complete(index, bdaddr, status,
MGMT_OP_USER_CONFIRM_NEG_REPLY);
}
+
+int mgmt_auth_failed(u16 index, bdaddr_t *bdaddr, u8 status)
+{
+ struct mgmt_ev_auth_failed ev;
+
+ put_unaligned_le16(index, &ev.index);
+ bacpy(&ev.bdaddr, bdaddr);
+ ev.status = status;
+
+ return mgmt_event(MGMT_EV_AUTH_FAILED, &ev, sizeof(ev), NULL);
+}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/8] Bluetooth: Fix mgmt_pin_code_reply return parameters
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
The command complete event for mgmt_pin_code_reply &
mgmt_pin_code_neg_reply should have the adapter index, Bluetooth address
as well as the status.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
include/net/bluetooth/mgmt.h | 5 +++++
net/bluetooth/mgmt.c | 23 +++++++++++++----------
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 52376a3..5aee200 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -147,6 +147,11 @@ struct mgmt_cp_pin_code_reply {
__u8 pin_len;
__u8 pin_code[16];
} __packed;
+struct mgmt_rp_pin_code_reply {
+ __le16 index;
+ bdaddr_t bdaddr;
+ uint8_t status;
+} __packed;
#define MGMT_OP_PIN_CODE_NEG_REPLY 0x0012
struct mgmt_cp_pin_code_neg_reply {
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index d1d9b8c..0d3d613 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1558,17 +1558,18 @@ int mgmt_pin_code_request(u16 index, bdaddr_t *bdaddr)
int mgmt_pin_code_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
{
struct pending_cmd *cmd;
+ struct mgmt_rp_pin_code_reply rp;
int err;
cmd = mgmt_pending_find(MGMT_OP_PIN_CODE_REPLY, index);
if (!cmd)
return -ENOENT;
- if (status != 0)
- err = cmd_status(cmd->sk, MGMT_OP_PIN_CODE_REPLY, status);
- else
- err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_REPLY,
- bdaddr, sizeof(*bdaddr));
+ put_unaligned_le16(index, &rp.index);
+ bacpy(&rp.bdaddr, bdaddr);
+ rp.status = status;
+
+ err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_REPLY, &rp, sizeof(rp));
list_del(&cmd->list);
mgmt_pending_free(cmd);
@@ -1579,17 +1580,19 @@ int mgmt_pin_code_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
int mgmt_pin_code_neg_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
{
struct pending_cmd *cmd;
+ struct mgmt_rp_pin_code_reply rp;
int err;
cmd = mgmt_pending_find(MGMT_OP_PIN_CODE_NEG_REPLY, index);
if (!cmd)
return -ENOENT;
- if (status != 0)
- err = cmd_status(cmd->sk, MGMT_OP_PIN_CODE_NEG_REPLY, status);
- else
- err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_NEG_REPLY,
- bdaddr, sizeof(*bdaddr));
+ put_unaligned_le16(index, &rp.index);
+ bacpy(&rp.bdaddr, bdaddr);
+ rp.status = status;
+
+ err = cmd_complete(cmd->sk, MGMT_OP_PIN_CODE_NEG_REPLY,
+ &rp, sizeof(rp));
list_del(&cmd->list);
mgmt_pending_free(cmd);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/8] Bluetooth: Fix mgmt_pin_code_reply command status opcode
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
The opcode for the ENODEV case was wrong (probably copy-paste mistake).
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/mgmt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index fdcc974..d1d9b8c 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -962,7 +962,7 @@ static int pin_code_reply(struct sock *sk, unsigned char *data, u16 len)
hdev = hci_dev_get(dev_id);
if (!hdev)
- return cmd_status(sk, MGMT_OP_DISCONNECT, ENODEV);
+ return cmd_status(sk, MGMT_OP_PIN_CODE_REPLY, ENODEV);
hci_dev_lock_bh(hdev);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/8] Bluetooth: Add management support for user confirmation request
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
This patch adds support for the user confirmation (numeric comparison)
Secure Simple Pairing authentication method.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
include/net/bluetooth/hci.h | 17 ++++++
include/net/bluetooth/hci_core.h | 4 ++
include/net/bluetooth/mgmt.h | 20 +++++++
net/bluetooth/hci_event.c | 50 ++++++++++++++++++
net/bluetooth/mgmt.c | 103 ++++++++++++++++++++++++++++++++++++++
5 files changed, 194 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index a5f8c46..ec6acf2 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -415,6 +415,17 @@ struct hci_cp_io_capability_reply {
__u8 authentication;
} __packed;
+#define HCI_OP_USER_CONFIRM_REPLY 0x042c
+struct hci_cp_user_confirm_reply {
+ bdaddr_t bdaddr;
+} __packed;
+struct hci_rp_user_confirm_reply {
+ __u8 status;
+ bdaddr_t bdaddr;
+} __packed;
+
+#define HCI_OP_USER_CONFIRM_NEG_REPLY 0x042d
+
#define HCI_OP_IO_CAPABILITY_NEG_REPLY 0x0434
struct hci_cp_io_capability_neg_reply {
bdaddr_t bdaddr;
@@ -936,6 +947,12 @@ struct hci_ev_io_capa_reply {
__u8 authentication;
} __packed;
+#define HCI_EV_USER_CONFIRM_REQUEST 0x33
+struct hci_ev_user_confirm_req {
+ bdaddr_t bdaddr;
+ __le32 passkey;
+} __packed;
+
#define HCI_EV_SIMPLE_PAIR_COMPLETE 0x36
struct hci_ev_simple_pair_complete {
__u8 status;
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 506f250..05f4706 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -762,6 +762,10 @@ int mgmt_connect_failed(u16 index, bdaddr_t *bdaddr, u8 status);
int mgmt_pin_code_request(u16 index, bdaddr_t *bdaddr);
int mgmt_pin_code_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status);
int mgmt_pin_code_neg_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status);
+int mgmt_user_confirm_request(u16 index, bdaddr_t *bdaddr, __le32 value);
+int mgmt_user_confirm_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status);
+int mgmt_user_confirm_neg_reply_complete(u16 index, bdaddr_t *bdaddr,
+ u8 status);
/* HCI info for socket */
#define hci_pi(sk) ((struct hci_pinfo *) sk)
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 1d25c59..52376a3 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -172,6 +172,19 @@ struct mgmt_rp_pair_device {
__u8 status;
} __packed;
+#define MGMT_OP_USER_CONFIRM_REPLY 0x0015
+struct mgmt_cp_user_confirm_reply {
+ __le16 index;
+ bdaddr_t bdaddr;
+} __packed;
+struct mgmt_rp_user_confirm_reply {
+ __le16 index;
+ bdaddr_t bdaddr;
+ __u8 status;
+} __packed;
+
+#define MGMT_OP_USER_CONFIRM_NEG_REPLY 0x0016
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
__le16 opcode;
@@ -239,3 +252,10 @@ struct mgmt_ev_pin_code_request {
__le16 index;
bdaddr_t bdaddr;
} __packed;
+
+#define MGMT_EV_USER_CONFIRM_REQUEST 0x000F
+struct mgmt_ev_user_confirm_request {
+ __le16 index;
+ bdaddr_t bdaddr;
+ __le32 value;
+} __packed;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 98b5764..604c7b5 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -796,6 +796,29 @@ static void hci_cc_le_read_buffer_size(struct hci_dev *hdev,
hci_req_complete(hdev, HCI_OP_LE_READ_BUFFER_SIZE, rp->status);
}
+static void hci_cc_user_confirm_reply(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_rp_user_confirm_reply *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%x", hdev->name, rp->status);
+
+ if (test_bit(HCI_MGMT, &hdev->flags))
+ mgmt_user_confirm_reply_complete(hdev->id, &rp->bdaddr,
+ rp->status);
+}
+
+static void hci_cc_user_confirm_neg_reply(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_user_confirm_reply *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%x", hdev->name, rp->status);
+
+ if (test_bit(HCI_MGMT, &hdev->flags))
+ mgmt_user_confirm_neg_reply_complete(hdev->id, &rp->bdaddr,
+ rp->status);
+}
+
static inline void hci_cs_inquiry(struct hci_dev *hdev, __u8 status)
{
BT_DBG("%s status 0x%x", hdev->name, status);
@@ -1728,6 +1751,14 @@ static inline void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *sk
hci_cc_le_read_buffer_size(hdev, skb);
break;
+ case HCI_OP_USER_CONFIRM_REPLY:
+ hci_cc_user_confirm_reply(hdev, skb);
+ break;
+
+ case HCI_OP_USER_CONFIRM_NEG_REPLY:
+ hci_cc_user_confirm_neg_reply(hdev, skb);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
@@ -2362,6 +2393,21 @@ unlock:
hci_dev_unlock(hdev);
}
+static inline void hci_user_confirm_request_evt(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_ev_user_confirm_req *ev = (void *) skb->data;
+
+ BT_DBG("%s", hdev->name);
+
+ hci_dev_lock(hdev);
+
+ if (test_bit(HCI_MGMT, &hdev->flags))
+ mgmt_user_confirm_request(hdev->id, &ev->bdaddr, ev->passkey);
+
+ hci_dev_unlock(hdev);
+}
+
static inline void hci_simple_pair_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_ev_simple_pair_complete *ev = (void *) skb->data;
@@ -2580,6 +2626,10 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
hci_io_capa_reply_evt(hdev, skb);
break;
+ case HCI_EV_USER_CONFIRM_REQUEST:
+ hci_user_confirm_request_evt(hdev, skb);
+ break;
+
case HCI_EV_SIMPLE_PAIR_COMPLETE:
hci_simple_pair_complete_evt(hdev, skb);
break;
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index d7fc54d..fdcc974 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1193,6 +1193,55 @@ unlock:
return err;
}
+static int user_confirm_reply(struct sock *sk, unsigned char *data, u16 len,
+ int success)
+{
+ struct mgmt_cp_user_confirm_reply *cp = (void *) data;
+ u16 dev_id, mgmt_op, hci_op;
+ struct pending_cmd *cmd;
+ struct hci_dev *hdev;
+ int err;
+
+ BT_DBG("");
+
+ dev_id = get_unaligned_le16(&cp->index);
+
+ if (success) {
+ mgmt_op = MGMT_OP_USER_CONFIRM_REPLY;
+ hci_op = HCI_OP_USER_CONFIRM_REPLY;
+ } else {
+ mgmt_op = MGMT_OP_USER_CONFIRM_NEG_REPLY;
+ hci_op = HCI_OP_USER_CONFIRM_NEG_REPLY;
+ }
+
+ hdev = hci_dev_get(dev_id);
+ if (!hdev)
+ return cmd_status(sk, mgmt_op, ENODEV);
+
+ if (!test_bit(HCI_UP, &hdev->flags)) {
+ err = cmd_status(sk, mgmt_op, ENETDOWN);
+ goto failed;
+ }
+
+ cmd = mgmt_pending_add(sk, mgmt_op, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
+ goto failed;
+ }
+
+ err = hci_send_cmd(hdev, hci_op, sizeof(cp->bdaddr), &cp->bdaddr);
+ if (err < 0) {
+ list_del(&cmd->list);
+ mgmt_pending_free(cmd);
+ }
+
+failed:
+ hci_dev_unlock_bh(hdev);
+ hci_dev_put(hdev);
+
+ return err;
+}
+
int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
{
unsigned char *buf;
@@ -1281,6 +1330,12 @@ int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
case MGMT_OP_PAIR_DEVICE:
err = pair_device(sk, buf + sizeof(*hdr), len);
break;
+ case MGMT_OP_USER_CONFIRM_REPLY:
+ err = user_confirm_reply(sk, buf + sizeof(*hdr), len, 1);
+ break;
+ case MGMT_OP_USER_CONFIRM_NEG_REPLY:
+ err = user_confirm_reply(sk, buf + sizeof(*hdr), len, 0);
+ break;
default:
BT_DBG("Unknown op %u", opcode);
err = cmd_status(sk, opcode, 0x01);
@@ -1541,3 +1596,51 @@ int mgmt_pin_code_neg_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
return err;
}
+
+int mgmt_user_confirm_request(u16 index, bdaddr_t *bdaddr, __le32 value)
+{
+ struct mgmt_ev_user_confirm_request ev;
+
+ BT_DBG("hci%u", index);
+
+ put_unaligned_le16(index, &ev.index);
+ bacpy(&ev.bdaddr, bdaddr);
+ put_unaligned_le32(value, &ev.value);
+
+ return mgmt_event(MGMT_EV_USER_CONFIRM_REQUEST, &ev, sizeof(ev), NULL);
+}
+
+static int confirm_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status,
+ u8 opcode)
+{
+ struct pending_cmd *cmd;
+ struct mgmt_rp_user_confirm_reply rp;
+ int err;
+
+ cmd = mgmt_pending_find(opcode, index);
+ if (!cmd)
+ return -ENOENT;
+
+ put_unaligned_le16(index, &rp.index);
+ bacpy(&rp.bdaddr, bdaddr);
+ rp.status = status;
+ err = cmd_complete(cmd->sk, opcode, &rp, sizeof(rp));
+
+ list_del(&cmd->list);
+ mgmt_pending_free(cmd);
+
+ return err;
+}
+
+int mgmt_user_confirm_reply_complete(u16 index, bdaddr_t *bdaddr, u8 status)
+{
+ return confirm_reply_complete(index, bdaddr, status,
+ MGMT_OP_USER_CONFIRM_REPLY);
+}
+
+int mgmt_user_confirm_neg_reply_complete(u16 index, bdaddr_t *bdaddr,
+ u8 status)
+{
+ return confirm_reply_complete(index, bdaddr, status,
+ MGMT_OP_USER_CONFIRM_NEG_REPLY);
+}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/8] Bluetooth: Add mgmt_pair_device command
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
This patch adds a new mgmt_pair_device which can be used to initiate a
dedicated bonding procedure. Some extra callbacks are added to the
hci_conn struct so that the pairing code can get notified of the
completion of the procedure.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
include/net/bluetooth/hci_core.h | 16 +++++
include/net/bluetooth/mgmt.h | 12 ++++
net/bluetooth/mgmt.c | 133 ++++++++++++++++++++++++++++++++++++++
3 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index d5d8454..506f250 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -248,6 +248,10 @@ struct hci_conn {
void *priv;
struct hci_conn *link;
+
+ void (*connect_cfm_cb) (struct hci_conn *conn, u8 status);
+ void (*security_cfm_cb) (struct hci_conn *conn, u8 status);
+ void (*disconn_cfm_cb) (struct hci_conn *conn, u8 reason);
};
extern struct hci_proto *hci_proto[];
@@ -571,6 +575,9 @@ static inline void hci_proto_connect_cfm(struct hci_conn *conn, __u8 status)
hp = hci_proto[HCI_PROTO_SCO];
if (hp && hp->connect_cfm)
hp->connect_cfm(conn, status);
+
+ if (conn->connect_cfm_cb)
+ conn->connect_cfm_cb(conn, status);
}
static inline int hci_proto_disconn_ind(struct hci_conn *conn)
@@ -600,6 +607,9 @@ static inline void hci_proto_disconn_cfm(struct hci_conn *conn, __u8 reason)
hp = hci_proto[HCI_PROTO_SCO];
if (hp && hp->disconn_cfm)
hp->disconn_cfm(conn, reason);
+
+ if (conn->disconn_cfm_cb)
+ conn->disconn_cfm_cb(conn, reason);
}
static inline void hci_proto_auth_cfm(struct hci_conn *conn, __u8 status)
@@ -619,6 +629,9 @@ static inline void hci_proto_auth_cfm(struct hci_conn *conn, __u8 status)
hp = hci_proto[HCI_PROTO_SCO];
if (hp && hp->security_cfm)
hp->security_cfm(conn, status, encrypt);
+
+ if (conn->security_cfm_cb)
+ conn->security_cfm_cb(conn, status);
}
static inline void hci_proto_encrypt_cfm(struct hci_conn *conn, __u8 status, __u8 encrypt)
@@ -632,6 +645,9 @@ static inline void hci_proto_encrypt_cfm(struct hci_conn *conn, __u8 status, __u
hp = hci_proto[HCI_PROTO_SCO];
if (hp && hp->security_cfm)
hp->security_cfm(conn, status, encrypt);
+
+ if (conn->security_cfm_cb)
+ conn->security_cfm_cb(conn, status);
}
int hci_register_proto(struct hci_proto *hproto);
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 44ac55c..1d25c59 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -160,6 +160,18 @@ struct mgmt_cp_set_io_capability {
__u8 io_capability;
} __packed;
+#define MGMT_OP_PAIR_DEVICE 0x0014
+struct mgmt_cp_pair_device {
+ __le16 index;
+ bdaddr_t bdaddr;
+ __u8 io_cap;
+} __packed;
+struct mgmt_rp_pair_device {
+ __le16 index;
+ bdaddr_t bdaddr;
+ __u8 status;
+} __packed;
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
__le16 opcode;
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 52e5f88..d7fc54d 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -38,6 +38,7 @@ struct pending_cmd {
int index;
void *cmd;
struct sock *sk;
+ void *user_data;
};
LIST_HEAD(cmd_list);
@@ -1063,6 +1064,135 @@ static int set_io_capability(struct sock *sk, unsigned char *data, u16 len)
&dev_id, sizeof(dev_id));
}
+static inline struct pending_cmd *find_pairing(struct hci_conn *conn)
+{
+ struct hci_dev *hdev = conn->hdev;
+ struct list_head *p;
+
+ list_for_each(p, &cmd_list) {
+ struct pending_cmd *cmd;
+
+ cmd = list_entry(p, struct pending_cmd, list);
+
+ if (cmd->opcode != MGMT_OP_PAIR_DEVICE)
+ continue;
+
+ if (cmd->index != hdev->id)
+ continue;
+
+ if (cmd->user_data != conn)
+ continue;
+
+ return cmd;
+ }
+
+ return NULL;
+}
+
+static void pairing_complete(struct pending_cmd *cmd, u8 status)
+{
+ struct mgmt_rp_pair_device rp;
+ struct hci_conn *conn = cmd->user_data;
+
+ rp.index = cmd->index;
+ bacpy(&rp.bdaddr, &conn->dst);
+ rp.status = status;
+
+ cmd_complete(cmd->sk, MGMT_OP_PAIR_DEVICE, &rp, sizeof(rp));
+
+ /* So we don't get further callbacks for this connection */
+ conn->connect_cfm_cb = NULL;
+ conn->security_cfm_cb = NULL;
+ conn->disconn_cfm_cb = NULL;
+
+ hci_conn_put(conn);
+
+ list_del(&cmd->list);
+ mgmt_pending_free(cmd);
+}
+
+static void pairing_complete_cb(struct hci_conn *conn, u8 status)
+{
+ struct pending_cmd *cmd;
+
+ BT_DBG("status %u", status);
+
+ cmd = find_pairing(conn);
+ if (!cmd) {
+ BT_DBG("Unable to find a pending command");
+ return;
+ }
+
+ pairing_complete(cmd, status);
+}
+
+static int pair_device(struct sock *sk, unsigned char *data, u16 len)
+{
+ struct hci_dev *hdev;
+ struct mgmt_cp_pair_device *cp;
+ struct pending_cmd *cmd;
+ u8 sec_level, auth_type;
+ struct hci_conn *conn;
+ u16 dev_id;
+ int err;
+
+ BT_DBG("");
+
+ cp = (void *) data;
+ dev_id = get_unaligned_le16(&cp->index);
+
+ hdev = hci_dev_get(dev_id);
+ if (!hdev)
+ return cmd_status(sk, MGMT_OP_PAIR_DEVICE, ENODEV);
+
+ hci_dev_lock_bh(hdev);
+
+ if (cp->io_cap == 0x03) {
+ sec_level = BT_SECURITY_MEDIUM;
+ auth_type = HCI_AT_DEDICATED_BONDING;
+ } else {
+ sec_level = BT_SECURITY_HIGH;
+ auth_type = HCI_AT_DEDICATED_BONDING_MITM;
+ }
+
+ conn = hci_connect(hdev, ACL_LINK, &cp->bdaddr, sec_level, auth_type);
+ if (!conn) {
+ err = -ENOMEM;
+ goto unlock;
+ }
+
+ if (conn->connect_cfm_cb) {
+ hci_conn_put(conn);
+ err = cmd_status(sk, MGMT_OP_PAIR_DEVICE, EBUSY);
+ goto unlock;
+ }
+
+ cmd = mgmt_pending_add(sk, MGMT_OP_PAIR_DEVICE, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
+ hci_conn_put(conn);
+ goto unlock;
+ }
+
+ conn->connect_cfm_cb = pairing_complete_cb;
+ conn->security_cfm_cb = pairing_complete_cb;
+ conn->disconn_cfm_cb = pairing_complete_cb;
+ conn->io_capability = cp->io_cap;
+ cmd->user_data = conn;
+
+ if (conn->state == BT_CONNECTED &&
+ hci_conn_security(conn, sec_level, auth_type))
+ pairing_complete(cmd, 0);
+
+ err = 0;
+
+unlock:
+ hci_dev_unlock_bh(hdev);
+ hci_dev_put(hdev);
+
+ return err;
+}
+
int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
{
unsigned char *buf;
@@ -1148,6 +1278,9 @@ int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
case MGMT_OP_SET_IO_CAPABILITY:
err = set_io_capability(sk, buf + sizeof(*hdr), len);
break;
+ case MGMT_OP_PAIR_DEVICE:
+ err = pair_device(sk, buf + sizeof(*hdr), len);
+ break;
default:
BT_DBG("Unknown op %u", opcode);
err = cmd_status(sk, opcode, 0x01);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/8] Bluetooth: Make pending_add return a pointer to the added entry
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1298127962-18576-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
This makes it more convenient to do manipulations on the entry (needed
by later commits).
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/mgmt.c | 62 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index f5ef7a3..52e5f88 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -219,14 +219,14 @@ static void mgmt_pending_free(struct pending_cmd *cmd)
kfree(cmd);
}
-static int mgmt_pending_add(struct sock *sk, u16 opcode, int index,
- void *data, u16 len)
+static struct pending_cmd *mgmt_pending_add(struct sock *sk, u16 opcode,
+ u16 index, void *data, u16 len)
{
struct pending_cmd *cmd;
cmd = kmalloc(sizeof(*cmd), GFP_ATOMIC);
if (!cmd)
- return -ENOMEM;
+ return NULL;
cmd->opcode = opcode;
cmd->index = index;
@@ -234,7 +234,7 @@ static int mgmt_pending_add(struct sock *sk, u16 opcode, int index,
cmd->cmd = kmalloc(len, GFP_ATOMIC);
if (!cmd->cmd) {
kfree(cmd);
- return -ENOMEM;
+ return NULL;
}
memcpy(cmd->cmd, data, len);
@@ -244,7 +244,7 @@ static int mgmt_pending_add(struct sock *sk, u16 opcode, int index,
list_add(&cmd->list, &cmd_list);
- return 0;
+ return cmd;
}
static void mgmt_pending_foreach(u16 opcode, int index,
@@ -305,8 +305,9 @@ static int set_powered(struct sock *sk, unsigned char *data, u16 len)
{
struct mgmt_mode *cp;
struct hci_dev *hdev;
+ struct pending_cmd *cmd;
u16 dev_id;
- int ret, up;
+ int err, up;
cp = (void *) data;
dev_id = get_unaligned_le16(&cp->index);
@@ -321,36 +322,39 @@ static int set_powered(struct sock *sk, unsigned char *data, u16 len)
up = test_bit(HCI_UP, &hdev->flags);
if ((cp->val && up) || (!cp->val && !up)) {
- ret = cmd_status(sk, MGMT_OP_SET_POWERED, EALREADY);
+ err = cmd_status(sk, MGMT_OP_SET_POWERED, EALREADY);
goto failed;
}
if (mgmt_pending_find(MGMT_OP_SET_POWERED, dev_id)) {
- ret = cmd_status(sk, MGMT_OP_SET_POWERED, EBUSY);
+ err = cmd_status(sk, MGMT_OP_SET_POWERED, EBUSY);
goto failed;
}
- ret = mgmt_pending_add(sk, MGMT_OP_SET_POWERED, dev_id, data, len);
- if (ret < 0)
+ cmd = mgmt_pending_add(sk, MGMT_OP_SET_POWERED, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
if (cp->val)
queue_work(hdev->workqueue, &hdev->power_on);
else
queue_work(hdev->workqueue, &hdev->power_off);
- ret = 0;
+ err = 0;
failed:
hci_dev_unlock_bh(hdev);
hci_dev_put(hdev);
- return ret;
+ return err;
}
static int set_discoverable(struct sock *sk, unsigned char *data, u16 len)
{
struct mgmt_mode *cp;
struct hci_dev *hdev;
+ struct pending_cmd *cmd;
u16 dev_id;
u8 scan;
int err;
@@ -383,9 +387,11 @@ static int set_discoverable(struct sock *sk, unsigned char *data, u16 len)
goto failed;
}
- err = mgmt_pending_add(sk, MGMT_OP_SET_DISCOVERABLE, dev_id, data, len);
- if (err < 0)
+ cmd = mgmt_pending_add(sk, MGMT_OP_SET_DISCOVERABLE, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
scan = SCAN_PAGE;
@@ -407,6 +413,7 @@ static int set_connectable(struct sock *sk, unsigned char *data, u16 len)
{
struct mgmt_mode *cp;
struct hci_dev *hdev;
+ struct pending_cmd *cmd;
u16 dev_id;
u8 scan;
int err;
@@ -438,9 +445,11 @@ static int set_connectable(struct sock *sk, unsigned char *data, u16 len)
goto failed;
}
- err = mgmt_pending_add(sk, MGMT_OP_SET_CONNECTABLE, dev_id, data, len);
- if (err < 0)
+ cmd = mgmt_pending_add(sk, MGMT_OP_SET_CONNECTABLE, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
if (cp->val)
scan = SCAN_PAGE;
@@ -828,6 +837,7 @@ static int disconnect(struct sock *sk, unsigned char *data, u16 len)
struct hci_dev *hdev;
struct mgmt_cp_disconnect *cp;
struct hci_cp_disconnect dc;
+ struct pending_cmd *cmd;
struct hci_conn *conn;
u16 dev_id;
int err;
@@ -859,9 +869,11 @@ static int disconnect(struct sock *sk, unsigned char *data, u16 len)
goto failed;
}
- err = mgmt_pending_add(sk, MGMT_OP_DISCONNECT, dev_id, data, len);
- if (err < 0)
+ cmd = mgmt_pending_add(sk, MGMT_OP_DISCONNECT, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
put_unaligned_le16(conn->handle, &dc.handle);
dc.reason = 0x13; /* Remote User Terminated Connection */
@@ -938,6 +950,7 @@ static int pin_code_reply(struct sock *sk, unsigned char *data, u16 len)
struct hci_dev *hdev;
struct mgmt_cp_pin_code_reply *cp;
struct hci_cp_pin_code_reply reply;
+ struct pending_cmd *cmd;
u16 dev_id;
int err;
@@ -957,9 +970,11 @@ static int pin_code_reply(struct sock *sk, unsigned char *data, u16 len)
goto failed;
}
- err = mgmt_pending_add(sk, MGMT_OP_PIN_CODE_REPLY, dev_id, data, len);
- if (err < 0)
+ cmd = mgmt_pending_add(sk, MGMT_OP_PIN_CODE_REPLY, dev_id, data, len);
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
bacpy(&reply.bdaddr, &cp->bdaddr);
reply.pin_len = cp->pin_len;
@@ -980,6 +995,7 @@ static int pin_code_neg_reply(struct sock *sk, unsigned char *data, u16 len)
{
struct hci_dev *hdev;
struct mgmt_cp_pin_code_neg_reply *cp;
+ struct pending_cmd *cmd;
u16 dev_id;
int err;
@@ -999,10 +1015,12 @@ static int pin_code_neg_reply(struct sock *sk, unsigned char *data, u16 len)
goto failed;
}
- err = mgmt_pending_add(sk, MGMT_OP_PIN_CODE_NEG_REPLY, dev_id,
+ cmd = mgmt_pending_add(sk, MGMT_OP_PIN_CODE_NEG_REPLY, dev_id,
data, len);
- if (err < 0)
+ if (!cmd) {
+ err = -ENOMEM;
goto failed;
+ }
err = hci_send_cmd(hdev, HCI_OP_PIN_CODE_NEG_REPLY, sizeof(bdaddr_t),
&cp->bdaddr);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/8] More Management interface patches
From: johan.hedberg @ 2011-02-19 15:05 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Here's a new set of patches for the Management interface. Combined with
the latest user space git these patches enable both legacy and Secure
Simple Pairing procedures. After these the only big missing feature in
the management interface is device discovery which I'm just about to
start working on.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox