Two DLT Requests For Bluetooth RF Captures

[Chris Kilgour]

This email is submitted under the process described at [1].

I'd like to request two LINKTYPE/DLT allocations for RF Bluetooth Captures, with the details described here [2]. The details there were compiled after technical consultations on the Ubertooth mailing list and IRC.

To conform with the practices of the pcap devs, I'd be happy to modify the description at [2] for correctness and style/format, or for example to translate the format descriptions into the style used at [1].

Assuming the DLT allocations move ahead, does one then submit a patch with both the new DLTs and pseudoheaders? Or do the pcap devs update pcap/bpf.h independently?

Any other advice to help get this request approved and the results into libpcap would be appreciated.

[1] http://www.tcpdump.org/linktypes.html
[2] https://github.com/greatscottgadgets/ubertooth/wiki/Bluetooth-Captures-in-PCAP

Chris Kilgour

[Guy Harris]

Post by Chris Kilgour
I'd like to request two LINKTYPE/DLT allocations for RF Bluetooth Captures, with the details described here [2].

What is the "nanosecond offset to pcap timestamp"? pcap-ng lets you specify the resolution of time stamps, and even pcap lets you, at least with newer versions of libpcap and Wireshark, specify nanosecond resolution with a different magic number.

Post by Chris Kilgour
To conform with the practices of the pcap devs, I'd be happy to modify the description at [2] for correctness and style/format, or for example to translate the format descriptions into the style used at [1].

Translating them into the style in the pages under http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about C/C-derived-language data structure names - or anything *else* about C and languages derived from it - and also makes it easier to add the link-layer header type to the Web site.

Post by Chris Kilgour
Assuming the DLT allocations move ahead, does one then submit a patch with both the new DLTs and pseudoheaders?

No.

Post by Chris Kilgour
Or do the pcap devs update pcap/bpf.h independently?

Yes.

You may, if you wish, supply C-language structures for the pseudoheaders in header files to include in the pcap directory; it's helpful, but not a requirement.

[Guy Harris]

Post by Guy Harris
Translating them into the style in the pages under http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about C/C-derived-language data structure names - or anything *else* about C and languages derived from it - and also makes it easier to add the link-layer header type to the Web site.

...although if you're willing to ensure that your pages describing the formats will stay available (without the pseudo-header changing), we wouldn't need to create our own pages for them, and can just link to your pages in the linktypes.html page.

[Chris Kilgour]

Post by Guy Harris

Post by Guy Harris
Translating them into the style in the pages under http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about C/C-derived-language data structure names - or anything *else* about C and languages derived from it - and also makes it easier to add the link-layer header type to the Web site.

...although if you're willing to ensure that your pages describing the formats will stay available (without the pseudo-header changing), we wouldn't need to create our own pages for them, and can just link to your pages in the linktypes.html page.

I have established the following two documents that I can confirm will not be changed in any technically-significant way. There may be editorial changes for typos and the like. And, if there are any further libpcap-related technical recommendations prior to DLT allocation, I can accommodate those as well.

[1] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
[2] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html

Chris

[Guy Harris]

Post by Chris Kilgour
I have established the following two documents that I can confirm will not be changed in any technically-significant way. There may be editorial changes for typos and the like. And, if there are any further libpcap-related technical recommendations prior to DLT allocation, I can accommodate those as well.
[1] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
[2] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html

So, at this point, would you rather that tcpdump.org, rather than you, host those documents?

In your case, you could either maintain the packet description and references to other specifications (such as the Bluetooth specs, in this case), and have tcpdump.org just link to your descriptions, or have those pages live on the tcpdump.org Web site. I have no real preference for either alternative - whatever works best for you is fine.

The reference to "editorial changes" indicate that it might be better for you to maintain them, so that you can make those changes without having to put them up as pull requests on the GitHub repository for the Web site.

[Chris Kilgour]

Post by Guy Harris

Post by Chris Kilgour
[1] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
[2] http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html

So, at this point, would you rather that tcpdump.org, rather than you, host those documents?
In your case, you could either maintain the packet description and references to other specifications (such as the Bluetooth specs, in this case), and have tcpdump.org just link to your descriptions, or have those pages live on the tcpdump.org Web site. I have no real preference for either alternative - whatever works best for you is fine.
The reference to "editorial changes" indicate that it might be better for you to maintain them, so that you can make those changes without having to put them up as pull requests on the GitHub repository for the Web site.

Sure, I will keep hosting these pages.

Chris Kilgour

[Guy Harris]

Post by Chris Kilgour
Sure, I will keep hosting these pages.

OK, I've assigned:

LINKTYPE_BLUETOOTH_BREDR_BB/DLT_BLUETOOTH_BREDR_BB - 255

LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR/DLT_BLUETOOTH_LE_LL_WITH_PHDR - 256

and will update the Link-Layer Header Types page soon.

