Piotr Kaczorek | 31 May 2012 15:03
Picon
Favicon

Retrieving RSSI from WiFi packets

Hello,

How can I get RSSI/signal strength information from sniffed WiFi packets?

I wan't to get info about it from 'nearby devices' even if they were 
only 'searching for hotspot' (Probe request).
WiFi card I have is based on Prism ISL3886 (if that matters).

I've found that when I used kismet (on other device - laptop with Intel 
iwl4965 WiFi and laptop with Realtek RTL8188CE WiFi) the signal strength 
is stored in PPI -> 802.11-Common

I cant see this layer/Class in the scanned packet. Is there some 
'special way' to get it?

example packet.show2():
###[ RadioTap dummy ]###
   version= 0
   pad= 0
   len= 14
   present= Flags+Rate+Channel
   notdecoded= '\x00\x02v\t\x80\x04'
###[ 802.11 ]###
      subtype= 4L
      type= Management
      proto= 0L
      FCfield=
      ID= 0
      addr1= ff:ff:ff:ff:ff:ff
      addr2= 00:1c:a4:6a:e8:64
(Continue reading)

Joshua Wright | 31 May 2012 15:50
Favicon

Re: Retrieving RSSI from WiFi packets

On 5/31/2012 9:03 AM, Piotr Kaczorek wrote:
> How can I get RSSI/signal strength information from sniffed WiFi packets?

> example packet.show2():
> ###[ RadioTap dummy ]###
> version= 0
> pad= 0
> len= 14
> present= Flags+Rate+Channel
> notdecoded= '\x00\x02v\t\x80\x04'

I'm pretty sure it's in the "nodecoded" content.  Grab a packet capture 
while processing with Scapy and look at the decoded RadioTap header in 
Wireshark.  You can slice the nodecoded string data and turn it into an 
integer as needed.

-Josh

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Piotr Kaczorek | 31 May 2012 21:32
Picon
Favicon

Re: Retrieving RSSI from WiFi packets

Thanks Josh,

You are right.

But there is something wrong/missing in my monitor interface configuration.
After running kismet the interface which I ran kismet on starts showing 
signal strength information. But not before (even though It's set it to 
monitor mode by hostapd).

That's how it looks like when the interface is set as it should:
###[ RadioTap dummy ]###
   version= 0
   pad= 0
   len= 26
   present= TSFT+Flags+Rate+Channel+dBm_AntSignal+Antenna+b14
   notdecoded= 
'8`/\x08\x00\x00\x00\x00\x10\x02\x94\t\xa0\x00\xdb\x01\x00\x00'
...

I have to find the 'difference' in the config before/after kismet and 
set it properly (I don't want to/can't use kismet every time).
Anybody got an idea what might be wrong?

W dniu 31.05.2012 15:50, Joshua Wright pisze:
>
> I'm pretty sure it's in the "nodecoded" content.  Grab a packet 
> capture while processing with Scapy and look at the decoded RadioTap 
> header in Wireshark.  You can slice the nodecoded string data and turn 
> it into an integer as needed.
>
(Continue reading)

Joshua Wright | 31 May 2012 21:52
Favicon

Re: Retrieving RSSI from WiFi packets

On 5/31/2012 3:32 PM, Piotr Kaczorek wrote:
> But there is something wrong/missing in my monitor interface configuration.
> After running kismet the interface which I ran kismet on starts showing
> signal strength information. But not before (even though It's set it to
> monitor mode by hostapd).
>
> That's how it looks like when the interface is set as it should:
> ###[ RadioTap dummy ]###
> version= 0
> pad= 0
> len= 26
> present= TSFT+Flags+Rate+Channel+dBm_AntSignal+Antenna+b14
> notdecoded= '8`/\x08\x00\x00\x00\x00\x10\x02\x94\t\xa0\x00\xdb\x01\x00\x00'
> ...
>
> I have to find the 'difference' in the config before/after kismet and
> set it properly (I don't want to/can't use kismet every time).
> Anybody got an idea what might be wrong?

Don't use Kismet to take your packet captures.  Kismet re-writes packet 
captures into its own format in the .pcapdump file.  Use "tcpdump -ni 
mon0 -s0 -w out.pcap" while you are running Scapy, then view out.pcap in 
Wireshark to compare your results.

-Josh

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

(Continue reading)

Piotr Kaczorek | 31 May 2012 23:51
Picon
Favicon

Re: Retrieving RSSI from WiFi packets

I decided to set up interface to monitor mode with airmon.

I've checked the packet contents with 'raw' tcpdump.
I know that now the signal strengths are there (saw them in tcpdump 
+scapy shows longer 'present' list with +dBm_AntSignal+ and the 
notdecoded line is longer).

Now I only have to decode the 'notdecoded' part of packet.

Is there some easy way to decode this information from hex (actually I 
need this single value)?

W dniu 31.05.2012 21:52, Joshua Wright pisze:
> On 5/31/2012 3:32 PM, Piotr Kaczorek wrote:
>> But there is something wrong/missing in my monitor interface 
>> configuration.
>> After running kismet the interface which I ran kismet on starts showing
>> signal strength information. But not before (even though It's set it to
>> monitor mode by hostapd).
>>
>> That's how it looks like when the interface is set as it should:
>> ###[ RadioTap dummy ]###
>> version= 0
>> pad= 0
>> len= 26
>> present= TSFT+Flags+Rate+Channel+dBm_AntSignal+Antenna+b14
>> notdecoded= 
>> '8`/\x08\x00\x00\x00\x00\x10\x02\x94\t\xa0\x00\xdb\x01\x00\x00'
>> ...
>>
(Continue reading)

Piotr Kaczorek | 1 Jun 2012 13:23
Picon
Favicon

Re: Retrieving RSSI from WiFi packets

This definately isn't bulletproof (and not 'elegant') but for now I will 
use:
sig_str = -(256-ord(packet.notdecoded[-4:-3]))

Theese bytes seem to give me number shown by wireshark/tcpdump as the 
signal value.

Thank you for help Joshua

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org


Gmane