Re: btuart and SOCKET Bluetooth CF

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Tue, 19 Jan 2010, Iain Hibbert wrote:

> On Tue, 19 Jan 2010, KIYOHARA Takashi wrote:
>
> > > Hm, does it work with ACL data yet?  I think that your
> > > btuart_dtl_output_acl() function strips the ACLDATA header.. I don't
> > > understand how does the device know the connection handle?
> >
> > Only type (1byte) of acldata adjust to me. Perhaps, the problem is not
> > in this.
>
> mm yes, my bad

perhaps related to this byte-pad ?

+       dtlh->len =
+           htole16(sizeof(hdr) - sizeof(hdr.type) + le16toh(hdr.length));
+       if (dtlh->len & 0x1)
+               m_copyback(m, m->m_pkthdr.len, 1, &dtlh->rsvd); /* Add pad */

dtlh->len is not host byte order so could be wrong padding added?

also - should this value reflect the real length (including the pad)? eg
data stream:

    [type] [rsvd] [len0] [len1] [.. data[len] ..]
    [type] [rsvd] [len0] [len1] [.. data[len] ..]
    [type] [rsvd] [len0] [len1] [.. data[len] ..]
    [type] [rsvd] [len0] [len1] [.. data[len] ..]

then, the device would strip the outer header and can ignore any padding
(I don't know if it works like that, but the HCI packet header contains
the actual length)

Further, I think for simplicity you don't need to interpret the HCI packet
header directly during output, just use the m->m_pkthdr.len value which is
correct.

regards,
iain