[Guy Harris]

Post by Chris Kilgour
There may be editorial changes for typos and the like.

(Speaking of typos, it's "multi-octet", not "multi-octect".)

[Chris Kilgour]

Post by Guy Harris
What is the "nanosecond offset to pcap timestamp"? pcap-ng lets you specify the resolution of time stamps, and even pcap lets you, at least with newer versions of libpcap and Wireshark, specify nanosecond resolution with a different magic number.

The motivation was classic pcap. I was up on pcap-ng, but did not realize the pcap format has an updated variant with higher-precision timestamps. So I have removed the ns field from the pseudoheaders.

Post by Guy Harris
Translating them into the style in the pages under http://www.tcpdump.org/linktypes would be helpful. It avoids worrying about C/C-derived-language data structure names - or anything *else* about C and languages derived from it - and also makes it easier to add the link-layer header type to the Web site.

Okay, I will do this. Are the linktype description pages developed with any tools or templates, or just written as HTML (with the website's CSS applied)?

I also have a question prompted by reviewing some sample pages like [1] and [2].

It seems some folks choose little-endian for multi-byte fields and others choose network/big-endian. It there a preference here? Is it acceptable to define these fields as having the same endianness as the pcap file header (or pcap-ng section header)?

[1] http://www.tcpdump.org/linktypes/LINKTYPE_NG40.html
[2] http://www.tcpdump.org/linktypes/LINKTYPE_NETANALYZER.html

[Guy Harris]

Post by Chris Kilgour
The motivation was classic pcap. I was up on pcap-ng, but did not realize the pcap format has an updated variant with higher-precision timestamps.

Yup. Use 0xa1b23c4d, rather than 0xa1b2c3d4, as the magic number, as per

http://www.tcpdump.org/manpages/pcap-savefile.5.html

Newer versions of libpcap have APIs to allow an application doing a live capture to request nanosecond time stamp resolution for time stamps (which may return PCAP_ERROR_TSTAMP_PRECISION_NOTSUP if the device doesn't support nanosecond resolution) and to indicate, when opening a saved capture file, that it wants seconds-and-nanoseconds time stamps rather than seconds-and-microseconds time stamps (if the file contains microsecond-resolution time stamps, the microseconds value is multiplied by 1000; there really should be an API to say "how precise are the time stamps in this file").

[Guy Harris]

Post by Chris Kilgour
It seems some folks choose little-endian for multi-byte fields and others choose network/big-endian. It there a preference here? Is it acceptable to define these fields as having the same endianness as the pcap file header (or pcap-ng section header)?

Choosing a standard byte order means that libpcap and Wireshark's Wiretap library don't have to, when reading a capture file, byte-swap fields in the pseudo-header if it's being read on a host with a byte order different from the host that wrote the file being read.

Using "byte order of the host that wrote the file" means that the code writing the file doesn't have to put the header in a standard byte order.

We have examples of all three types of data in pseudo-headers, so there's no obvious precedent for any of {big-endian, little-endian, host-that-wrote-the-file-endian}.

If the pseudo-header is extensible and the code to byte-swap the files in libpcap wouldn't be able to handle arbitrary extensions, a standard byte order should be used. In other cases (for example, a fixed-format pseudo-header, or a pseudo-header with TLVs where the T and L are host-endian but the V is in a standard byte order, like LINKTYPE_BLUETOOTH_LINUX_MONITOR), host-that-wrote-the-file-endian is acceptable.

[Guy Harris]

Post by Guy Harris

Post by Chris Kilgour
It seems some folks choose little-endian for multi-byte fields and others choose network/big-endian. It there a preference here? Is it acceptable to define these fields as having the same endianness as the pcap file header (or pcap-ng section header)?

Choosing a standard byte order means that libpcap and Wireshark's Wiretap library don't have to, when reading a capture file, byte-swap fields in the pseudo-header if it's being read on a host with a byte order different from the host that wrote the file being read.
Using "byte order of the host that wrote the file" means that the code writing the file doesn't have to put the header in a standard byte order.

The current versions of

http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html

and

http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html

say "All multi-octet fields are expressed in little-endian format." I presume that means that's now the specification, so libpcap doesn't need to byte-swap anything, and programs dissecting those packets should extract the values as if they're little-endian.

[Chris Kilgour]

Post by Guy Harris
The current versions of
http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
and
http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
say "All multi-octet fields are expressed in little-endian format." I presume that means that's now the specification, so libpcap doesn't need to byte-swap anything, and programs dissecting those packets should extract the values as if they're little-endian.

Yes, I didn't want to break new ground with the former host-endian definition, given your earlier statement. Since BT itself is little-endian oriented, and the majority of BT-sniffer users are likely Intel-based, little-endian seems the way to go.

And by the way, thanks for the quick turnaround on the DLT allocations.

Chris Kilgour