Will anyone object if I modify wi(4) so that it does not pass to bpf
the entire Prism frame, which consists of

  status
  rx timestamp
  rx silence & signal
  .
  .
  .
  802.11 header w/ 4th MAC
  data length
  ethernet header
  payload

but I omit the data length and the ethernet header, instead?

My reasoning is this: all of the useful information in a Prism header,
such as RSSI, precedes the 802.11 header. The data length and ethernet
header, which follow the header, are redundant.  When we omit the data
length and the ethernet header, the 802.11 header abuts the payload,
so the Prism header becomes a simple "encapsulation" for 802.11 frames,
instead of an oddball header type unto itself. Now we can re-use tcpdump's
802.11 code without making an ugly change to it.

Your thoughts?

Should it be a long-term goal for there to be a generic wireless
encapsulation? Let's call it DLT_WIRELESS. It might consist of a total
length and length/type/value pairs, e.g.,

   total len   len type     value     len type    value
 +-----------------------------------------------------------
 | 8           | 3 | signal | -60 dBm | 3 | noise | -90dBm | . . .
 +-----------------------------------------------------------

    len     type                              802.11 frame
    -----------------------------------------
. . . 2 | was fragmented (flag: no value) |  . . .
    -----------------------------------------

Maybe the properties of different radios' hardware-specific headers do
not overlap enough to justify DLT_WIRELESS.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933