This patch adds support for handling Passkey Requests
and response over management interface.
---
lib/mgmt.h | 5 ++-
plugins/mgmtops.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/lib/mgmt.h b/lib/mgmt.h
index b77970f..cf8343b 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -218,7 +218,7 @@ struct mgmt_rp_user_confirm_reply {
#define MGMT_OP_USER_PASSKEY_REPLY 0x001C
struct mgmt_cp_user_passkey_reply {
bdaddr_t bdaddr;
- uint32_t passkey;
+ __le32 passkey;
} __packed;
struct mgmt_rp_user_passkey_reply {
bdaddr_t bdaddr;
@@ -226,6 +226,9 @@ struct mgmt_rp_user_passkey_reply {
} __packed;
#define MGMT_OP_USER_PASSKEY_NEG_REPLY 0x001D
+struct mgmt_cp_user_passkey_neg_reply {
+ bdaddr_t bdaddr;
+} __packed;
#define MGMT_OP_READ_LOCAL_OOB_DATA 0x001E
struct mgmt_rp_read_local_oob_data {
diff --git a/plugins/mgmtops.c b/plugins/mgmtops.c
index 8e6eb4d..e9920f4 100644
--- a/plugins/mgmtops.c
+++ b/plugins/mgmtops.c
@@ -572,6 +572,78 @@ static int mgmt_confirm_reply(int index, bdaddr_t *bdaddr, gboolean success)
return 0;
}
+static int mgmt_passkey_reply(int index, bdaddr_t *bdaddr, uint32_t passkey)
+{
+ char buf[MGMT_HDR_SIZE + sizeof(struct mgmt_cp_user_passkey_reply)];
+ struct mgmt_hdr *hdr = (void *) buf;
+ size_t buf_len;
+ char addr[18];
+
+ ba2str(bdaddr, addr);
+ DBG("index %d addr %s passkey %06u", index, addr, passkey);
+
+ memset(buf, 0, sizeof(buf));
+
+ hdr->index = htobs(index);
+ if (passkey == INVALID_PASSKEY) {
+ struct mgmt_cp_user_passkey_neg_reply *cp;
+
+ hdr->opcode = htobs(MGMT_OP_USER_PASSKEY_NEG_REPLY);
+ hdr->len = htobs(sizeof(*cp));
+
+ cp = (void *) &buf[sizeof(*hdr)];
+ bacpy(&cp->bdaddr, bdaddr);
+
+ buf_len = sizeof(*hdr) + sizeof(*cp);
+ } else {
+ struct mgmt_cp_user_passkey_reply *cp;
+
+ hdr->opcode = htobs(MGMT_OP_USER_PASSKEY_REPLY);
+ hdr->len = htobs(sizeof(*cp));
+
+ cp = (void *) &buf[sizeof(*hdr)];
+ bacpy(&cp->bdaddr, bdaddr);
+ cp->passkey = htobl(passkey);
+
+ buf_len = sizeof(*hdr) + sizeof(*cp);
+ }
+
+ if (write(mgmt_sock, buf, buf_len) < 0)
+ return -errno;
+
+ return 0;
+}
+
+static void mgmt_passkey_request(int sk, uint16_t index, void *buf, size_t len)
+{
+ struct mgmt_ev_user_passkey_request *ev = buf;
+ struct controller_info *info;
+ char addr[18];
+ int err;
+
+ if (len < sizeof(*ev)) {
+ error("Too small passkey_request event");
+ return;
+ }
+
+ ba2str(&ev->bdaddr, addr);
+
+ DBG("hci%u %s", index, addr);
+
+ if (index > max_index) {
+ error("Unexpected index %u in passkey_request event", index);
+ return;
+ }
+
+ info = &controllers[index];
+
+ err = btd_event_user_passkey(&info->bdaddr, &ev->bdaddr);
+ if (err < 0) {
+ error("btd_event_user_passkey: %s", strerror(-err));
+ mgmt_passkey_reply(index, &ev->bdaddr, INVALID_PASSKEY);
+ }
+}
+
struct confirm_data {
int index;
bdaddr_t bdaddr;
@@ -1406,6 +1478,9 @@ static gboolean mgmt_event(GIOChannel *io, GIOCondition cond, gpointer user_data
case MGMT_EV_DEVICE_UNBLOCKED:
mgmt_device_unblocked(sk, index, buf + MGMT_HDR_SIZE, len);
break;
+ case MGMT_EV_USER_PASSKEY_REQUEST:
+ mgmt_passkey_request(sk, index, buf + MGMT_HDR_SIZE, len);
+ break;
default:
error("Unknown Management opcode %u (index %u)", opcode, index);
break;
@@ -1749,16 +1824,6 @@ static int mgmt_remove_bonding(int index, bdaddr_t *bdaddr)
return 0;
}
-static int mgmt_passkey_reply(int index, bdaddr_t *bdaddr, uint32_t passkey)
-{
- char addr[18];
-
- ba2str(bdaddr, addr);
- DBG("index %d addr %s passkey %06u", index, addr, passkey);
-
- return -ENOSYS;
-}
-
static int mgmt_encrypt_link(int index, bdaddr_t *dst, bt_hci_result_t cb,
gpointer user_data)
{
--
1.6.6.1
Hi Johan,
On Thu, Dec 15, 2011 at 7:39 PM, Johan Hedberg <[email protected]> wrote:
> On Thu, Dec 15, 2011, Hemant Gupta wrote:
>> In my code, I am using htobl(passkey), while passkey is sent to kernel.
>> So you mean I need to change it to btohl ?
>
> No, you use htobl when encoding (writing to) a mgmt message and btohl
> when decoding (reading from) one.
Thanks a lot for clarification. Will send new patch in a moment.
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi,
On Thu, Dec 15, 2011 at 7:29 PM, Hemant Gupta <[email protected]> wrote:
> Hi Johan,
>
> On Thu, Dec 15, 2011 at 7:26 PM, Johan Hedberg <[email protected]> wrote:
>> Hi Hemant,
>>
>> On Thu, Dec 15, 2011, Hemant Gupta wrote:
>>> Thanks for the comment, I used it since the kernel was using le32, and
>>> the structure allocated was u32? Dont we require to do the type
>>> casting?
>>
>> No. To my understanding the difference is only annotational, i.e. it's
>> only there to remind you of the endianness of the variable. In user
>> space we just use uint32_t but have to remember to call btohl before
>> using the value for anything.
> In my code, I am using htobl(passkey), while passkey is sent to kernel.
> So you mean I need to change it to btohl ?
The defines in bluetooth.h seems same for both btohl and htobl
#define htobl(d) bswap_32(d)
#define btohl(d) bswap_32(d)
>>
>> Johan
>
>
>
> --
> Best Regards
> Hemant Gupta
> ST-Ericsson India
--
Best Regards
Hemant Gupta
ST-Ericsson India
On Thu, Dec 15, 2011, Hemant Gupta wrote:
> In my code, I am using htobl(passkey), while passkey is sent to kernel.
> So you mean I need to change it to btohl ?
No, you use htobl when encoding (writing to) a mgmt message and btohl
when decoding (reading from) one.
Johan
Hi Johan,
On Thu, Dec 15, 2011 at 7:26 PM, Johan Hedberg <[email protected]> wrote:
> Hi Hemant,
>
> On Thu, Dec 15, 2011, Hemant Gupta wrote:
>> Thanks for the comment, I used it since the kernel was using le32, and
>> the structure allocated was u32? Dont we require to do the type
>> casting?
>
> No. To my understanding the difference is only annotational, i.e. it's
> only there to remind you of the endianness of the variable. In user
> space we just use uint32_t but have to remember to call btohl before
> using the value for anything.
In my code, I am using htobl(passkey), while passkey is sent to kernel.
So you mean I need to change it to btohl ?
>
> Johan
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
On Thu, Dec 15, 2011, Hemant Gupta wrote:
> Tanks for the comment, I used it since the kernel was using le32, and
> the structure allocated was u32? Dont we require to do the type
> casting?
No. To my understanding the difference is only annotational, i.e. it's
only there to remind you of the endianness of the variable. In user
space we just use uint32_t but have to remember to call btohl before
using the value for anything.
Johan
Hi Johan,
On Thu, Dec 15, 2011 at 5:38 PM, Johan Hedberg <[email protected]> wrote:
> Hi Hemant,
>
> On Thu, Dec 15, 2011, Hemant Gupta wrote:
>> @@ -218,7 +218,7 @@ struct mgmt_rp_user_confirm_reply {
>> ?#define MGMT_OP_USER_PASSKEY_REPLY ? 0x001C
>> ?struct mgmt_cp_user_passkey_reply {
>> ? ? ? bdaddr_t bdaddr;
>> - ? ? uint32_t passkey;
>> + ? ? __le32 passkey;
>> ?} __packed;
>
> Otherwise the patch looks ok but this change shouldn't be in it. ?__le32
> is only for the kernel side.
>
Tanks for the comment, I used it since the kernel was using le32, and
the structure
allocated was u32? Dont we require to do the type casting?
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Johan,
On Thu, Dec 15, 2011 at 02:08:51PM +0200, Johan Hedberg wrote:
> Hi Hemant,
>
> On Thu, Dec 15, 2011, Hemant Gupta wrote:
> > @@ -218,7 +218,7 @@ struct mgmt_rp_user_confirm_reply {
> > #define MGMT_OP_USER_PASSKEY_REPLY 0x001C
> > struct mgmt_cp_user_passkey_reply {
> > bdaddr_t bdaddr;
> > - uint32_t passkey;
> > + __le32 passkey;
> > } __packed;
>
> Otherwise the patch looks ok but this change shouldn't be in it. __le32
> is only for the kernel side.
Minor comment related to debugging in general. We always allocate space
for bluetooth address string even when we do not use debug.
Best regards
Andrei Emeltchenko
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hemant,
On Thu, Dec 15, 2011, Hemant Gupta wrote:
> @@ -218,7 +218,7 @@ struct mgmt_rp_user_confirm_reply {
> #define MGMT_OP_USER_PASSKEY_REPLY 0x001C
> struct mgmt_cp_user_passkey_reply {
> bdaddr_t bdaddr;
> - uint32_t passkey;
> + __le32 passkey;
> } __packed;
Otherwise the patch looks ok but this change shouldn't be in it. __le32
is only for the kernel side.
Johan