All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.