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

Radio tap header: wrong channel width and guard interval

0

I have my own Atheros-chipset based 802.11n Access Point (AP) setup, where I can control what capabilities are advertised to the clients. I run a iperf session between the AP (hosted on a Laptop) and a 802.11n smartphone. Also, I capture a trace of all packets received at the AP (hosted on a Laptop) from the smartphone. I notice some discrepancies in the radio tap header reported by wireshark, in the captures packets. For example:

  1. If I fix the capability to 20MHz channel width with long guard interval, I still see some (around 10%) of the packets wtih 40MHz channel width and/or short guard interval.
  2. If fix the capability to 40MHz channel width with long guard interval, I see almost all (around 85%) packets with 20MHz channel width.

The reason I believe this is a wireshark bug is that the throughput reported by iperf in case 2, is higher that what is at all possible (even theoretically), if 85% of the packets are sent at 20MHz data rates. So, most likely wireshark is reporting the channel width incorrectly.

Is this a known problem? Has anybody else seen this issue before?

Has anybody experienced issues even remotely related to this?

asked 20 Mar '15, 18:33

UBWiNS's gravatar image

UBWiNS
6113
accept rate: 0%

edited 10 Apr '15, 17:22

What does tcpdump report? If it reports the same thing, it's probably a driver bug, with Wireshark and tcpdump both just reporting what they're told.

(10 Apr '15, 19:59) Guy Harris ♦♦

One Answer:

0

Hello UBWiNS - I have experienced something very similar to your observations regarding the radiotap parameters. I have observed incorrect radiotap settings using numerous WiFi adapters each using different drivers. Recently, I have experimented with analyzing 2.4GHz traffic to determine if the traffic is being sent is 802.11b-only, 802.11g-only or 802.11b/g mixed. The following radiotap headers can be used to distinguish between each traffic type: (1) 2 GHz spectrum channel and CCK channel = 802.11b (2) 2 GHz spectrum channel and OFDM channel = pure 802.11g, no 802.11b STA's present (3) 2 GHz spectrum channel and Dynamic CCK-OFDM channel = 802.11g traffic with 11b STA's present. I set-up a WLAN using 802.11b-only access. When I connected a STA and examined the radiotap parameters within WLAN frames from the STA to the AP and vice-versa I observed the following parameters set: a) 2GHz spectrum channel- as expected b) Most traffic was marked as OFDM. According to the IEEE 802.11-2012 specification, sections 16 and 17, 802.11b can only be transmitted using DSSS/CCK modultation. So the OFDM parameter was incorrectly being set. I also confirmed that all the traffic was sent at 11b rates (1, 2, 5.5 or 11Mbps). I think this is a driver issue because another WiFi adapter/driver combination had the correct settings.

answered 13 Apr '15, 07:17

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%