[PATCH 0/3] Support binary pin codes

[PATCH 0/3] Support binary pin codes

[David Herrmann]

This patch series allows passing binary bluetooth PINs to the hci handlers
by adding a pin_len argument. This is required to support devices which
require binary PINs like the Nintendo Wii Remote.

This patch series also adds Nintendo Wii Remote pairing support by hardcoding
the PIN. This was discussed earlier in:
http://thread.gmane.org/gmane.linux.bluez.kernel/3961

Marcel suggested automatic pairing inside the daemon by VID/PID detection
and this patch implements this approach. See:
http://thread.gmane.org/gmane.linux.bluez.kernel/3964


Regards
David

[PATCH 1/3] Add length argument to hci pincode reply

[David Herrmann]

This adds a new "length" argument to the hci pincode reply to allow
sending binary pins including \0 characters.
---
 plugins/hciops.c  |    9 ++++-----
 plugins/mgmtops.c |   14 ++++++--------
 src/adapter.c     |    2 +-
 src/adapter.h     |    2 +-
 4 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/plugins/hciops.c b/plugins/hciops.c
index 93f6f21..afac330 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -3296,7 +3296,7 @@ static int hciops_remove_bonding(int index, bdaddr_t *bdaddr)
 	return 0;
 }
 
-static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
+static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen)
 {
 	struct dev_info *dev = &devs[index];
 	char addr[18];
@@ -3307,14 +3307,13 @@ static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
 
 	if (pin) {
 		pin_code_reply_cp pr;
-		size_t len = strlen(pin);
 
-		dev->pin_length = len;
+		dev->pin_length = pinlen;
 
 		memset(&pr, 0, sizeof(pr));
 		bacpy(&pr.bdaddr, bdaddr);
-		memcpy(pr.pin_code, pin, len);
-		pr.pin_len = len;
+		memcpy(pr.pin_code, pin, pinlen);
+		pr.pin_len = pinlen;
 		err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
 						OCF_PIN_CODE_REPLY,
 						PIN_CODE_REPLY_CP_SIZE, &pr);
diff --git a/plugins/mgmtops.c b/plugins/mgmtops.c
index 042afc5..d03a29d 100644
--- a/plugins/mgmtops.c
+++ b/plugins/mgmtops.c
@@ -493,7 +493,7 @@ static void mgmt_connect_failed(int sk, uint16_t index, void *buf, size_t len)
 	btd_event_bonding_complete(&info->bdaddr, &ev->bdaddr, ev->status);
 }
 
-static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
+static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen)
 {
 	char buf[MGMT_HDR_SIZE + sizeof(struct mgmt_cp_pin_code_reply)];
 	struct mgmt_hdr *hdr = (void *) buf;
@@ -501,7 +501,7 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
 	char addr[18];
 
 	ba2str(bdaddr, addr);
-	DBG("index %d addr %s pin %s", index, addr, pin ? pin : "<none>");
+	DBG("index %d addr %s pinlen %lu", index, addr, pinlen);
 
 	memset(buf, 0, sizeof(buf));
 
@@ -518,10 +518,8 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
 		buf_len = sizeof(*hdr) + sizeof(*cp);
 	} else {
 		struct mgmt_cp_pin_code_reply *cp;
-		size_t pin_len;
 
-		pin_len = strlen(pin);
-		if (pin_len > 16)
+		if (pinlen > 16)
 			return -EINVAL;
 
 		hdr->opcode = htobs(MGMT_OP_PIN_CODE_REPLY);
@@ -530,8 +528,8 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
 
 		cp = (void *) &buf[sizeof(*hdr)];
 		bacpy(&cp->bdaddr, bdaddr);
-		cp->pin_len = pin_len;
-		memcpy(cp->pin_code, pin, pin_len);
+		cp->pin_len = pinlen;
+		memcpy(cp->pin_code, pin, pinlen);
 
 		buf_len = sizeof(*hdr) + sizeof(*cp);
 	}
