(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.
