0

I am trying to sniff 802.11 packets on the Wi-Fi device in monitor mode. I am getting erroneous output. It is confirmed that I have to use link layer type as DLT_IEEE_802_11_RADIO (127). I am not getting the exact packet format as I have got for ethernet. I want to take MAC address and RSSI values from those packets.I am doing my code in C++. Can I know how do I access these values.

dfordevy
  • 161
  • 1
  • 15

1 Answers1

0

DLT_IEEE_802_11_RADIO

The tcpdump.org link-layer header types page says of LINKTYPE_IEEE802_11_RADIOTAP/DLT_IEEE802_11_RADIO:

LINKTYPE_IEEE802_11_RADIOTAP 127 DLT_IEEE802_11_RADIO Radiotap link-layer information followed by an 802.11 header.

The page linked to describes what the radiotap header looks like. It's somewhat complicated, so your code to handle it will be somewhat complicated, although if all you want is a signal strength indicator, that will be easier to do.

The signal strength will either be strength in dBm, i.e. decibels from 1 milliwatt, or strength in dB from some unspecified arbitrary reference point. Neither of those are "RSSI" as mentioned in the 802.11 specification, as they can be negative, but they're potentially more useful than "RSSI" as mentioned in the 802.11 specification, as all the 802.11 "RSSI" lets you do is compare whether one signal is stronger or weaker than another, you can't determine how much stronger or weaker it is or how much power the signal is.

Following the radiotap header is an 802.11 header. To find MAC addresses, see section 8 of the 802.11 standard. Note that there are more than two MAC addresses in many frames, because hosts don't necessarily send packets directly to other hosts, they might send them to an access point that forwards the packet to the destination host.

  • Thanks you Harris. This helped me a lot. I am done with the code.Just one problem seems to occur, some bits of MAC are altered. For eg. the MAC 80:AA:FC:89:03:BA is shown as 80:A8:FC:89:03:BA. Are there any possibilities of getting errorneous bits from WiFi packets? – dfordevy Jul 31 '13 at 04:35
  • "Are there any possibilities of getting errorneous bits from WiFi packets?" Yes, if you're capturing in monitor mode; in monitor mode, the adapter might provide to the host packets that have been damaged before they're received (perhaps by your microwave oven :-)), even if, as a result of the damage, the CRC reveals that they're damaged. The radiotap header might indicate that the packet had an invalid CRC, and Wireshark might do so as well. –  Jul 31 '13 at 08:42
  • I am not using Wireshark. I am developing my own API. How can I do the CRC? Is there any API of libpcap that will provide me only non-erroneous packets – dfordevy Jul 31 '13 at 11:38
  • "How can I do the CRC?" For the radiotap header, see [the radiotap Web site](http://www.radiotap.org) and [the radiotap Flags field](http://www.radiotap.org/defined-fields/Flags), and its "frame failed FCS check" flag. For checking it yourself, see, for example, the Wireshark source code, which includes functions to check CRC-32 as used in Ethernet, Wi-Fi, etc. –  Jul 31 '13 at 19:00
  • "Is there any API of libpcap that will provide me only non-erroneous packets?" No, there isn't. –  Jul 31 '13 at 19:01
  • Even for the MAC Address errors it is not raising the flags for BAD-FCS. What I can do to resolve those? – dfordevy Aug 05 '13 at 10:27
  • Can I set the filter based on SSID? – dfordevy Aug 05 '13 at 10:27