On Sun, 29 Jul 2007, Juan RP wrote:

> On Sun, 22 Jul 2007 21:40:55 +0100 (BST)
> Iain Hibbert <plunky@rya-online.net> wrote:
>
> > On Sun, 22 Jul 2007, Iain Hibbert wrote:
> >
> > > Looking at it the trail in the bluetooth stack is fairly short and I
> > > can't see much possibility of mistake there, will look at it in more
> > > depth later..
> >
> > Juan, can you try to reproduce that with the attached patch included, so
> > that I can have more information about where this might be going wrong?
>
> Hi, I just tried this patch and tried to send three files via obexapp in
> server mode from my cellular phone to the ubt0. This time the third time
> the connection was accepted... there are only these messages:
>
> hdr.length = 12, count = 80
> ubt0: bad ACL packet length (76 != 12)
>
> Hope this helps... thanks.

Sorry for delay, I've been ENOTIME. I'm away from home until wednesday so
I can't doublecheck the spec, but as far as I recall this means that the
bluetooth code is not at fault, the usb stack has given us an 80 byte
transfer which IIRC is supposed to be a single packet, but that when we
examine the (4 byte) packet header we find there should have only been 12
bytes of packet payload.

This packet is built by the local bluetooth controller to pass the ACL
data over USB to the host so it is not related to the remote device at
all.

The 'bad ACL packet length' is a DIAGNOSTIC message for something that I
considered should never happen, and in fact the behaviour is modified in
that case - without DIAGNOSTIC, it will be silently accepted and most
likely the extra data will be ignored because the code doesn't look past
the data it is expecting. Do you know is this a recently occurring
phenomenon or has it always happened?

What is the USB layout relating to ubt on this machine, can you post the
dmesg?

iain