Correctly identifying the RSSI via scapy

[stryngs]

There are many examples on Search Engines for an incorrect way to determine the RSSI strength for an 802.11 frame using scapy. According to some of the Issues I read in this project, supposedly this has been fixed. Specifically @gpotter2 mentioned this. The new field that was added, dBm_AntSignal. However, in looking at a capture just a moment ago, in RadioTap you now see things like this:
present=TSFT+Flags+Rate+Channel+dBm_AntSignal+b14+b22+b29+Ext

Convert that over to bytes [hexstr(str(f.present), onlyhex = 1)]and we get:
'54 53 46 54 2b 46 6c 61 67 73 2b 52 61 74 65 2b 43 68 61 6e 6e 65 6c 2b 64 42 6d 5f 41 6e 74 53 69 67 6e 61 6c 2b 62 31 34 2b 62 32 32 2b 62 32 39 2b 45 78 74'

No where in the above bytes do I see the byte needed for the math, aa.

It's not to say that the above bytes don't contain the information needed to ascertain the RSSI, but that I am not sure how to go about doing so; thus this post and what I am going to see if there is interest for, and will provide the code if it is.

So... How do we solve for RSSI? I did it in my repo, packetEssentials. It's broken down between a couple classes, so let me give an example:
import packetEssentials as PE
from scapy.all import *
p = sniff(iface = 'wlan0mon', count = 1)
nUni = PE.lib.unifier.Unify('wlan0mon')
In [62]: nUni.getStats(p[0])
Out[62]: {'chan': '6', 'freq': 2437, 'rssi': -87}

Why does this work where all other Search Engine methods fail? The person making the suggestion didn't try it with different drivers.... This was key to making the math work correct. If you're interested in the guts of it, check out:
https://github.com/stryngs/packetEssentials/blob/master/SRC/packetEssentials/lib/drivers.py#L5

Now, obviously I don't have offsets for all drivers, only the ones I've gotten my hands on. However, this covers a lot of the drivers in current use today.

So... What do you think about me creating a PR to pull in some of the packetEssentials code so that folks can do this in scapy without needing extra libs, or being given incorrect information?

[gpotter2]

Hi, thanks for your interest in scapy

The notdecoded field should not be used. It contains fields that are not supported. With the latest version (master on GitHub), we support nearly all attributes provided by the RadioTap documentation, with their padding.

The answers you can find on the web date back before we implemented this functionality: because every driver had different RadioTap options included, the AntSignal would pop up in different places. People tried to hack through that but it's obviously not driver compatible.

The "example" you have provided makes no sense what so ever: you are encoding scapy's human representation of the flags in Hex:

I don't see how you would get any byte needed for the math in that.

Could you fill up the issue template &/ provide a pcap the shows a field being wrongly dissected on latest master version ?

[stryngs]

Hi @gpotter2. That's just it, I don't know if the fields are being wrongly dissected. The reason I brought up the issue was because there is no clean way I know of to determine RSSI using scapy. The way that I do it, it works and works 100% of the time as it's based on offsetting depending on which driver you're using.

So let me ask this, what is the current method that you would say I should use to determine the rssi (In a format such as -46) for a given frame without using my methodology? Maybe I'm just missing the obvious here?

[gpotter2]

packet[RadioTap].dBm_AntSignal
We try to make the names in present match with the field (though that's not always the case)

(Note: this is only available in newer Scapy versions. You can use master branch if unsure)

[stryngs]

Hah, evidently I just wasn't up to date:
'Rate': 108,
'Channel': 2412,
'ChannelFlags': <Flag 192 (OFDM+2GHz)>,
'dBm_AntSignal': -33,

Very cool and glad that this has been implemented into scapy. Thank you for the feedback and patience!