Linux bluetooth development
 help / color / mirror / Atom feed
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


  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