hello, i wanted to know how is wireshark able to capture packets of another computer and how is it able to calculate the rssi values of the packets. where is the rssi value stored in the computer and in which frame format is it saved??thank you.. asked 05 Oct '16, 21:17  misbah |
One Answer:
To capture on air, you need a wireless network adapter for which a driver exists for your operating system which supports monitoring and promiscuous mode at the same time. This is currently only sure for Mac, on Windows and Linux you have to carefully choose the hardware and drivers. On Windows, you need a release of NPcap which supports monitoring mode on top of the above. Plus there are some further issues related to 802.11 modes supported for normal operation and for monitoring mode. The driver in monitoring mode normally provides a radiotap or other (e.g. TZSP) pseudo-header which, among other metadata related to the captured 802.11 frame, contains the RSSI value as your network adapter has measured it at the moment of capturing the frame. Wireshark shows you the value twice - once in the dissector of the pseudo-header itself, second time in the "802.11 radio information" set of fields which is always the same regardless what pseudo-header they've arrived in. answered 06 Oct '16, 03:18  sindy edited 06 Oct '16, 03:18 |
Totally agree with @Sindy, here is a screenshot of RSSI value presented in a beacon frame captured with a wireless adapter in monitor mode.
...unless the particular packet file format keeps radio information separate from packet data; pcap, pcapng, and Network Monitor files don't, they have a pseudo-header at the beginning of the packet data, but the {Airo,Omni}Peek formats from WildPackets^WSavvius do keep them separate.
The "802.11 radio information" section (which is new in 2.2) is probably the best place to look for radio information in most cases, as it's not cluttered up with the details of the pseudo-header.
@Guy
The screenshot is from an Omnipeek capture (pkt file) opened in Wireshark and it has the radio information in the header. This is good - but when I try to subset the capture the file and either SaveAs or Export in Wireshark, I lose this information. From your comment, I think I now know why. Is there a format I can move to when subsetting in Wireshark to allow me to keep the radio information?
@Bob Jones, the precise meaning of "header" matters here.
In the narrow sense, it is part of the actual packet data (i.e. it can be actually captured on the wire or in the air) which contains the overhead data of a protocol layer - such as an IP header or a TCP header.
In a wider sense, it may also be some information prefixed to the actual captured data into the container intended to carry the captured data because the capture format doesn't provide any other container for that information. This is the case of radiotap or TZSP "headers", and where distinction is important, this type of "header" is called a "pseudo-header", just as @Guy Harris refers to it above.
Only in the widest sense (which you have used above) it is the information which is relevant to a single particular packet, regardless how it is transported or encapsulated. Some formats, such as pcapng or the Airo/Omnipeek formats, provide for logical separation between actual captured data and the metadata which are related to the packet but not part of its actual contents.
The
802.11 radio informationpart of the dissection tree is a unified view of the radio related information regardless how it is stored in the capture file.Unfortunately, no pcapng extension (similar to the epb_flags option to the Enhanced Packet Block) has been proposed yet to accommodate the radio related information. So as of current, Wireshark would have to either change the contents of each packet by prefixing it with a pseudo-header and migrating the radio related data there, or use the Airo/OmniPeek format directly, to be able to export these data along with the packets.
BTW, similar situation exists for other types of metadata - namely, in the mobile networks area where bandwidth efficiency is one of primary design constraints, the packet data itself are not enough to identify the protocol, so automated identification is only possible if the necessary information is available as metadata in the capturing analyzer's own capture file. Here again Wireshark cannot export data without losing this information or without learning to write the complete original format.
Filing an enhancement bug for adding a radio-related Option to pcapng draft proposal and handling it in Wireshark might be the cleanest way to get the ability to export packets from Airo/OmniPeek without losing the radio-related information.