Re: [tcpdump-workers] pcap segment violation
Yes, even so 2014-02-13 16:36 GMT-05:00, Guy Harris : > > On Feb 13, 2014, at 1:24 PM, "Daniel H. Bahr" wrote: > >> For some reason, as I said earlier, if the SIGSEGV is not connected to >> the bailout nothing queer happens, > > Even if you leave SIGQUIT and SIGTERM connected? > > ___ 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] Request for DLT for new BlueZ Monitor
On Dec 27, 2013, at 3:13 AM, Michal Labedzki wrote: > I think the best name for this is DLT_BLUETOOTH_LINUX_MONITOR, because > this is Linux kernelspace, not BlueZ userland. OK, LINKTYPE_BLUETOOTH_LINUX_MONITOR and DLT_BLUETOOTH_LINUX_MONITOR have been assigned the value 254. ___ 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 Feb 14, 2014, at 12:18 PM, Chris Kilgour wrote: > 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. > 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. > Assuming the DLT allocations move ahead, does one then submit a patch with > both the new DLTs and pseudoheaders? No. > 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. ___ 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 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. ___ 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
