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.
