On Dec 3, 2015, at 7:29 AM, Tim Furlong <dev.null.2...@gmail.com> wrote:
> One of the biggest challenges you'll face in this is that the code to parse
> radiotap is in epan/dissectors and gets compiled into libwireshark; you won't
> want to pull libwireshark in to editcap (it'd kind of defeat the purpose of
> editcap).
The code to parse radiotap could be used as the basis for code in editcap, but
that would be necessary only if the goal were to make it possible to read a
pcap or pcapng file with radiotap headers and write it out as a *Peek file, not
if the goal is to read 802.11 *Peek files and write them out as pcap or pcapng
files with radiotap headers.
> Didn't locate the airopeek code, but believe it's in libwiretap, which should
> be fine.
There are two *Peek file formats: the "classic" one and the "tagged" one. In
releases up to including 2.0, the radio information in "classic" files was
parsed in libwireshark; in the current master branch, it's parsed in
libwiretap. In 2.0 and later, radio information in "tagged" files is parsed in
libwireshark.
> Also, I don't know if there's code to generate radiotap headers,
There is.
It's in kernel-mode code in Linux, {Free,Net,Open,DragonFly}BSD, and OS X, not
in Wireshark, however.
> though I'd be inclined to follow through what wireshark does when doing a
> wi-fi capture to try and find it (well, doing the capture first to confirm
> that it.
What Wireshark does when doing a capture on any network device is "run dumpcap".
> Actually, come to think of it, if you can do wi-fi capture with dumpcap, then
> there is probably code somewhere to write radiotap without going to
> libwireshark, so you might be in luck - though you'd
What dumpcap does when doing a capture on any network device is "use
libpcap/WinPcap".
What libpcap does when doing a capture on any network device is "use the native
packet capture mechanism".
What the native packet capture mechanism does is "rely on the driver for the
network adapter".
So you won't find the code to write radiotap headers code anywhere in the
Wireshark source, including dumpcap, or in libpcap; you'll have to look at
either device drivers, or the common radiotap-writing code they use, in various
OS kernels.
> For translating from airopeek, though, as Guy indicated, you're likely going
> to do the heavy lifting on that yourself.
If the libwiretap link-layer header type is WTAP_ENCAP_IEEE_802_11_WITH_RADIO,
then programs reading packets with libwiretap, including editcap, get handed a
"pseudo-header" that contains the parsed radio metadata. In the master branch,
all AiroPeek and OmniPeek 802.11 captures will have a link-layer header type of
WTAP_ENCAP_IEEE_802_11_WITH_RADIO and will provide that pseudo-header, so what
you'd do is take the data from that pseudo-header and write it out, if
possible, as a radiotap header.
I say "if possible" because, for example, the fields
guint8 signal_percent; /* Signal level, as a percentage */
guint8 noise_percent; /* Noise level, as a percentage */
in the radio metadata pseudo-header *cannot* be written to a radiotap header;
radiotap only supports reporting signal and noise levels as dBm or as dB
relative to an arbitrary reference point, *not* as a percentage.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
