Re: proposal: rename DLT_PRISM_HEADER

[Solomon Peachy <solomon () linux-wlan com>]

On Mon, Dec 16, 2002 at 12:38:15PM -0800, Guy Harris wrote:
> Unfortunately, you didn't CC Solomon on the mail, so he wouldn't see it
> unless he's subscribed to tcpdump-workers, and he doesn't seem to be
> subcribed to it, so he probably didn't see it.

Okay, okay.  I should get off my ass and subscribe.  :) 

[providing majordomo likes me this time, I'm now on tcpdump-workers..]

> > What are the units for the mactime? The hosttime? It would be nice if
> > the units were standardized (nanoseconds, picoseconds) or if the header
> > carried some units indication. Also, is it desirable to indicate which
> > packet feature the mactime marks (PLCP header, 802.11 header, packet end)?

mactime is the high-resolution timestamp from the NIC.  There are no
units, because it is highly hardware dependent.. 

hosttime is the highest-resolution timestamp we can get from the host at
the time the packet is received from the hardware, before it wades its
way through the rest of the network stack.  On linux systems, this is
the 'jiffies' counter.  

Of course, I'm open to suggestions on how to improve this header.  The
goal was to have it provide all the layer 2 information one could
conceivably get from the NIC hardware that wouldn't necessarily be
present in the 802.11 or os-specific headers. 

> Also, why is the hosttime here in the first place?  How does that differ
> from the regular frame time stamp that *all* frames passing through BPF
> or the Linux networking stack get?

Ah, Linux provides this, but do other systems?

> > Is the dot11AntennaList given in the 802.11 spec?

The dot11PhyAntenna table is documented on page 495 of the 802.11-1999
spec, and the dot11AntennasList table is documented on page 503.

> > Any idea how the version numbers be coordinated?

Right now, through me. *chuckle* 

Currently the "definitive" source is at:

www.shaftnet.org/~pizza/software/capturefrm.txt

I'm partial to making the "definitive" document part of the ethereal cvs
tree, to be kept hand-in-hand with the dissector.

On the other hand, 95% of a maintainer's job is saying "no", and I'd
like to keep this from getting bloated with OS/NIC-specific things.

The document as-is doesn't actually have any kind of revision
information, that will obviously have to change.  Plus a few corrections
that have cropped up..

> > Any particular reason for the super-generous, 32-bit fields?

So we don't have to worry about alignment and byte-packing issues.
Simplicity is more important than saving a few bytes.

 - Pizza
-- 
Solomon Peachy                        solomon () linux-wlan com
AbsoluteValue Systems                 http://www.linux-wlan.com
715-D North Drive                     +1 (321) 259-0737  (office)
Melbourne, FL 32934                   +1 (321) 259-0286  (fax)

Attachment: _bin
Description: