(Blah blah blah work around duplicate message detector blah blah blah
someday I'll figure out if I can configure Thunderbird to know that all
tcpdump-workers mail should come from my alum.mit.edu address blah blah
blah.)
David Young wrote:
Here is support for radiotap, an extensible radio capture header for
802.11, in its (hopefully) final form. I made the diffs from the
CVS HEAD.
The main difference from previous radiotap patches (such as those that
appear in FreeBSD) is that it fixes some alignment problems.
Any objections to my committing this to cvs.tcpdump.org?
Looks good to me, at least for the top-of-tree (where we require that
the platform support 64-bit integers, and where we define u_int64_t to
be an unsigned 64-bit integer type).
(I still hold out the hope that tcpdump can someday provide some alignment
guarantee---radiotap is designed so that if the radiotap header is on
a natural 64-bit boundary, then every field is on its natural boundary.
One problem is that we currently don't require that tcpdump 3.x be
linked with libpcap 0.x - adding an alignment guarantee to libpcap would
require that tcpdump know whether the libpcap with which it's linked
makes that guarantee.
Also, in radiotap v2, I would like to capture in the native byte-order,
but I haven't figured out how to interpret saved-packet files of different
endianness.)
pcap_is_swapped(p) returns true if the capture file you've opened
was captured on a machine with a different byte order, based on the byte
order of the magic number - if that matches the byte order of the
radiotap values, that'd be sufficient.
(It always returns false for live captures.)
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
