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.
