Hi Michael,<br><br>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!<br><br> I'll repost the patch in a few minutes as I've made the comments generic rather than sounding like a PS3-specific ptroblem.
<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is one of the places you should send this patch, the other is the<br>bluetooth list, which I've CC'ed. The main issue is whether your patch
<br>is safe in the general case, or if it's just a PS3 issue.</blockquote><div><br>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.
<br><br>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.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Cool, do the sixaxis controllers work with this patch applied?
</blockquote><div><br>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.
<br><br>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.
<br><br>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.
<br><br></div><div>Cheers,<br> Ralf.</div></div><br>