@@ -568,7 +566,7 @@ static void mgmt_pin_code_request(int sk, uint16_t index, void *buf, size_t len)
 	err = btd_event_request_pin(&info->bdaddr, &ev->bdaddr);
 	if (err < 0) {
 		error("btd_event_request_pin: %s", strerror(-err));
-		mgmt_pincode_reply(index, &ev->bdaddr, NULL);
+		mgmt_pincode_reply(index, &ev->bdaddr, NULL, 0);
 	}
 }
 
diff --git a/src/adapter.c b/src/adapter.c
index c400bfd..83f3217 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3703,7 +3703,7 @@ int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr)
 int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
 							const char *pin)
 {
-	return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin);
+	return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pin ? strlen(pin) : 0);
 }
 
 int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/adapter.h b/src/adapter.h
index 308af75..fd2fc12 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -221,7 +221,7 @@ struct btd_adapter_ops {
 	int (*read_local_features) (int index, uint8_t *features);
 	int (*disconnect) (int index, bdaddr_t *bdaddr);
 	int (*remove_bonding) (int index, bdaddr_t *bdaddr);
-	int (*pincode_reply) (int index, bdaddr_t *bdaddr, const char *pin);
+	int (*pincode_reply) (int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen);
 	int (*confirm_reply) (int index, bdaddr_t *bdaddr, gboolean success);
 	int (*passkey_reply) (int index, bdaddr_t *bdaddr, uint32_t passkey);
 	int (*enable_le) (int index);
-- 
1.7.4.2

[PATCH 2/3] Make adapter API accept binary pincodes

[David Herrmann]

Add pin-length argument to adapter API to allow passing binary pins
containing \0 characters to the hci handler.
---
 src/adapter.c |    4 ++--
 src/adapter.h |    2 +-
 src/event.c   |    6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/adapter.c b/src/adapter.c
index 83f3217..14516ac 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3701,9 +3701,9 @@ int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr)
 }
 
 int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
-							const char *pin)
+							const char *pin, size_t pinlen)
 {
-	return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pin ? strlen(pin) : 0);
+	return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pinlen);
 }
 
 int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/adapter.h b/src/adapter.h
index fd2fc12..b507506 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -273,7 +273,7 @@ int btd_adapter_disconnect_device(struct btd_adapter *adapter,
 int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr);
 
 int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
-							const char *pin);
+							const char *pin, size_t pinlen);
 int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
 							gboolean success);
 int btd_adapter_passkey_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/event.c b/src/event.c
index 4ca1be5..91343d4 100644
--- a/src/event.c
+++ b/src/event.c
@@ -111,13 +111,13 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
 	device_get_address(device, &dba);
 
 	if (derr) {
-		err = btd_adapter_pincode_reply(adapter, &dba, NULL);
+		err = btd_adapter_pincode_reply(adapter, &dba, NULL, 0);
 		if (err < 0)
 			goto fail;
 		return;
 	}
 
-	err = btd_adapter_pincode_reply(adapter, &dba, pincode);
+	err = btd_adapter_pincode_reply(adapter, &dba, pincode, pincode ? strlen(pincode) : 0);
 	if (err < 0)
 		goto fail;
 
@@ -142,7 +142,7 @@ int btd_event_request_pin(bdaddr_t *sba, bdaddr_t *dba)
 	memset(pin, 0, sizeof(pin));
 	pinlen = read_pin_code(sba, dba, pin);
 	if (pinlen > 0) {
-		btd_adapter_pincode_reply(adapter, dba, pin);
+		btd_adapter_pincode_reply(adapter, dba, pin, pinlen);
 		return 0;
 	}
 
-- 
1.7.4.2

[PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[David Herrmann]

The Nintendo Wii Remote requires the destination bluetooth address
as pincode. This changes the pin handling by skipping the agent
module and sending an hardcoded pin if the target device is a
Nintendo Wii Remote.
---
 src/event.c |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/src/event.c b/src/event.c
index 91343d4..ec05e95 100644
--- a/src/event.c
+++ b/src/event.c
@@ -129,6 +129,24 @@ fail:
 	error("Sending PIN code reply failed: %s (%d)", strerror(-err), -err);
 }
 
