Re: [PATCH] bluetooth/l2cap: silence framedrop kmsg noise

["Gregory M. Turner" <gmt@be-evil.net>]

On Sunday 22 February 2015 16:05:37 Marcel Holtmann wrote:
> Hi Greg,
>
> I get the feeling that either dongle or the remote device is broken. If it
> is the dongle, it might actually needs a firmware update / ROM patch to
> make this behave properly.

I'm pretty sure the firmware's up to date on it.  But this thing is quite old 
and not well supported.  I think it's an old revision of the HW that was 
superseded by something slightly less shitty in future Logitech packages (they 
do still sell this keyboard package, or did the last time I checked, but 
reports were, it came with a different dongle).

This behavior definitely follows the dongle -- all other factors have been 
varied and ruled out over the many years I've put up with this thing.

> The real problem is that we get a ACL fragment from the controller telling
> us that it is continuation of a previous packet. However this previous
> packet seems to never arrive in the first place. Meaning I have no idea
> what is actually happening here. The error message tells you that.

With length zero?  That seems crazy.  Or am I misunderstanding what that 
number signifies?

> So instead of removing it, we might want to consider using rate limiting for
> that specific error message.

In my particular case, it makes sense to just apply the patch I posted even if 
it's wrong.  Clearly, though, this is treating the symptom, not the disease.

> It is a valid error message.

Idunno... obv. it's valid in the sense that this is what the driver thinks the 
device is telling the host, hence, my patch is stupid.

However, it seems I have either a) a broken dongle b) a dongle that's working 
as designed, but whose design is broken or nonstandard*, or c) a broken linux 
driver (but the line between c and b is blurry).

I'm wondering, in particular, about (b).  I used to have a second dongle like 
this one.  It fell apart some years ago (hmm, I may have saved the pieces 
somewhere), but I'm pretty sure it had the same behavior.  That was a long 
time ago, however; I could definitely be remembering incorrectly.

I'll see if I can't learn how to get my android phone to sniff this traffic.  My 
thinking is, if a sniffed dump looked different from the host's dump, I'd have a 
pretty clear indication of a problem arising at or below the driver layer.

Another similar avenue of attack would be to mess around with Windows.  If 
there is some way to generate these dumps in Windows, and everything looked 
fine there, I'd at least have a clear indication that the kernel driver lacks 
some needed quirk support for this device.

-gmt