Hi,
I just noticed the 802.11 radio header encapsulation that was added in the
last release. This is a great idea, however it falls short of meeting all of
the possible requirements for radio information. For example, it doesn't
include information about the silence level, SNR, FCS errors, etc that some
drivers might support.
I would like to suggest that the current encoding be replaced with a more
general purpose tag-length-value encoding. With this technique, driver
implementors can supply all of the information that the radio can provide in
a header, and even if the version of Ethereal that a user is running cannot
interpret all of the header, the rest of the decode will still work.
Some fields that would be of interest are (based on my PRISM driver):
* Frame type
* Whether frame was received during CF period
* Whether the frame is undecrypted
* Whether the frame contains an FCS error
* Rate
* Signal level
* Silence level
* Channel
I have written an encapsulation protocol for these fields, but it is not TLV
based. I much prefer the idea of making it general purpose and TLV based so
that it could be integrated with the 802.11 dissector and used by all
radios.
Regards,
Chris.