Rahim Shariff wrote:
> I'm using the latest windows binary for tethereal to parse cap files. The
> detail information I get does not print out the noise or signal bpm. It
> does print out data rate and signal %. I looked in the packet-ieee80211.c
> file, and apparently the radio headers aren't even looking for the noise
> or signal bpm information - they just parse info on data rate, channel,
> and signal from the radio headers.
>
> A while back Chris Waters submitted a patch to print the additional radio
> header info:
>
> http://ethereal.ntop.org/lists/ethereal-dev/200206/msg00031.html
>
> Has this code been accepted into the main branch?
No. Read the entire thread for the reasons why.
There's no such thing as "*the* additional radio header info". There
isn't some single "standard" radio header. There are several different
radio headers.
There are three that have been assigned libpcap link-layer type values
(Prism, AVS, radiotap), so that they can appear in libpcap files; those
are all supported by libpcap, tcpdump, and Ethereal.
There are also radio headers that appear in some non-libpcap capture file
formats. Ethereal can read some of those - AiroPeek (old and "V9" file
formats) and Sniffer Wireless. There might be others, but nobody's
supplied us with code to read others, or with captures in those other
formats + either a specification for the format or dissected versions of
those captures for reverse engineering.
What program generated the capture files you're trying to read?
If it's a program on Linux or BSD that uses libpcap format, such as
tcpdump or Ethereal, *AND* radio headers were enabled when capturing,
Ethereal should be showing you the radio information.
If it's AiroPeek or Sniffer Wireless, Ethereal should be showing you the
radio headers *IF* the file is written in a format Ethereal knows how to
read.
if it's none of those, you'd have to either implement code to read them,
or send us some captures along with either a document describing the file
format (including the radio header format) or decoded versions of those
captures from the program that generated them so we could write that code.
(Chris's patch did not include *any* changes to the code to read capture
file formats, so it wouldn't make any difference in Ethereal's ability to
interpret radio headers, as there was no code in his patch to *produce*
the headers his code was interpreting, as I noted in my followups in the
thread.)
(Were we to generalize the WTAP_ENCAP_IEEE_802_11_WITH_RADIO header, we'd
probably just rip off the radiotap header, as it includes most of the
items in Chris's code plus many others, and could have the "FCS error"
flag and "could not be decrypted by MAC" flags added.
Having recently taken the pcap-to-Wiretap conversion out of the capture
code path, at some point I'd like to have a single Wiretap encapsulation
for 802.11+radio, and use a radiotap format for the radio information,
with Wiretap mapping Prism, AVS, AiroPeek, Sniffer Wireless, etc. to
radiotap format when reading and mapping from those formats on writing,
although that does mean that we'd write out only radiotap format for
libpcap - I'd argue that's a feature, not a bug - and would have to figure
out something to do about missing fields in those files where the radio
header isn't tagged.)
