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

11ac capture from macbook pro

0

I am noticing that phy rates are not always being decoded properly and wondered if there was a fix in the works. iPhone 5S supports and is connected to 40MHz channel but only reports PHY RATE of 72.2, which is not correct. There are also other times when it doesnt report any rates at all.

Thoughts? I have tried PPI and RadioTap.

asked 12 Feb '14, 09:43

ericsr's gravatar image

ericsr
11112
accept rate: 0%

The rate field in radiotap and the rate field in the PPI specification are both numbers in units of .5 Mb/s, and thus can't represent a PHY rate of 72.2 Mb/s (72.2 Mb/s is not a multiple of .5 Mb/s). Are you referring to a PHY rate reported somewhere other than the radiotap or PPI header?

(12 Feb '14, 16:26) Guy Harris ♦♦

See attachment

(12 Feb '14, 16:43) ericsr

alt text

(12 Feb '14, 16:43) ericsr

One Answer:

0

UPDATE: having looked at the capture attached to the bug, the VHT field is not present, so either:

1) the traffic is NOT 11ac traffic - if it's coming from the iPhone 5s, either it's not 11ac traffic, or Apple isn't telling the entire truth when they say, on their iPhone 5s tech specs page, that the 5s supports "802.11a/b/g/n Wi-Fi (802.11n 2.4GHz and 5GHz" and don't mention 11ac

or

2) it's 11ac traffic but the driver in the OS is reporting it as 11n traffic (the MCS field is present).

OK, that's not coming from the radiotap Rate field, it's looked up in a table using the MCS rate index, bandwidth, and guard interval length, from the radiotap MCS field, as indices. The table comes from information in section 20.6 "Parameters for HT MCSs" in the 802.11 spec.

I think the VHT field in the radiotap header is for 11ac.

If the driver for the adapter in the version you're using of the OS you're using (Mountain Lion or Mavericks, probably, in your case, but similar stuff would need to be done for Linux and *BSD, for example) supplies the VHT field, then there is code in Wireshark 1.10.x to handle that field. If it's not calculating the correct data rate, either the driver isn't supplying the right VHT field values or isn't supplying them at all, in which case you'd have to ask Apple whether there's a fix in the works, or the rate isn't being calculated correctly from that field value, in which case Wireshark would need to be changed.

If the driver is not supplying the VHT field, but is supplying the MCS field, then Wireshark is doing the best that it can, and you'd have to ask Apple whether there's a fix in the works.

If you're not running the latest wireshark 1.10.x release (currently 1.10.5), upgrade to it, and see if that fixes the problem.

If that doesn't fix it, you should file a bug on the Wireshark Bugzilla on this, and attach a raw capture file (not a screenshot of Wireshark's display of the capture file) containing a packet showing the problem. (If it was captured on a protected network - WEP or WPA/WPA2-encrypted - you do NOT need to supply the password for the network; we don't need any information other than the radiotap header information.)

answered 12 Feb '14, 18:13

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

edited 13 Feb '14, 10:35

Appears to only happen on 80MHz channelization. I am now on 40 and it displays properly. I have entered a bug.

(12 Feb '14, 18:23) ericsr

You're not going to get 80 MHz channelization, or anything else 11ac, with your iPhone - the iPhone 5s only supports 802.11a/b/c/n, not 802.11ac, according to Apple's tech specs page for the 5s. You can get data rates higher than 72.2 with 11n; are the data rates for 802.11n packets correct, or are there problems with them as well?

(12 Feb '14, 18:42) Guy Harris ♦♦

We'll need some captures, containing problematic packets, attached to the bug. (You can just make small captures containing only the problematic packets and, if the packets are from a protected network, using WEP or WPA/WPA2, you do not need to supply the password for the network - we only need to look at the radiotap header, not the packet data.)

(12 Feb '14, 19:30) Guy Harris ♦♦