I am monitoring Wi-Fi probe requests via tcpdump on Debian and am trying to capture the RSSI (signal strength) of each probe request element. Currently, the output from tcpdump for each probe request looks like this:

09:13:17.663057 BSSID:Broadcast DA:Broadcast SA:04:fe:31:67:32:a0 (oui Unknown) Probe Request () [1.0 2.0 5.5 11.0 Mbit]

It is missing signal strength and some other elements.

Using another machine with the same version of tcpdump/libpcap and the same arguments to tcpdump, the output includes signal strength (shown below)

09:14:51.673753 6.0 Mb/s 2412 MHz 11g -71dB signal antenna 1 BSSID:Broadcast DA:Broadcast SA:b2:b2:b2:b2:b2:b2 (oui Unknown) Probe Request (11n-AP) [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]

Can anyone explain why the RSSI is missing from data payload on the first device and is there any way to capture it?

Per a request from @Spiff, here is a hex dump of one of the packet captures.

12:44:40.226564 BSSID:Broadcast DA:Broadcast SA:00:1e:8f:93:3f:60 (oui Unknown) Probe Request (pagefarm) [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
        0x0000:  4400 0000 9000 0000 7261 3000 0000 0000  D.......ra0.....
        0x0010:  0000 0000 0000 0000 4400 0100 0000 0400  ........D.......
        0x0020:  c79d 0300 4400 0200 0000 0000 0000 0000  ....D...........
        0x0030:  4400 0300 0000 0400 0300 0000 4400 0400  D...........D...
        0x0040:  0000 0400 b1ff ffff 0000 0000 0000 0000  ................
        0x0050:  0000 0000 4400 0600 0000 0400 0000 0000  ....D...........
        0x0060:  4400 0700 0000 0400 0000 0000 4400 0800  D...........D...
        0x0070:  0000 0400 0200 0000 4400 0900 0000 0000  ........D.......
        0x0080:  0000 0000 4400 0a00 0000 0400 3500 0000  ....D.......5...
        0x0090:  4000 0000 ffff ffff ffff 001e 8f93 3f60  @.............?`
        0x00a0:  ffff ffff ffff 4022 0008 7061 6765 6661  ......@"..pagefa
        0x00b0:  726d 0108 0204 0b16 0c12 1824 0301 0332  rm.........$...2
        0x00c0:  0430 4860 6c                             .0H`l
  • Which OS is the second computer using?
    – heavyd
    May 15, 2015 at 14:33
  • Which command, exactly, do you use in this case? I use: tcpdump -n -e -tttt -vvv -i moni0 -s 0 -w moni0.dump "link[0] == 0x80" which logs to a file called moni0.dump tcpdump's output, for an interface in monitor mode. This works fine for me, and I do not any other way to do this. May 15, 2015 at 14:37
  • Both running Debian, the second machine that displays signal strength does have a slightly newer kernel version.
    – kittyhawk
    May 15, 2015 at 14:45
  • I use the command "tcpdump -l -n -e -tttt -vvv -I ra0 -s 0 type mgt subtype probe-req"
    – kittyhawk
    May 15, 2015 at 14:46
  • 1
    ...and tcpdump, the "tcp" in its name nonwithstanding, captures packets at layer 2, and, as Spiff said, Wi-Fi drivers often include the layer-1 radio information in packets supplied to packet capture mechanisms as well.
    – user164970
    May 15, 2015 at 17:08

1 Answer 1


[Updated with all the findings from our troubleshooting.
Thanks to tcpdump/libpcap/Wireshark maintainer extraordinaire Guy Harris.]

tcpdump only understands the "Radiotap" (a.k.a LINKTYPE_IEEE802_11_RADIOTAP, a.k.a DLT_IEEE802_11_RADIO) radio meta-data header format data link type for 802.11 monitor mode.

The IEEE802_11_RADIO DLT tells the card/driver to prepend each received frame with an extra "fake" header full of radio meta-data. This is stuff that wasn't transmitted as bits on the air, but was instead read from the state of the radio at the time it received that frame. This information includes the RSSI, the channel the radio was tuned to, the data rate/MCS of the packet, and possibly much more.

If your card & driver support Radiotap, you can specify that you want to capture in this mode by adding -y IEEE802_11_RADIO to your tcpdump arguments. You can get a list of supported data link types for your ra0 interface with tcpdump -i ra0 -IL, or possibly with tcpdump -i ra0 -D. Note that the monitor mode DLTs might not appear if you don't include the -I to specify monitor mode. Note also that adding -I to put the interface into monitor mode might not work on all systems, so you may need to use the airmon-ng script in the aircrack-ng open source software package to turn monitor mode on.

It looks like the Ralink driver/chipset on the non-working machine doesn't support Radiotap headers. It apparently only supports the deprecated Prism header format, and a lesser-known variant of Prism headers at that.

You could confirm this theory by checking the DLT of the interface on the working machine (when in monitor mode) using the commands above, and confirming that it's IEEE802_11_RADIO.

If confirmed, this means your options come down to things like:

  • Update the driver on your non-working machine to make it match the driver on your working machine. Apparently the driver on the working machine supports Radiotap headers. Since you say both machines have the same model USB Wi-Fi adapter, hopefully both adapters truly have the same Wi-Fi chipset inside, so the better driver will work.
  • Use Wireshark (or the included command-line tool tshark) to do your monitor mode packet captures on the machine with the problem. Wireshark and tshark should know how to parse the variant Prism headers that the "bad" driver supports.
  • Capture the link-layer headers with tcpdump and parse out the RSSI of the variant Prism header yourself. It will most likely be the little-endian SInt32 at offset 0x44 (decimal 68). It would be more reliable to look for the sequence 4400 0400 0000 0400 and then take the next 4 bytes and consider them an SInt32. In your example captured header, the RSSI value looks like: b1ff ffff. That would be 0xffffffb1, which is the 32-bit two's complement signed integer representation of -79, which is a valid RSSI for a poor-but-still-workable signal strength.
  • Use tcpdump to capture to a file on the problem machine, but analyze them afterwards using Wireshark or tshark on another machine.
  • etc.
  • tcpdump -i ra0 -D will show what DLTs are available on ra0.
    – user164970
    May 15, 2015 at 17:03
  • Note that -I might not work, in which case the workaround is to use the airmon-ng script in aircrack-ng to turn monitor mode on. Your distribution may already have a package for aircrack-ng.
    – user164970
    May 15, 2015 at 17:06
  • When I issue tcpdump -I ra0 -IL I only see a data link type of PRISM_HEADER (802.11 plus Prism header). Is there any way to get additional DLTs onto my system?
    – kittyhawk
    May 15, 2015 at 17:34
  • @kittyhawk Twice now you've reported your arguments to tcpdump and both times you wrote a capital I instead of a lower-case i in the place where you'd need to put a lower-case i to specify an interface. It makes me suspect you're doing it wrong on your actual machine.
    – Spiff
    May 15, 2015 at 18:31
  • Sorry, I am using a lowercase i in my argument. I think autocorrect must have changed it to an uppercase when I was typing it into the comment field.
    – kittyhawk
    May 15, 2015 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.