+static int get_pin(bdaddr_t *sba, bdaddr_t *dba, char *pinbuf)
+{
+	uint16_t vendor, product;
+	char src_addr[18], dst_addr[18];
+
+	ba2str(sba, src_addr);
+	ba2str(dba, dst_addr);
+	if (0 == read_device_id(src_addr, dst_addr, NULL, &vendor, &product, NULL)) {
+		/* Nintendo Wii Remote uses destination address as PIN */
+		if (vendor == 0x057e && product == 0x0306) {
+			memcpy(pinbuf, dba, 6);
+			return 6;
+		}
+	}
+
+	return read_pin_code(sba, dba, pinbuf);
+}
+
 int btd_event_request_pin(bdaddr_t *sba, bdaddr_t *dba)
 {
 	struct btd_adapter *adapter;
@@ -140,7 +158,7 @@ int btd_event_request_pin(bdaddr_t *sba, bdaddr_t *dba)
 		return -ENODEV;
 
 	memset(pin, 0, sizeof(pin));
-	pinlen = read_pin_code(sba, dba, pin);
+	pinlen = get_pin(sba, dba, pin);
 	if (pinlen > 0) {
 		btd_adapter_pincode_reply(adapter, dba, pin, pinlen);
 		return 0;
-- 
1.7.4.2

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[Daniele Forsi]

David Herrmann wrote:

> The Nintendo Wii Remote requires the destination bluetooth address
> as pincode.

according to my my tests they require the source address, ie the host
adapter's address

> +		/* Nintendo Wii Remote uses destination address as PIN */

better to document in that comment if it works when pressing the red
button or the 1+2 buttons

I tested your 3 patches against bluez git 4.91-32-gd7f412e and
gnome-bluetooth 2.32 but they didn't work for me for 2 reasons:
1) can't get vid/pid so when the remote is unknown the
read_device_id() call in your code fails to get vid/pid and the
specific pin is never tried; the same happens after a failed pairing
when the /var/lib/bluetooth/*/did file contains a line this:
00:1F:C5:25:36:87 FFFF 0000 0000 0000
2) the source vs destination address I mentioned above

It works for me if I manually edit that line with the values read from
another wiimote's line:
00:1F:C5:25:36:87 0002 057E 0306 0600
and if I change dba to sba here
>			memcpy(pinbuf, dba, 6);

how can I help you to debug these issues?

BTW pairing also works when I use the test code mentioned in
https://bugzilla.gnome.org/show_bug.cgi?id=603845#c6
-- 
Daniele Forsi

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[David Herrmann]

On Wed, Apr 6, 2011 at 12:04 PM, Daniele Forsi <dforsi@gmail.com> wrote:
>> The Nintendo Wii Remote requires the destination bluetooth address
>> as pincode.
>
> according to my my tests they require the source address, ie the host
> adapter's address
>
>> +             /* Nintendo Wii Remote uses destination address as PIN */
>
> better to document in that comment if it works when pressing the red
> button or the 1+2 buttons
Pressing 1+2 buttons requires the destination address, pressing the sync
button requires the source address. Since the 1+2 buttons technique is the
more easy way I decided to implement this way first, however, the bluez
daemon needs input from the user-agent to decide which method to use finally.
The Wii decides which PIN to use depending whether the red-sync button on the
Wii (yes, on the wii, not the wiimote) or the "connection" button in
the Wii-menu is used.
The latter one uses destination address, the first one source address.

I couldn't figure out when autoreconnection is established, reliably. Pairing
the wiimote works sometimes, but not always and I didn't figure out how to
reset the internal cache of reconnection addresses. My wiimote also saves up
to 3 addresses which it can reconnect to in an unreliable way and so I sometimes
end up with my wiimote starting the Wii instead of reconnecing to my
PC. However,
this issue may be solved later.

>
> I tested your 3 patches against bluez git 4.91-32-gd7f412e and
> gnome-bluetooth 2.32 but they didn't work for me for 2 reasons:
> 1) can't get vid/pid so when the remote is unknown the
> read_device_id() call in your code fails to get vid/pid and the
> specific pin is never tried; the same happens after a failed pairing
> when the /var/lib/bluetooth/*/did file contains a line this:
> 00:1F:C5:25:36:87 FFFF 0000 0000 0000
All my Wiimotes have a PnP SDP record which is fetched by the SDP code
inside bluez so VID/PID should be available. Could you test using
sdptool whether there is a valid PnP record in your wiimote? If there is
no PnP record with VID/PID information it would be useful to know how
old your wiimote is. I have 3 different wiimotes, one about 2 years old,
one 1 year old and one new WiimotePlus which is about 1/2 year old and
all of them have the same PnP record so I assumed all wiimotes have this
PnP record.
If there is a valid PnP record maybe some bluez Dev could elaborate whether
VID/PID values are guaranteed to be available when pairing is started. All
my tests worked and there was always a valid VID/PID when pairing was done.

> 2) the source vs destination address I mentioned above
Please try both methods: sync button and 1+2 buttons and report which
method works
with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
red-sync-button and dest-addr plus 1+2 buttons.

>
> It works for me if I manually edit that line with the values read from
> another wiimote's line:
> 00:1F:C5:25:36:87 0002 057E 0306 0600
> and if I change dba to sba here
>>                       memcpy(pinbuf, dba, 6);
>
> how can I help you to debug these issues?
>
> BTW pairing also works when I use the test code mentioned in
> https://bugzilla.gnome.org/show_bug.cgi?id=603845#c6
This patch simply forces the source address as PIN for every device. If this
works for you, could you run the example code at:
http://goo.gl/axeqd
on the new /dev/hidrawX device which is created for the wiimote? HIDRAW support
must be enabled in the kernel of course.
This should give you VID/PID information and the HID descriptor table.
Git-url for this is: http://goo.gl/odnwd

> --
> Daniele Forsi

Thanks for helping. I think if we could figure out how to reliably get
the VID/PID
values we can change the PIN to sda to support all devices. Patch 1
and 2 of my series
might be applied anyway to allow binary pins. This would also allow to
extend the
DBUS agent interface.
If you have ideas how to support both, sba and dba via some new DBUS
interface, I would
be glad to hear about it.

David

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[Daniele Forsi]

2011/4/6 David Herrmann:

> Please try both methods: sync button and 1+2 buttons and report which
> method works
> with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
> red-sync-button and dest-addr plus 1+2 buttons.

now I understand, you're right, such explaination would be useful as a
comment in the code even if only one method is implemented
I can confirm that your code works unmodified for me too if I press
1+2 (after I manually fix the issue I still have with vid/pid), and it
also works after modifying it to use source-addr and pressing the sync
button

> If there is a valid PnP record maybe some bluez Dev could elaborate whether
> VID/PID values are guaranteed to be available when pairing is started.

I have two original remotes from December 2008 and different one from
December 2010 and their SDP records are identical:

Service RecHandle: 0x0
Service Class ID List:
  "SDP Server" (0x1000)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 1
  "SDP" (0x0001)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "" (0x0100)
    Version: 0x0100

Service Name: Nintendo RVL-CNT-01
Service Description: Nintendo RVL-CNT-01
Service Provider: Nintendo
Service RecHandle: 0x10000
Service Class ID List:
  "Human Interface Device" (0x1124)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 17
  "HIDP" (0x0011)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Human Interface Device" (0x1124)
    Version: 0x0100

Service RecHandle: 0x10001
Service Class ID List:
  "PnP Information" (0x1200)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 1
  "SDP" (0x0001)
Profile Descriptor List:
  "PnP Information" (0x1200)
    Version: 0x0100

> I couldn't figure out when autoreconnection is established, reliably. Pairing
> the wiimote works sometimes, but not always and I didn't figure out how to
> reset the internal cache of reconnection addresses.

if you have dangerous ideas I'm willing to sacrifice for the good of
science :-) my remote that doesn't work well

> If this works for you, could you run the example code at:
> http://goo.gl/axeqd
> on the new /dev/hidrawX device which is created for the wiimote?

it kind of works, but it seems I'm running an older kernel
(2.6.35-28-generic #49-Ubuntu):
$ sudo ./hid-example /dev/hidraw0
Report Descriptor Size: 218
Report Descriptor:
5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0

Raw Name: Nintendo RVL-CNT-01
Raw Phys: 00:1F:81:00:01:00
Raw Info:
	bustype: 5 (Bluetooth)
	vendor: 0x057e
	product: 0x0306
HIDIOCSFEATURE: Invalid argument
HIDIOCGFEATURE: Invalid argument
write() wrote 2 bytes
read: Resource temporarily unavailable

> If you have ideas how to support both, sba and dba via some new DBUS
> interface, I would be glad to hear about it.

using a binary pin seems to solve this problem and the pin could be
constructed by the agent based on user choice (and the agent can use
the binary pin interface also for plain strings)
I understand that constructing the pin in bluez would make it
available to all agents but then how do we ask the user for which
method to use?

you know better than me, but supporting dba doesn't seem a strict
requirement to me because pairing with 1+2 already worked for me with
gnome-bluetooth 2.32 and bluez-4.69; the config file has this
explaination:
  The special NULL pin means that the devices will not be paired, but
  connected to and marked as trusted. This is for devices such as mice
  and joypads where there is no encryption
I don't understand the details but this means that CreateDevice is
used instead of CreatePairedDevice
-- 
Daniele Forsi

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[Bastien Nocera]

On Wed, 2011-04-06 at 16:05 +0200, Daniele Forsi wrote:
> 2011/4/6 David Herrmann:
> 
> > Please try both methods: sync button and 1+2 buttons and report which
> > method works
> > with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
> > red-sync-button and dest-addr plus 1+2 buttons.
> 
> now I understand, you're right, such explaination would be useful as a
> comment in the code even if only one method is implemented
> I can confirm that your code works unmodified for me too if I press
> 1+2 (after I manually fix the issue I still have with vid/pid), and it
> also works after modifying it to use source-addr and pressing the sync
> button
> 
> > If there is a valid PnP record maybe some bluez Dev could elaborate whether
> > VID/PID values are guaranteed to be available when pairing is started.
> 
> I have two original remotes from December 2008 and different one from
> December 2010 and their SDP records are identical:
> 
> Service RecHandle: 0x0
> Service Class ID List:
>   "SDP Server" (0x1000)
> Protocol Descriptor List:
>   "L2CAP" (0x0100)
>     PSM: 1
>   "SDP" (0x0001)
> Language Base Attr List:
>   code_ISO639: 0x656e
>   encoding:    0x6a
>   base_offset: 0x100
> Profile Descriptor List:
>   "" (0x0100)
>     Version: 0x0100
> 
> Service Name: Nintendo RVL-CNT-01
> Service Description: Nintendo RVL-CNT-01
> Service Provider: Nintendo
> Service RecHandle: 0x10000
> Service Class ID List:
>   "Human Interface Device" (0x1124)
> Protocol Descriptor List:
>   "L2CAP" (0x0100)
>     PSM: 17
>   "HIDP" (0x0011)
> Language Base Attr List:
>   code_ISO639: 0x656e
>   encoding:    0x6a
>   base_offset: 0x100
> Profile Descriptor List:
>   "Human Interface Device" (0x1124)
>     Version: 0x0100
> 
> Service RecHandle: 0x10001
> Service Class ID List:
>   "PnP Information" (0x1200)
> Protocol Descriptor List:
>   "L2CAP" (0x0100)
>     PSM: 1
>   "SDP" (0x0001)
> Profile Descriptor List:
>   "PnP Information" (0x1200)
>     Version: 0x0100
> 
> > I couldn't figure out when autoreconnection is established, reliably. Pairing
> > the wiimote works sometimes, but not always and I didn't figure out how to
> > reset the internal cache of reconnection addresses.
> 
> if you have dangerous ideas I'm willing to sacrifice for the good of
> science :-) my remote that doesn't work well
> 
> > If this works for you, could you run the example code at:
> > http://goo.gl/axeqd
> > on the new /dev/hidrawX device which is created for the wiimote?
> 
> it kind of works, but it seems I'm running an older kernel
> (2.6.35-28-generic #49-Ubuntu):
> $ sudo ./hid-example /dev/hidraw0
> Report Descriptor Size: 218
> Report Descriptor:
> 5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
> 1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
> 15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
> 9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
> 85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
> 5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
> 0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
> 95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0
> 
> Raw Name: Nintendo RVL-CNT-01
> Raw Phys: 00:1F:81:00:01:00
> Raw Info:
> 	bustype: 5 (Bluetooth)
> 	vendor: 0x057e
> 	product: 0x0306
> HIDIOCSFEATURE: Invalid argument
> HIDIOCGFEATURE: Invalid argument
> write() wrote 2 bytes
> read: Resource temporarily unavailable
> 
> > If you have ideas how to support both, sba and dba via some new DBUS
> > interface, I would be glad to hear about it.
> 
> using a binary pin seems to solve this problem and the pin could be
> constructed by the agent based on user choice (and the agent can use
> the binary pin interface also for plain strings)
> I understand that constructing the pin in bluez would make it
> available to all agents but then how do we ask the user for which
> method to use?
> 
> you know better than me, but supporting dba doesn't seem a strict
> requirement to me because pairing with 1+2 already worked for me with
> gnome-bluetooth 2.32 and bluez-4.69; the config file has this
> explaination:

The whole point of this is of actually pairing the Wiimote so that when
turned on, the Wiimote connects to the computer. If you need to press
any buttons other than the power one, then it's not working.

>   The special NULL pin means that the devices will not be paired, but
>   connected to and marked as trusted. This is for devices such as mice
>   and joypads where there is no encryption
> I don't understand the details but this means that CreateDevice is
> used instead of CreatePairedDevice

The special NULL means that you would have needed to make the Wiimote
discoverable (through pressing 1/2) before it was usable.

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[David Herrmann]

On Wed, Apr 6, 2011 at 4:31 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Wed, 2011-04-06 at 16:05 +0200, Daniele Forsi wrote:
>> 2011/4/6 David Herrmann:
>>
>> > Please try both methods: sync button and 1+2 buttons and report which
>> > method works
>> > with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
>> > red-sync-button and dest-addr plus 1+2 buttons.
>>
>> now I understand, you're right, such explaination would be useful as a
>> comment in the code even if only one method is implemented
>> I can confirm that your code works unmodified for me too if I press
>> 1+2 (after I manually fix the issue I still have with vid/pid), and it
>> also works after modifying it to use source-addr and pressing the sync
>> button
>>
>> > If there is a valid PnP record maybe some bluez Dev could elaborate whether
>> > VID/PID values are guaranteed to be available when pairing is started.
>>
>> I have two original remotes from December 2008 and different one from
>> December 2010 and their SDP records are identical:
>>
>> Service RecHandle: 0x0
>> Service Class ID List:
>>   "SDP Server" (0x1000)
>> Protocol Descriptor List:
>>   "L2CAP" (0x0100)
>>     PSM: 1
>>   "SDP" (0x0001)
>> Language Base Attr List:
>>   code_ISO639: 0x656e
>>   encoding:    0x6a
>>   base_offset: 0x100
>> Profile Descriptor List:
>>   "" (0x0100)
>>     Version: 0x0100
>>
>> Service Name: Nintendo RVL-CNT-01
>> Service Description: Nintendo RVL-CNT-01
>> Service Provider: Nintendo
>> Service RecHandle: 0x10000
>> Service Class ID List:
>>   "Human Interface Device" (0x1124)
>> Protocol Descriptor List:
>>   "L2CAP" (0x0100)
>>     PSM: 17
>>   "HIDP" (0x0011)
>> Language Base Attr List:
>>   code_ISO639: 0x656e
>>   encoding:    0x6a
>>   base_offset: 0x100
>> Profile Descriptor List:
>>   "Human Interface Device" (0x1124)
>>     Version: 0x0100
>>
>> Service RecHandle: 0x10001
>> Service Class ID List:
>>   "PnP Information" (0x1200)
>> Protocol Descriptor List:
>>   "L2CAP" (0x0100)
>>     PSM: 1
>>   "SDP" (0x0001)
>> Profile Descriptor List:
>>   "PnP Information" (0x1200)
>>     Version: 0x0100
>>
>> > I couldn't figure out when autoreconnection is established, reliably. Pairing
>> > the wiimote works sometimes, but not always and I didn't figure out how to
>> > reset the internal cache of reconnection addresses.
>>
>> if you have dangerous ideas I'm willing to sacrifice for the good of
>> science :-) my remote that doesn't work well
>>
>> > If this works for you, could you run the example code at:
>> > http://goo.gl/axeqd
>> > on the new /dev/hidrawX device which is created for the wiimote?
>>
>> it kind of works, but it seems I'm running an older kernel
>> (2.6.35-28-generic #49-Ubuntu):
>> $ sudo ./hid-example /dev/hidraw0
>> Report Descriptor Size: 218
>> Report Descriptor:
>> 5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
>> 1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
>> 15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
>> 9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
>> 85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
>> 5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
>> 0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
>> 95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0
>>
>> Raw Name: Nintendo RVL-CNT-01
>> Raw Phys: 00:1F:81:00:01:00
>> Raw Info:
>>       bustype: 5 (Bluetooth)
>>       vendor: 0x057e
>>       product: 0x0306
>> HIDIOCSFEATURE: Invalid argument
>> HIDIOCGFEATURE: Invalid argument
>> write() wrote 2 bytes
>> read: Resource temporarily unavailable
>>
>> > If you have ideas how to support both, sba and dba via some new DBUS
>> > interface, I would be glad to hear about it.
>>
>> using a binary pin seems to solve this problem and the pin could be
>> constructed by the agent based on user choice (and the agent can use
>> the binary pin interface also for plain strings)
>> I understand that constructing the pin in bluez would make it
>> available to all agents but then how do we ask the user for which
>> method to use?
>>
>> you know better than me, but supporting dba doesn't seem a strict
>> requirement to me because pairing with 1+2 already worked for me with
>> gnome-bluetooth 2.32 and bluez-4.69; the config file has this
>> explaination:
>
> The whole point of this is of actually pairing the Wiimote so that when
> turned on, the Wiimote connects to the computer. If you need to press
> any buttons other than the power one, then it's not working.

Exactly.

I prefer my solution with dba over sba because it allows to pair the wiimote
without opening the backside. The only issue left with the patches is the
VID/PID thing. It works perfectly for me when I delete the device with
gnome-bluetooth and add the wiimote as new device.

It would be interesting to know from a bluez dev or gnome-bluetooth dev whether
the SDP records are always retrieved before trying to connect to a remote
device or whether we need to do this manually.

Re: [PATCH 3/3] Support hardcoded Nintendo Wii Remote pins

[Bastien Nocera]

On Wed, 2011-04-06 at 19:55 +0200, David Herrmann wrote:
<snip>
> Exactly.
> 
> I prefer my solution with dba over sba because it allows to pair the wiimote
> without opening the backside. The only issue left with the patches is the
> VID/PID thing. It works perfectly for me when I delete the device with
> gnome-bluetooth and add the wiimote as new device.

gnome-bluetooth just calls RemoveDevice() which won't remove cached SDP
records, resolved name, etc. for the device. Best open
up /var/lib/bluetooth files with a text editor, and remove everything
related to your Wiimote for testing.

(or you can just nuke the directory if you don't care about pairing your
other devices again).

> It would be interesting to know from a bluez dev or gnome-bluetooth dev whether
> the SDP records are always retrieved before trying to connect to a remote
> device or whether we need to do this manually.

The ordering of this is done by bluetoothd, and I'm pretty certain that
the SDP records are only updated *after* pairing, as some devices might
refuse to answer SDP requests from unpaired devices.

But at that point we should already have a name for it cached (at least
with gnome-bluetooth, which waits for the name to be resolved to allow
you to go through the next steps).