This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Graph of wlan datarate incorrect

0

I have another problem that I don't understand, I have filtered to radiotap.vht.datarate.0 and wlan.fc.type_subtype == 0x28 but the graph don't show a higher datarate (180-200 Mbit/s) as the two N devices with maximum of 150 Mbit/s:

I have another question, what is the difference between radiotap.vht.datarate.0/radiotap.vht.datarate.1/radiotap.vht.datarate.2/radiotap.vht.datarate.3/radiotap.vht.datarate.4?

asked 17 Feb '17, 00:12

Hyrrican's gravatar image

Hyrrican
6335
accept rate: 0%

converted 18 Feb '17, 02:05

grahamb's gravatar image

grahamb ♦
19.8k330206

Converted from this other question.

(18 Feb '17, 02:06) grahamb ♦

2 Answers:

0

radiotap.vht.datarate.0/radiotap.vht.datarate.1/radiotap.vht.datarate.2/radiotap.vht.datarate.3/radiotap.vht.datarate.4?

If you look at the radiotap header VHT definitions, they define a number of fields for up to four users:

The four mcs_nss fields encode MCS and NSS for up to four users

Defined are number of spatial streams, MCS index, and coding(BCC or LDPC). Based on this, I believe these fields represent MU-MIMO capabilities. Since these specific ones do not appear to be part of the defined radiotap fields, I suspect they are derived quantities from items that are present, such as MCS Index, bandwidth, guard interval, etc., which would en masse define the datarate, per the MCS Index table.

Since an AP could send data to up to four clients at the same time with MU_MIMO, and the clients could be all different with different capabilities, RF environment, etc., it seems reasonable that they could all have a different Tx rate assigned per the algorithm radios use to Tx data.

Another reference is here.

Note that your analysis can be a little bit tricky in that 802.11ac clients can send frames at max datarate, or something less, all the way down to plain-old 802.11a rates. If you are analyzing all the traffic, be careful when just looking at specific datarate fields in the header for VHT, HT, etc., because if the datarate falls for whatever reason (distance, sudden rf environment change, etc) you might miss it. This is why the

wlan_radio.data_rate

field could be of significant value - with luck it captures all the datarates into one field in which case you could then analyze just this one field.

answered 18 Feb '17, 05:23

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

@Bob Jones = This answer was already provided here:

https://ask.wireshark.org/questions/59283/data-rate-mcs-not-shown

The original question was already answered, but the user (@Hyrrican) requested assistance on another topic - namely how to graph WLAN data rates. It was decided (and rightly so) to create a new topic regarding the question about plotting WLAN data rates.

Now with all that said, below is the response (and hopefully the answer to the question) about plotting WLAN data rates in Wireshark.

(18 Feb '17, 06:11) Amato_C

@Amato,

@Bob Jones = This answer was already provided here:

Is this it?

Neither provide a very descriptive explanation. But looking at the Git hub repository, it "appears" that the difference is the number of spatial streams supported by the device??

datarate.0 = 1SS

datarate.1 = 2SS

An answer, yes, but note that my view is different. Are we allowed to have different viewpoints?

I can show with a trace that when my radio Tx frames with one or two SS that the radiotap.vht.datarate.0 field gets populated either way (as does the wlan_radio.data_rate field).

(18 Feb '17, 06:28) Bob Jones

@Bob Jones - I apologize if my response was confrontational. I was trying to explain the sequence of events that lead to this new post based on a previous post.

And of course people can have different view points! :)

(18 Feb '17, 06:41) Amato_C

@Bob Jones - I think your explanation about the different VHT datarate.x variables makes better sense than my assumption.

Having diffetent datarates for different MU-MIMO users would make better sense.

Thanks

(18 Feb '17, 07:32) Amato_C

0

You need to enter values for the 3 fields: Display Filter, Y-Axis, and Y-Field.

alt text

In the display filter, you enter the filter expression you would like to use. For example, I entered the IP address of the WiFi Client (ip.addr==192.168.0.101). The graph will only display information pertaining to the Client with IP address 192.168.0.101

The Y-axis must be selected as Max, Min or Average. Then the Y-field would be wlan_radio.data_rate

Your graph would look like something like this:

alt text

Again, this is not the optimal solution since Wireshark only graphs based on time (sec) as opposed to frame numbers.

answered 18 Feb '17, 06:23

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

Ok, now I understand how to filter min, max, avg, sorry.

@Amato but can you explain me why in my case, screenshot above, the red line (ac-device) 200 Mbit/s is lesser as the green and violet line (n-device) with maximum 150 Mbit/s? The most of the time the QoS/data packets of the ac-device are at 180-200 Mbit/s. Or is my filtering completely wrong, but I think if it's filtered so, I can see faster the collapse of the datarate.

(19 Feb '17, 23:52) Hyrrican

@Hyrrican = try using the following Display filters in the I/O graph:

(wlan.ta == d8:c4:6a:53:bd:b9)&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

Explanation:

  1. wlan.ta = this is the transmit address, it should be the MAC address of your client

  2. The remaining part of the filters ensures that only Data and QoS-Data frames are displayed while removing Null Data frames and QoS-Null-Data frames also.

The filter should be used for each WiFi client that requires analysis. For example:

Filter 1 = (wlan.ta == aa:aa:aa:aa:aa:aa)&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

Filter 2 = Filter 1 = (wlan.ta == bb:bb:bb:bb:bb:bb)&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

Filter 3 = Filter 1 = (wlan.ta == cc:cc:cc:cc:cc:cc)&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

Unfortunately, the WiFi capture you posted is encrypted and the passphrase was not provided. So I was unable to use the IP address within the filter.

If you are using a wireless mesh solution, then the filter would have to be amended to include the Source and Transmit address:

Filter 1 = ((wlan.ta == aa:aa:aa:aa:aa:aa)||(wlan.sa == aa:aa:aa:aa:aa:aa))&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

After applying the following filter:

(wlan.ta == d8:c4:6a:53:bd:b9)&&(wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12))

I observe a majority of the traffic is around 200Mbps with a spike of 360Mbps. There are some dips in throughput to 6Mbps which could be explained with EAPOL re-keying. However, there is a major dip in traffic at 136 seconds in which the client is only sending data at 6Mbps because only multicast traffic is being transmitted. Without decrypting the traffic, it is hard to say what upper-layer protocol is being used. Regardless, there is about 10-13 seconds where 6Mbps data rate is being used due to multicast traffic.

(20 Feb '17, 05:56) Amato_C

Hi Amato, thanks for explanation, I will test it. Is it also possible to filter to wlan.bssid instead of wlan.ta and wlan.sa?

(20 Feb '17, 08:20) Hyrrican
1

What are you trying to analyze?

Are you trying to analyze the transmit data rates of your AP or client? Then it is not recommended to use wlan.bssid since both WiFi Access Points and WiFi clients populate that field with the same value when the client is connected to that BSSID.

If you are interested in viewing data rates only from your client, then the wlan.ta = <client-mac-address>

If you are interested in viewing data rates only from your AP, then the wlan.ta = <ap-mac-address-for-ssid>

Are you trying to analyze bi-directional traffic? Then use wlan.bssid to view all traffic to/from that BSSID. But you have to consider that some traffic will be from the client and some from the AP. This could not be used to determine the data rate of a particular device (either AP or client).

My recommendation: DO NOT use wlan.bssid = it will lead to confusion. Use the wlan.ta and the correct MAC address.

(20 Feb '17, 13:40) Amato_C