Re: "final" radiotap patch for tcpdump

[Guy Harris <guy () alum mit edu>]

(blah blah blah *surely* Thunderbird must have some way of arranging 
that a particular mailbox have a preferred From address blah blah blah 
duplicate post blah blah blah)

David Young wrote:

> "Oh."  Have we got the stomach for radiotap v2?  If big-endian kernels
> no longer have to convert fields to little-endian, I think that puts
> the second-to-last performance issue to rest.

Sounds good to me, although a little-endian radiotap header length field
is a bit more of a pain for libpcap, as, if the byte order in a capture
file or on the capturing machine is little-endian, it'd have to generate
code to load the header a byte at a time.

For remote capture using rpcap, this would require that the protocol
include a way for the server to tell the client what the server's byte
order is, so that "pcap_is_swapped()" can give the right answer for
remote captures.

> [The "last" performance issue is that libpcap & tcpdump don't grok
> variable-length headers,

Tcpdump can handle them with no trouble when dissecting the packets.
Problems applying filters to them are libpcap problems.  I don't know
when I'll be able to spend time looking at implementing that - it is, I
think, doable, in the sense that BPF code to handle it can be written,
it's just a bit more work.


-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.