On Wed, Dec 18, 2002 at 03:56:36PM -0500, Solomon Peachy wrote:
> > With LTVs, your tcpdump may skip records whose type it does not know.
>
> No, the old DLT_IEEE80211_PRISM type did that; whet you end up with is
> a header twice as long that can't be parsed or constructed as easily and
> quickly.
What can we afford in terms of header length and CPU cycles spent parsing?
I don't know what the outer acceptable figures are. How do you think
those considerations weigh against the conveniences of LTVs I mention?
In any case, I will reluctantly adopt the present format with unspecified
mactime units. I will *gladly* adopt the format if the units for mactime
are fixed at nanosecond resolution or higher, or given by a new header
field. It is counter to the purpose of a unified radio header format to
let the units change from one adapter to another.
BTW, since you've got that 64-bit field for mactime, it does not make
sense to use less than nanosecond resolution. Consider that a 64-bit
field with nanosecond resolution provides for measuring the arrival time
of a packet sent at 54Mbps to higher resolution than you will likely
ever need (less than one "bit time"), for longer (584 years) than you
will ever monitor a channel.
Dave
--
David Young OJC Technologies
[EMAIL PROTECTED] Engineering from the Right Brain
Urbana, IL * (217) 278-3933
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
