Monitor mode and packet error rate?

Question

Here's my setup:

1) MacBook Pro in monitor mode with Wireshark installed. 2) A WiFi router connected to the internet 3) An iPhone, connected to the WiFi router via WPA2

I start a streaming video on the iPhone so there's data moving to the iPhone from the WiFi router.

I fire up Wireshark on the MacBook Pro.

I wrap the iPhone in aluminum foil and place it in a metal filing cabinet. I wait several seconds, take it out, unwrap the foil from the phone, wait a few seconds and then stop the Wireshark recording.

Now, what I need to do with the data is figure out how bad the signal got through the ordeal. I know while the phone was in the cabinet, it stopped communicating with the router, as there's an obvious gap in the timestamps for the packet flow. But I'd like a little bit more detail. I'd like the packet error rate as well. Can Wireshark supply this information through one of the Statistics windows and I'm just not seeing it?

Answer 1

This is an interesting test, and Wireshark can likely provide at least some more information. A couple of ideas:

1.

You could evaluate changes in signal strength (RSSI) as you manipulate the DuT (device under test). Have a look at the SSI signal field in the Radiotap header from the frames transmitted by the DuT. You could use a filter such as

wlan.ta == (mac address of DuT)

and then review the radiotap header:

Radiotap Header v0, Length 20
    Header revision: 0
    Header pad: 0
    Header length: 20
    Present flags
    Flags: 0x10
    Data Rate: 12.0 Mb/s
    Channel frequency: 2412 [BG 1]
    Channel flags: 0x00c0, Orthogonal Frequency-Division Multiplexing (OFDM), 2 GHz spectrum
    **SSI Signal: -57 dBm**
    SSI Noise: -100 dBm
    Signal Quality: 75
    Antenna: 0
    SSI Signal: 43 dB

In this case, focus on SSI Signal, and how it changes as you manipulate the device. You can add this as a column in the packet view, or even graph it (graph in the Qt version as the GTK version does not handle negative numbers gracefully).

2.

Evaluate retries - as communication degrades, the number of retries will likely increase. I would graph this, and we could do something like this filter:

wlan.addr == (mac address of DuT) and wlan.fc.retry == 1

While conditions are poor, there should be more retries.

3.

Evaluate Datarate - as communication degrades, datarate often does as well. You could graph min/max/avg datarates to/from the DuT. Something like this field name for the Y field in the graph tool, and then do a Display filter for the DuT. An example set of config items:

Y field: wlan_radio.data_rate
Display Filter:  wlan.ta == (mac address of DuT)
Y Axis: AVG(Y field)

4.

Evaluate bad frames - as communication degrades, perhaps the number of bad frames does as well. Check for FCS field and see if the number of bad frames increases to/from the DuT while communication is impaired.