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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
