Re: [Bluez-devel] [Cbe-oss-dev] [PATCH] reset unexpected bluetooth data connections

["Ranulf Doswell" <ralf@ranulf.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2222 bytes --]

Hi Michael,

Thanks for the info, specifically the pointers to the coding style and patch
submission rules, which I neglected to look for in my excitement to create
my first kernel patch!

 I'll repost the patch in a few minutes as I've made the comments generic
rather than sounding like a PS3-specific ptroblem.

This is one of the places you should send this patch, the other is the
> bluetooth list, which I've CC'ed. The main issue is whether your patch
> is safe in the general case, or if it's just a PS3 issue.


I haven't got a great deal of BT equipment, so it's hard to test, but my
personal opinion is that any device which sends unsolicited data should
survive having a reset sent to it, as it's not correct for it to be sending
ACL data without a valid connection established. Arguably, the same patch
should be applied when unsolicited SCO data is received, although I have no
way of testing this.

Without the patch, it doesn't make sense to syslog the invalid data as it
opens up the system to an easily exploitable DOS simply by getting within
100m of a machine and flooding it with packets from a handheld device. This
particular device was sending about 100 packets per second.

Cool, do the sixaxis controllers work with this patch applied?


Pascal's hidd patch (patch-hidd-2.24-pabr2) works well to enable the
controllers to be detected. It looks like the most important part of the
patch has already been accepted into the bluez-utils tree, although the MTU
increase part of the patch hasn't been included, so PS3 controllers still
don't work out of the box as they require a slightly larger MTU.

All this patch does is reset the controllers when the machine is rebooted as
they otherwise continue to send packets until the machine is powered down.
It seems that their timeout is about a minute and that linux's stack running
provides sufficient ACK that data is still being received even if the kernel
itself doesn't know anything about the connection.

An additional patch to send every bluetooth device a reset as the kernel is
shutting down would probably also be a good idea, although it is possible to
add "hidd --killall" to a shutdown script to achieve the same result.

Cheers,
    Ralf.

[-- Attachment #1.2: Type: text/html, Size: 2703 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel