tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: btuart and SOCKET Bluetooth CF
Hi! Iain,
From: Iain Hibbert <plunky%rya-online.net@localhost>
Date: Tue, 19 Jan 2010 14:03:22 +0000 (GMT)
> On Tue, 19 Jan 2010, Iain Hibbert wrote:
> 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] ..]
I know, DTL operates following packet format.
In acldata case:
{
{
uint8 type;
uint8 rsvd;
uint16 len;
} NOKIA DTL header;
{
uint16_t con_handle;
uint16_t length;
};
{
data ...
};
[uint8_t pad;] /* need, if len is odd. */
}
NOKIA DTL parses little-endian. And operates each 2bytes/word. When
the length of data is an odd byte because headers are four bytes always,
padding is necessary.
> 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.
What do you meaning?
Please more explain.
Thanks,
--
kiyohara
Home |
Main Index |
Thread Index |
Old Index