From: Alexander Holler <holler@ahsoftware.de>
To: linux-bluetooth@vger.kernel.org
Subject: Re: Shouldn't bluez serialize connection/authorization attempts?
Date: Sat, 14 Dec 2013 12:55:51 +0100 [thread overview]
Message-ID: <52AC4747.4080409@ahsoftware.de> (raw)
In-Reply-To: <52AC4425.7080109@ahsoftware.de>
Am 14.12.2013 12:42, schrieb Alexander Holler:
> Hello,
>
> I've experienced a small problem which makes me wonder how userspace is
> expected to handle that.
>
> To explain the problem, I use simple-agent and rfcomm on the local side
> (Linux with bluez) and a remote device with a fixed pin (without user
> interaction, it refuses or allows connections based on the pin), but I
> think the underlying problem is independent of that configuration.
>
> Furthermore, I did a small patch to the local simple-agent:
> -----------------
> diff --git a/test/simple-agent b/test/simple-agent
> index 854e1af..63b705b 100755
> --- a/test/simple-agent
> +++ b/test/simple-agent
> @@ -64,8 +64,9 @@ class Agent(dbus.service.Object):
> in_signature="o",
> out_signature="s")
> def RequestPinCode(self, device):
> print("RequestPinCode (%s)" % (device))
> - set_trusted(device)
> - return ask("Enter PIN Code: ")
> + #set_trusted(device)
> + #return ask("Enter PIN Code: ")
> + return "666"
>
> @dbus.service.method(AGENT_INTERFACE,
> in_signature="o",
> out_signature="u")
> -----------------
>
> That means it now always returns 666 as pin without asking the user.
> This pin doesn't match the pin of the remote device.
>
> If I now call
>
> for i in $(seq 1 100); do rfcomm connect rfcomm666 aa:bb:cc:dd:ee:ff ; done
>
> in a shell, only one Pin request (the first) ends up at simple-agent but
> all connection attempts are refused.
>
> So besides the first connection attempt, all others do die somewhere
> where userspace has no control over.
>
> What happens is likely that connection attempts are refused by the
> remote side, because an ongoing connection or authorization attempt
> isn't finished while a new one arrives.
>
> The problem I see here is, that userspace has no control about what
> happens during a connection attempt. And userspace doesn't know if any
> other process just did a connection attempt too. How should userspace
> behave to make sure every connection attempt ends up in a pin-request
> for the user?
>
> Shouldn't those connection/pairing/authorization attempts to the same
> remote device be serialized by bluez?
>
Sorry, I forget to mention the local system: Linux 3.12.5 and bluez 5.12.
Regards,
Alexander Holler
next prev parent reply other threads:[~2013-12-14 11:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-14 11:42 Shouldn't bluez serialize connection/authorization attempts? Alexander Holler
2013-12-14 11:55 ` Alexander Holler [this message]
2013-12-14 13:36 ` Johan Hedberg
2013-12-14 14:59 ` Alexander Holler
2013-12-14 15:48 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52AC4747.4080409@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox