Re: btuart and SOCKET Bluetooth CF

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

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