I work with packet captures from multiple wireless devices. Some of them use the radiotap headers to insert information like signal strength, channel, data rate, etc. Others use wlan headers for the same. Currently I have multiple custom columns for each, one using the radiotap headers and one with the wlan headers, and I either have both sets displaying (one being blank and taking up screen space) or I have to switch back and forth between which ones are displayed. Anyone have any ideas if there is a way to have a custom column display one of multiple field names? I haven't found a way, but it would be nice if there were a way to give a custom column multiple criteria for the field name and have the column populate with the first matched. asked 11 Apr '13, 17:40 YLearn |
One Answer:
There's currently no mechanism for doing that. What ''really'' needs to be done is to have, for at least a subset of the radio metadata, common "wlan." fields, so that, regardless of the way the radio metadata appears in the capture file, those fields will have the same field name and the same value encoding, so that display filters, custom columns, TShark -T fields/-e operations, etc. can be used independently of whether the packet has a radiotap header or an AVS header or a Microsoft NetMon header or Peek Classic radio information or Peek Tagged radio information or.... Note, of course, that some fields are supported only by some metadata mechanisms; in particular, "signal strength" might be an uninterpretable number labeled as "RSSI" (where the only thing you can say is "the bigger the number the stronger the signal" in some captures and a signal strength in dBm in other captures. Those would be different fields. answered 11 Apr '13, 18:20 Guy Harris ♦♦ |
I suspected there wasn't a way but figured I would ask as I can't be the only one in this situation. While I ideally agree with what should "really" be done, I don't see the developers of the drivers and different wireless capture tools/software getting together to agree on this anytime soon (or most likely ever).
They don't have to. Wireshark just needs to either do that in the Wiretap library (thus presenting all 802.11 packets with a collection of 0 or more radio metadata items with standard labels) or in the dissectors for various radio information (so as to provide to the 802.11 dissector a collection of 0 or more radio metadata items with standard labels), and possibly also provide the raw information (for the benefit of people who actually have a reason to look at raw headers).
I think I am on the same page as you now. Thank you for your response.