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 16:48:37 +0100 [thread overview]
Message-ID: <52AC7DD5.1030402@ahsoftware.de> (raw)
In-Reply-To: <52AC7237.10306@ahsoftware.de>
Am 14.12.2013 15:59, schrieb Alexander Holler:
> Am 14.12.2013 14:36, schrieb Johan Hedberg:
>> Hi Alexander,
>>
>> On Sat, Dec 14, 2013, Alexander Holler wrote:
>>> 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.
>>
>> From the HCI logs you showed on IRC it was quite clear that the (remote
>> side) authorization phase for each connect attempt was finished before
>> the next connect attempt started, i.e. there was an L2CAP Connect
>> Response with an error status before the next L2CAP Connect Request. So
>> from this perspective there didn't seem to be any lack of serialization.
>
> That wasn't so clear for me as I've seen different responses from the
> remote device, but still nothing ended up at the local agent afer the
> first connection attempt failed (regardless how many retries).
>
> So there is no solution to this problem and one local user can easily
> DOS all local bluetooth communicaton?
Ok, that might be the wrong question. But I see two problems here:
First, an application can't be sure why a connection attempt failed.
Second, how should an application behave if a connection attempt failed
because of unknown reasons? Just retrying doesn't seem work.
Regards,
Alexander Holler
prev parent reply other threads:[~2013-12-14 15:48 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
2013-12-14 13:36 ` Johan Hedberg
2013-12-14 14:59 ` Alexander Holler
2013-12-14 15:48 ` Alexander Holler [this message]
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=52AC7DD5.1030402@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.