On Dec 3, 2015, at 7:29 AM, Tim Furlong <dev.null.2007@xxxxxxxxx> 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.