Re: [tcpdump-workers] Build and check on a big-endian system
> From: Guy Harris >On Feb 15, 2014, at 1:21 PM, Michael Richardson wrote: > >> The ESP tests are failing because you haven't got libssl-dev. > >Yes - some tests fail if the full set of support libraries weren't available >when tcpdump was built. > >Perhaps we want to suppress some tests if we don't have the appropriate >libraries - or have the tests compare against the results of a tcpdump built >without the library or libraries in question rather than the results of one >built with them. We could maybe add a text in INSTALL file, like: diff --git a/INSTALL.txt b/INSTALL.txt index 132e118..4dc61d3 100644 --- a/INSTALL.txt +++ b/INSTALL.txt @@ -9,6 +9,9 @@ You will need an ANSI C compiler to build tcpdump. The configure will abort if your compiler is not ANSI compliant. If this happens, use the generally available GNU C compiler (GCC). +To build with crypto support, you need SSL library (libssl-dev). +If you don't have this library, you will have some "make check" errors. + After libpcap has been built (either install it with "make install" or make sure both the libpcap and tcpdump source trees are in the same directory), run ./configure (a shell script). "configure" will Greetings ___ 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 Feb 16, 2014, at 2:03 PM, Chris Kilgour wrote: > 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. ___ 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 7:41 PM, Chris Kilgour wrote: > 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"). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Build and check on a big-endian system
On Feb 16, 2014, at 10:58 AM, François-Xavier Le Bail wrote: >> From: Guy Harris > >> On Feb 15, 2014, at 1:21 PM, Michael Richardson wrote: >> >>> The ESP tests are failing because you haven't got libssl-dev. >> >> Yes - some tests fail if the full set of support libraries weren't available >> when tcpdump was built. >> >> Perhaps we want to suppress some tests if we don't have the appropriate >> libraries - or have the tests compare against the results of a tcpdump built >> without the library or libraries in question rather than the results of one >> built with them. > > > We could maybe add a text in INSTALL file, like: > > diff --git a/INSTALL.txt b/INSTALL.txt > index 132e118..4dc61d3 100644 > --- a/INSTALL.txt > +++ b/INSTALL.txt > @@ -9,6 +9,9 @@ You will need an ANSI C compiler to build tcpdump. The > configure > will abort if your compiler is not ANSI compliant. If this happens, use > the generally available GNU C compiler (GCC). > > +To build with crypto support, you need SSL library (libssl-dev). > +If you don't have this library, you will have some "make check" errors. Denis appears to have fixed that with commit 9e2042ebe86c41d373930dbd89b56a6a2f06fcf0 Author: Denis Ovsienko Date: Mon Feb 17 00:22:37 2014 +0400 make OpenSSL-specific tests conditional That still leaves the NFLOG tests; that requires looking for DLT_NFLOG in the version of libpcap being used to build tcpdump, which would be a bit more work. An alternative might be to have the configure script run a test for DLT_NFLOG and somehow do something to make "make check" skip the NFLOG test. A generalization might be to have some support for "if ... end" in the tests/TESTLIST file, with the tests checking some name specified in a file, and have the configure script add entries to that file as necessary. ___ 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
On Feb 16, 2014, at 5:02 PM, Chris Kilgour wrote: > 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. ___ 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 16, 2014, at 2:03 PM, Chris Kilgour wrote: > There may be editorial changes for typos and the like. (Speaking of typos, it's "multi-octet", not "multi-octect".) ___ 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 7:41 PM, Chris Kilgour wrote:
> 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.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
