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
