DLT for Bluetooth Low Energy

[dragorn]

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 <***@isecpartners.com> -----

Date: Mon, 29 Apr 2013 13:09:32 -0700
From: Mike Ryan <***@isecpartners.com>
To: ***@kismetwireless.net
Subject: request: DLT for Bluetooth Low Energy

[sent this as-is to tcpdump-***@lists.tcpdump.org]

I would like a DLT for Bluetooth Low Energy, which is described in the
following document (warning, large PDF):

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

The link layer specification begins on PDF page 2189. The packet format
and headers begin on page 2200.

Background: I am a security researcher and have implemented a BTLE
sniffer for project Ubertooth (http://ubertooth.sf.net). One of my tools
dumps captured packets to PCAP, currently using USER_DLT0. I have also
written a Wireshark protocol dissector for these PCAP files.

These pieces of software are intended for public release, so I would
like a DLT for interoperability.

More information about can be found at my personal site:

http://lacklustre.net/bluetooth/
http://lacklustre.net/bluetooth/wireshark.html



----- End forwarded message -----

--

[M***@tieto.com]

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 Management Protocol (LMP) in BR/EDR and the
Link Layer Protocol (LL) in LE."... maybe it is good idea to request two new DLT too :
1. For Bluetooth LMP (described in the same specification, page 455) (optional for me)
2. For Ubertooth (preferred by me)


Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation
Product Engineering Services
http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
e-mail: ***@tieto.com
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN

[Guy Harris]

Post by dragorn
Date: Mon, 29 Apr 2013 13:09:32 -0700
Subject: request: DLT for Bluetooth Low Energy
I would like a DLT for Bluetooth Low Energy, which is described in the
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737
The link layer specification begins on PDF page 2189. The packet format
and headers begin on page 2200.

Do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL sound like reasonable names?

[Guy Harris]

Post by Guy Harris
Do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL sound like reasonable names?

Yep, those sound fine!

OK, I've assigned 251 for them.

[Guy Harris]

Post by Guy Harris

Post by Guy Harris
Do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL sound like reasonable names?

Yep, those sound fine!

OK, I've assigned 251 for them.

Fantastic!

So do LINKTYPE_BLUETOOTH_LE_LL/DLT_BLUETOOTH_LE_LL packets include the preamble octet and the CRC?

Got another request - can we get one for _BLUETOOTH_BB as well, for
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737
Baseband is at page 354

Those fields don't end on octet boundaries; are the bits stuffed into octets disregarding octet boundaries?

The spec says that "data fields generated internally at baseband level, such as the packet header fields and payload header length, shall be transmitted with the LSB first"; are the bits stored in octets as they're received and, if so, is the first bit of the packet the MSB or the LSB of the first bit?

Or are the packets not presented in quite as raw a fashion?

[Mike Ryan]

Hi, I impelemented most of the BTLE support in Ubertooth.

Post by Guy Harris
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
will be stored in the PPI with each packet.

[Guy Harris]

Post by Mike Ryan
Hi, I impelemented most of the BTLE support in Ubertooth.

Post by Guy Harris
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 file has:

4 bytes of Access Address;

2-39 bytes of packet data;

3 bytes of CRC;

in sequential order, with nothing separating them, right?

Post by Mike Ryan
To validate the CRC you must know a per-connection CrcInit. This value
will be stored in the PPI with each packet.

"Stored in the PPI"? Does that mean "stored in per-packet information kept by the program reading the capture file", or does it mean "per-packet information stored *in* the capture file"? If the latter, that presumably means there's some form of pseudo-header preceding the Access Address.

[Mike Ryan]

Post by Guy Harris

Post by Mike Ryan

Post by Guy Harris
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.
4 bytes of Access Address;
2-39 bytes of packet data;
3 bytes of CRC;
in sequential order, with nothing separating them, right?

Correct.

Post by Guy Harris

Post by Mike Ryan
To validate the CRC you must know a per-connection CrcInit. This value
will be stored in the PPI with each packet.

"Stored in the PPI"? Does that mean "stored in per-packet information
kept by the program reading the capture file", or does it mean
"per-packet information stored *in* the capture file"? If the latter,
that presumably means there's some form of pseudo-header preceding the
Access Address.

I prepend a PPI packet header to the packet, which includes the DLT
(thank you for assigning!) and some metadata about the packet and the
state of the Ubertooth during capture.

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

[Mike Ryan]

Post by Mike Ryan
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
Loading Image...

[Guy Harris]

Post by Mike Ryan
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.

Post by Mike Ryan
which includes the DLT (thank you for assigning!)

Oh, dear, it sounds as if the file's LINKTYPE_ value would be LINKTYPE_PPI.

So what is a program to do if handed a file with a LINKTYPE_ value of LINKTYPE_BLUETOOTH_LE_LL?

I *REALLY* don't want to see *ANY* LINKTYPE_/DLT_ values assigned that can *ONLY* be used in a LINKTYPE_PPI file.

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.

[Mike Ryan]

Post by Guy Harris
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's easiest to base stuff on existing examples.

[Guy Harris]

Post by Mike Ryan

Post by Guy Harris
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's easiest to base stuff on existing examples.

802.11; see, for example, LINKTYPE_IEEE802_11_RADIOTAP/DLT_IEEE802_11_RADIO, where the packet data is preceded by a radiotap header:

http://www.radiotap.org/