This patch series adds support for hexadecimal encoded pins. This is
no final patch and I would be glad to get some feedback.
This patch series solves the problem that the current bluez implementation
does not allow binary PINs that contain ASCII \0 characters. This is needed
for several devices that take bluetooth addresses as PINs. I had the
following ideas to implement binary pins:
- Hard coding binary pins into bluetoothd by detecting the device with
PnP VID/PID information as suggested by Marcel Holtmann.
However, this is not possible (as noted by Bastien Nocera) because
devices may refuse to offer SDP information for unpaired hosts.
Furthermore, SDP records are retrieved after pairing with the remote
device unless they're cached.
- Adding a new dbus agent interface that returns pins as byte-arrays
instead of 0-terminated strings. However, this either breaks backward-
compatibility or needs _huge_ additions to the dbus interface.
- Adding escape-sequences to pins or special pin parsing. This does break
backward-compatibility but may be implemented in a way that reduces
problems to a minimum.
I implemented the first approach a week ago as discussed on the mailing list
which turned out to be not appropriate. The second approach is probably the
cleanest one but requires huge dbus API additions. This patch series
implements the third approach. See patch 3/4 for details on the suggested
PIN encoding.
Pin encoding with the dollar sign is just a temporary approach which makes
the implementation quite easy and shows the idea of this patch. However,
the encoding is of course open for discussion.
Binary pin support is inspired by getting Nintendo Wiimote pairing support.
To test wiimote pairing with this patch series, do the following:
- assume the local bdaddr is: 01:23:45:67:89:ab
and the wiimote bdaddr is: ba:98:76:54:32:10
- Pairing with red-sync button, use pin: $ab8967452301 (host addr. backwards)
- Pairing with 1+2 buttons, use pin: $1032547698ba (wiimote addr backwards)
Automatic reconnection is only enabled in the wiimote when synced with the
red-sync button. The 1+2 button method is only for temporary connections.
Regards
David
Agents can now return PIN codes longer than 16 characters. The
pin parser automatically truncates all PINs to 16 characters, but
allows hexadecimal PINs to be longer than 16 characters because
each two hexdecimal encoded bytes are parsed into one output byte.
---
src/agent.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/agent.c b/src/agent.c
index f87f253..40495bf 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -403,7 +403,7 @@ static void pincode_reply(DBusPendingCall *call, void *user_data)
len = strlen(pin);
dbus_error_init(&err);
- if (len > 16 || len < 1) {
+ if (len < 1) {
error("Invalid PIN length (%zu) from agent", len);
dbus_set_error_const(&err, "org.bluez.Error.InvalidArgs",
"Invalid passkey length");
--
1.7.4.4
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..248fb78 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.4
If a pin code is retrieved from an agent and the first character is
a dollar sign '$', then the pin is decoded as following:
- The first character (dollar sign) is stripped from the pin
- The rest is parsed as hexadecimal numbers, where each two characters
will be converted into a one byte integer. If an odd number of
characters follows, then the last character is stripped. Empty
pins are valid. Parser is case insensitive.
Pins not starting with '$' are parsed as usual.
For instance:
pin: $0A3e005067
is decoded into a 5 byte pin:
decoded: 0x0a 0x3e 0x00 0x50 0x67
---
src/event.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/src/event.c b/src/event.c
index 248fb78..f2fc688 100644
--- a/src/event.c
+++ b/src/event.c
@@ -101,12 +101,52 @@ static gboolean get_adapter_and_device(bdaddr_t *src, bdaddr_t *dst,
*
*****************************************************************/
+static char hex2dec(char c)
+{
+ if (c >= '0' && c <= '9')
+ return c - '0';
+ else if (c >= 'A' && c <= 'F')
+ return c - 'A' + 10;
+ else if (c >= 'a' && c <= 'f')
+ return c - 'a' + 10;
+ else
+ return 0;
+}
+
+static size_t decode_hex(const char *pin, char *out)
+{
+ size_t i;
+
+ for (i = 0; i < 16 && pin[i * 2] && pin[i * 2 + 1]; ++i)
+ out[i] = hex2dec(pin[i * 2]) * 16 + hex2dec(pin[i * 2 + 1]);
+ return i;
+}
+
+static size_t decode_pin(const char *pin, char *out)
+{
+ size_t len;
+
+ if (!pin) {
+ return 0;
+ }
+ else if (pin[0] == '$') {
+ len = decode_hex(&pin[1], out);
+ }
+ else {
+ len = strnlen(pin, 16);
+ memcpy(out, pin, len);
+ }
+ return len;
+}
+
static void pincode_cb(struct agent *agent, DBusError *derr,
const char *pincode, struct btd_device *device)
{
struct btd_adapter *adapter = device_get_adapter(device);
bdaddr_t sba, dba;
int err;
+ size_t len;
+ char rawpin[16];
device_get_address(device, &dba);
@@ -117,7 +157,8 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
return;
}
- err = btd_adapter_pincode_reply(adapter, &dba, pincode, pincode ? strlen(pincode) : 0);
+ len = decode_pin(pincode, rawpin);
+ err = btd_adapter_pincode_reply(adapter, &dba, rawpin, len);
if (err < 0)
goto fail;
--
1.7.4.4
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.4
On Tue, 2011-05-03 at 20:28 +0200, David Herrmann wrote:
> On Tue, May 3, 2011 at 2:27 PM, Daniele Forsi <[email protected]> wrote:
> > one issue when using the 1+2 way is that the Wiimote will forget the
> > pairing when it is turned off while the PC will remember it, so the
> > Wiimote won't be shown in the list of found devices and you need to
> > delete it before you can pair again
>
> I don't get this. If the wiimote is listed as paired, why would you
> want to see it in the list of found devices? The wiimote is already
> listed as paired so simply reestablish the pairing by connecting to
> the wiimote via DBus bluez.Input api.
If the Wiimote is already paired, it won't appear in the "discoverable
and not already setup" devices list in the wizard.
But your point is correct.
> >>> Is there any way to detect which "type" of pairing is made with the
> >>> Wiimote, eg. you say that button 1+2 will only work for temporary
> >>> connections. Can we detect this? Would pairing anyway work?
> >>
> >> I guess you mean that you wanna predict which PIN to use? No, I
> >> currently know no way to detect this. However, one may try the first
> >> pin and if that fails the second pin.
> >
> > I think this is what the Wii does when in the "home" screen where you
> > are supposed to press 1+2 because it will find the remote also when
> > pressing the sync button (I have a Wiimote that I need to pair from
> > the home screen pressing sync because it doesn't wake up with 1+2)
>
> With 1+2 buttons only the dest-address works as PIN (I checked this). However,
> with "sync" button both addresses may work. I will check this later...
> Anyway, this would simplify the wiimote handling significantly.
Either way, I think I'd do the work so that the "proper" pairing can be
done, and add a warning at the end of a failed pairing process for a
Wiimote if pairing failed, mentioning which way you should press the
buttons to have it always paired.
I'll get on that as soon as your patches make it into bluez master
proper.
Cheers
* David Herrmann <[email protected]> [2011-04-10 19:11:15 +0200]:
> 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)
Over column 80 here.
> {
> - 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);
and here.
> 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..248fb78 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);
and here.
--
Gustavo F. Padovan
http://profusion.mobi
* David Herrmann <[email protected]> [2011-04-10 19:11:14 +0200]:
> 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)
This is over 80 characters. And call pinlen, pin_len instead to keep the same
name and have a small diff here.
> {
> 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);
Over 80 here as well.
> }
>
> 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);
same here.
--
Gustavo F. Padovan
http://profusion.mobi
On Tue, May 3, 2011 at 2:27 PM, Daniele Forsi <[email protected]> wrote:
> one issue when using the 1+2 way is that the Wiimote will forget the
> pairing when it is turned off while the PC will remember it, so the
> Wiimote won't be shown in the list of found devices and you need to
> delete it before you can pair again
I don't get this. If the wiimote is listed as paired, why would you
want to see it in the list of found devices? The wiimote is already
listed as paired so simply reestablish the pairing by connecting to
the wiimote via DBus bluez.Input api.
>>> Is there any way to detect which "type" of pairing is made with the
>>> Wiimote, eg. you say that button 1+2 will only work for temporary
>>> connections. Can we detect this? Would pairing anyway work?
>>
>> I guess you mean that you wanna predict which PIN to use? No, I
>> currently know no way to detect this. However, one may try the first
>> pin and if that fails the second pin.
>
> I think this is what the Wii does when in the "home" screen where you
> are supposed to press 1+2 because it will find the remote also when
> pressing the sync button (I have a Wiimote that I need to pair from
> the home screen pressing sync because it doesn't wake up with 1+2)
With 1+2 buttons only the dest-address works as PIN (I checked this). However,
with "sync" button both addresses may work. I will check this later...
Anyway, this would simplify the wiimote handling significantly.
2011/5/3 David Herrmann:
> On Tue, May 3, 2011 at 1:32 AM, Bastien Nocera wrote:
>> What are the necessary changes to be made in gnome-bluetooth?
>>
>> I'm guessing that we should add a "WIIMOTE" type of special casing in
>> the pin database, and pass the adapter address as per the above when a
>> PIN is requested.
>
> Exactly. If I click on PIN-type in gnome-bluetooth applet, then there
> are already several choices I can make. I'd recommend adding a new one
> with "use source address as PIN" and one with "use destination address
> as PIN".
yeah, automatically shown only when the selected device is a Wiimote
one issue when using the 1+2 way is that the Wiimote will forget the
pairing when it is turned off while the PC will remember it, so the
Wiimote won't be shown in the list of found devices and you need to
delete it before you can pair again
>> Is there any way to detect which "type" of pairing is made with the
>> Wiimote, eg. you say that button 1+2 will only work for temporary
>> connections. Can we detect this? Would pairing anyway work?
>
> I guess you mean that you wanna predict which PIN to use? No, I
> currently know no way to detect this. However, one may try the first
> pin and if that fails the second pin.
I think this is what the Wii does when in the "home" screen where you
are supposed to press 1+2 because it will find the remote also when
pressing the sync button (I have a Wiimote that I need to pair from
the home screen pressing sync because it doesn't wake up with 1+2)
--
Daniele Forsi
On Tue, May 3, 2011 at 1:32 AM, Bastien Nocera <[email protected]> wrote:
> What are the necessary changes to be made in gnome-bluetooth?
>
> I'm guessing that we should add a "WIIMOTE" type of special casing in
> the pin database, and pass the adapter address as per the above when a
> PIN is requested.
Exactly. If I click on PIN-type in gnome-bluetooth applet, then there
are already several choices I can make. I'd recommend adding a new one
with "use source address as PIN" and one with "use destination address
as PIN".
Then at least all functionalities to pair with a device are
implemented. Additional auto-detection may be added...
> Is there any way to detect which "type" of pairing is made with the
> Wiimote, eg. you say that button 1+2 will only work for temporary
> connections. Can we detect this? Would pairing anyway work?
I guess you mean that you wanna predict which PIN to use? No, I
currently know no way to detect this. However, one may try the first
pin and if that fails the second pin. As far as I know, the wiimote
does not turn off when a wrong PIN is passed so you can try other
PINs. I am still working on reverse-engineering the protocol and maybe
I will find a way, though.
> Cheers
Regards
David
On Sun, 2011-04-10 at 19:11 +0200, David Herrmann wrote:
<snip>
> Binary pin support is inspired by getting Nintendo Wiimote pairing support.
> To test wiimote pairing with this patch series, do the following:
> - assume the local bdaddr is: 01:23:45:67:89:ab
> and the wiimote bdaddr is: ba:98:76:54:32:10
> - Pairing with red-sync button, use pin: $ab8967452301 (host addr. backwards)
> - Pairing with 1+2 buttons, use pin: $1032547698ba (wiimote addr backwards)
> Automatic reconnection is only enabled in the wiimote when synced with the
> red-sync button. The 1+2 button method is only for temporary connections.
What are the necessary changes to be made in gnome-bluetooth?
I'm guessing that we should add a "WIIMOTE" type of special casing in
the pin database, and pass the adapter address as per the above when a
PIN is requested.
Is there any way to detect which "type" of pairing is made with the
Wiimote, eg. you say that button 1+2 will only work for temporary
connections. Can we detect this? Would pairing anyway work?
Cheers