On Jun 14, 2013, at 9:33 AM, Mike Ryan wrote:
>> Could you please switch to a scheme where the state information is a
>> pseudo-header that precedes the payload in the packet data? We could
>> assign a LINKTYPE_BLUETOOTH_LE_LL_UBERTOOTH value for that.
>
> Certainly. Can you point to any proto
> Could you please switch to a scheme where the state information is a
> pseudo-header that precedes the payload in the packet data? We could
> assign a LINKTYPE_BLUETOOTH_LE_LL_UBERTOOTH value for that.
Certainly. Can you point to any protocols which already implement things
this way? I find it'
On Jun 13, 2013, at 8:08 PM, Mike Ryan wrote:
> I prepend a PPI packet header to the packet,
Hopefully, this means that the file's LINKTYPE_ value would be
LINKTYPE_BLUETOOTH_LE_LL, not LINKTYPE_PPI.
> which includes the DLT (thank you for assigning!)
Oh, dear, it sounds as if the file's LIN
> I've attached a screenshot: you can see the old version of the PPI
> header (lacks CrcInit), the USER0 DLT, and the 18 bytes of data captured
> from the air.
>
> 18 = 4 byte AA + 2 byte header + 9 byte data + 3 byte CRC
Attachment scrubbed, see
http://lacklustre.net/bluetooth/btle_breakdown.png
> >> So do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL packets include the
> >> preamble octet and the CRC?
> >
> > They include the 3 octet CRC, they do not include the preamble.
>
> OK, I'll update the description on the "link-layer header types" page to note
> that.
>
> So the packet in the
On Jun 13, 2013, at 7:24 PM, Mike Ryan wrote:
> Hi, I impelemented most of the BTLE support in Ubertooth.
>
>> So do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL packets include the
>> preamble octet and the CRC?
>
> They include the 3 octet CRC, they do not include the preamble.
OK, I'll upd
Hi, I impelemented most of the BTLE support in Ubertooth.
> So do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL packets include the
> preamble octet and the CRC?
They include the 3 octet CRC, they do not include the preamble.
To validate the CRC you must know a per-connection CrcInit. This value
On Jun 13, 2013, at 12:52 PM, "dragorn" wrote:
> On Thu, Jun 13, 2013 at 11:51:41AM -0700, Guy Harris wrote:
>>
>> On Jun 13, 2013, at 11:13 AM, "dragorn" wrote:
>>
>>> On Thu, Jun 13, 2013 at 11:10:02AM -0700, Guy Harris wrote:
Do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL
On Jun 13, 2013, at 11:13 AM, "dragorn" wrote:
> On Thu, Jun 13, 2013 at 11:10:02AM -0700, Guy Harris wrote:
>>
>>
>> Do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL sound like reasonable names?
>
> Yep, those sound fine!
OK, I've assigned 251 for them.
__
On May 16, 2013, at 7:12 AM, dragorn wrote:
> - Forwarded message from Mike Ryan -
>
> Date: Mon, 29 Apr 2013 13:09:32 -0700
> From: Mike Ryan
> To: drag...@kismetwireless.net
> Subject: request: DLT for Bluetooth Low Energy
>
> [sent this as-is to tcpdump-workers@lists.tcpdump.org]
Hi,
This is good idea. +1 from me.
What name is proposed for new values?
DLT_BLUETOOTH_LL?
DLT_BLUETOOTH_LE?
other?
According to pointed specification, "2.1.2.2 Link Manager":
". The link manager achieves this by communicating with the link manager in
remote Bluetooth devices using the Link Ma
The list seems to be rejecting some posts, I just unsubbed/resubbed
myself in the hopes that it wakes up and lets me post this time; it
also bounced Mike Ryans post and he asked me to send it along.
- Forwarded message from Mike Ryan -
Date: Mon, 29 Apr 2013 13:09:32 -0700
From: Mike Rya
12 matches
Mail list logo