Re: [tcpdump-workers] Request for DLT for new BlueZ Monitor
I'd like to suggest that "struct _pcap_bluetooth_monitor_header" is too generic a name when this header only applies to the internal workings of an operating system's HCI and adapter-lifetime traffic. There are other forms of bluetooth monitoring that are not OS-specific nor even cover HCI. For example open-source sniffers like ubertooth and gr-bluetooth capture at the RF level. It's likely that a DLT allocation request will be forthcoming for capturing bluetooth over-the-air [1]. [1] https://github.com/greatscottgadgets/ubertooth/wiki/Bluetooth-Captures-in-PCAP Chris Kilgour ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Two DLT Requests For Bluetooth RF Captures
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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures
On 02/14/2014 04:46 PM, Guy Harris wrote: > > 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. > 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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures
On 02/14/2014 04:50 PM, Guy Harris wrote: > > On Feb 14, 2014, at 4:46 PM, Guy Harris wrote: > >> 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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures
On 02/16/2014 03:32 PM, Guy Harris wrote: >> >> [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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Two DLT Requests For Bluetooth RF Captures
> 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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
