Multiple Channel types and MCS missing

Question

Hi, Why are they multiple channel types in my packet capture?

I have this one: Channel type: 802.11a (0x0140), Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum

and this one

Channel type: 802.11n (ht20, 5 GHz) (0x00010140), Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum, HT Channel (20MHz Channel Width)

And how come there is no MCS info?`

      1 0.000000       d0:84:b0:70:bd:8d     8c:29:37:e8:29:34     802.11   347    QoS Data, SN=2412, FN=0, Flags=.p....F..
Frame 1: 347 bytes on wire (2776 bits), 347 bytes captured (2776 bits)
Radiotap Header v0, Length 52
    Header revision: 0
    Header pad: 0
    Header length: 52
    Present flags
    MAC timestamp: 429790384
    Flags: 0x14
        .... ...0 = CFP: False
        .... ..0. = Preamble: Long
        .... .1.. = WEP: True
        .... 0... = Fragmentation: False
        ...1 .... = FCS at end: True
        ..0. .... = Data Pad: False
        .0.. .... = Bad FCS: False
        0... .... = Short GI: False
    Channel frequency: 5260 [A 52]
    Channel type: 802.11a (0x0140), Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz spectrum
    SSI Noise: -89 dBm
    Antenna: 1
    Channel number: 52
    Channel frequency: 5260
    Channel type: 802.11n (ht20, 5 GHz) (0x00010140), Orthogonal Frequency-Division Multiplexing (OFDM), 5 GHz Spectrum, HT Channel (20MHz Channel Width)
    A-MPDU status
        A-MPDU reference number: 2412
        A-MPDU flags: 0x0004
            .... .... .... ...0 = Driver reports 0-length subframes in this A-MPDU: False
            .... .... .... ..0. = This is a 0-length subframe: False
            .... .... .... .1.. = Last subframe of this A-MPDU is known: True
            .... .... .... 0... = This is the last subframe of this A-MPDU: False
            .... .... ...0 .... = Delimiter CRC error on this subframe: False
    VHT information
        Known VHT information: 0x1ff
            .... .... .... ...1 = STBC: True
            .... .... .... ..1. = TXOP_PS_NOT_ALLOWED: True
            .... .... .... .1.. = Guard interval: True
            .... .... .... 1... = SGI Nsym disambiguation: True
            .... .... ...1 .... = LDPC extra OFDM symbol: True
            .... .... ..1. .... = Beamformed: True
            .... .... .1.. .... = Bandwidth: True
            .... .... 1... .... = Group ID: True
            .... ...1 .... .... = Partial AID: True
        .... ...0 = STBC: Off
        .... ..1. = TXOP_PS_NOT_ALLOWED: True
        .... .1.. = Guard interval: short (1)
        .... 0... = SGI Nsym disambiguation: False
        ...0 .... = LDPC extra OFDM symbol: False
        ..0. .... = Beamformed: False
        Bandwidth: 80 MHz (4)
        User 0: MCS 9
            1001 .... = MCS index 0: 9 (256-QAM 5/6)
            .... 0010 = Spatial streams 0: 2
            Space-time streams 0: 2
            Coding 0: LDPC (1)
            [Data Rate: 866.6 Mb/s]
        Group Id: 0
        Partial AID: 0
IEEE 802.11 QoS Data, Flags: .p....F..
    Type/Subtype: QoS Data (0x0028)
    Frame Control Field: 0x8842
        .... ..00 = Version: 0
        .... 10.. = Type: Data frame (2)
        1000 .... = Subtype: 8
        Flags: 0x42
            .... ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x02)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .1.. .... = Protected flag: Data is protected
            0... .... = Order flag: Not strictly ordered
    .000 0000 0011 0000 = Duration: 48 microseconds
    Receiver address: Apple_e8:29:34 (8c:29:37:e8:29:34)
    Destination address: Apple_e8:29:34 (8c:29:37:e8:29:34)
    Transmitter address: 00:84:b0:70:bd:9c (00:84:b0:70:bd:9c)
    Source address: Sagemcom_70:bd:8d (d0:84:b0:70:bd:8d)
    BSS Id: 00:84:b0:70:bd:9c (00:84:b0:70:bd:9c)
    .... .... .... 0000 = Fragment number: 0
    1001 0110 1100 .... = Sequence number: 2412
    Frame check sequence: 0xb7c2ac4a [incorrect, should be 0x464e2f60]
        [Good: False]
        [Bad: True]
    Qos Control: 0x0000
    CCMP parameters
        CCMP Ext. Initialization Vector: 0x0000000009B2
        Key Index: 0
Data (257 bytes)

Answer 1

1

The Radiotap information is provided by the driver. I have seen many drivers provide the incorrect information for the Radiotap header. However, your driver is providing some very good information for example:

MCS index 0: 9 (256-QAM 5/6) - MCS for 11ac
Guard interval: short (1)
Spatial streams: 2 Space-time streams
Bandwidth: 80 MHz - Bandwidth only used in 11ac

Using the above information, we can calculate that your link speed = 866.7Mbps And your WiFi driver is reporting = Data Rate: 866.6 Mb/s

So you have all the information in the packet. Yes it is hidden, but it is there.

answered 04 Jun '15, 13:00

Amato_C
1.1k●14●20●32
accept rate: 14%

How do I see what the driver version is and where it is? I have different MacBook models and I get different information back, and it's making difficult to interpret the data. :(

(04 Jun '15, 19:08) Joe C

Any idea why certain frames have an actually MCS info tab and some don't? I think QOS Data has it (sometimes)

(04 Jun '15, 19:10) Joe C

How do I see what the driver version is and where it is?

Not clear. Selecting "About This Mac" from the Apple menu, clicking the "More Info..." button in its dialog, clicking on "System Report..." in the new dialog, and selecting "Wi-Fi" under "Network" will give you the hardware, but, on my machine, it just reports it as "AirPort Extreme (0x14E4, 0xEF)" with the firmware being "Broadcom BCM43xx 1.0", but that's not good enough to figure out which kext in /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns" is the driver for the adapter on my machine.

(05 Jun '15, 03:20) Guy Harris ♦♦

Any idea why certain frames have an actually MCS info tab and some don't?

Beacons are generally sent out using classic 802.11 - no, not even 802.11b, much less 11g, 11a, 11n, or 11ac) - so that all stations can see the network. Those won't have MCS information, as there's no MCS information to have. If you capture in monitor mode, you'll probably see a significant number of beacons.

(05 Jun '15, 09:24) Guy Harris ♦♦

Answer 2

1

Part of the problem here is that Apple are "helpfully" providing both a Channel field and an XChannel field in the radiotap header. The first of those is the one that says it's 11a; the second of those says it's 11n.

However, 11n is "HT", or "High Throughput"; the "VHT", or "Very High Throughput", information says it's 11ac.

Either the radiotap dissector can show all the raw radiotap information, or it can try to digest it and ignore, for example, older radiotap fields that can't handle 11n or 11ac if there are also newer radiotap fields that indicate that it's using a later standard. Perhaps there should be better way of presenting radio metadata, e.g. pass a cleaned-up version to the 802.11 dissector and have it present the cleaned-up version, and let the user open up the radiotap header if they want to see the raw metadata (bearing in mind that it may have somewhat self-contradictory information).

answered 04 Jun '15, 17:26

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

So how does one discern what the correct mode is?

(04 Jun '15, 19:06) Joe C

must you use radiotap info? For me it worked better with Per Packet Information.

(04 Jun '15, 23:29) Christian_R

So how does one discern what the correct mode is?

Unfortunately, you have to look at several items and deduce it from that, the way Amato_C and I did. As I said in the third paragraph in my answer, Wireshark should really do a better job here.

(05 Jun '15, 09:26) Guy Harris ♦♦

For me it worked better with Per Packet Information.

Worked better because there was more information from the PPI header, or worked better because the information there is easier to understand when you read Wireshark's dissection of it? My goal is to enhance radiotap or its processing by programs in order eliminate all reasons to prefer other radio headers, including PPI, to radiotap.

(05 Jun '15, 09:28) Guy Harris ♦♦

Worked better because there was more information from the PPI header, or worked better because the information there is easier to understand when you read Wireshark's dissection of it? So for me it was easier to read, because it shows me clearly that I am on the 2.4GHz 802.11n. But the only one machine who is able to capture ppi is my mac. With Ubuntu Notebook only Radiohead is possible. So if you need more Info please tell me. I can take some traces for you.

(05 Jun '15, 16:03) Christian_R

OK, that sounds like a presentation issue, which should be fixed in Wireshark, as per the last paragraph of my answer.

With Ubuntu Notebook only Radiohead is possible.

So what does Thom Yorke think about this? :-)

(05 Jun '15, 18:15) Guy Harris ♦♦

OK, that sounds like a presentation issue, which should be fixed in Wireshark, as per the last paragraph of my answer.

Now is fixed in Wireshark, in the master branch. There will be an "802.11 radio information" subtree after the radiotap subtree and before the 802.11 subtree, and it'll have a reasonably-digested version of the radio information, including showing the PHY and (if available) band information, e.g. showing "802.11n" (or "802.11n 2.4 GHz" or "802.11n 5 GHz") for 802.11n packets or "802.11ac" for 802.11ac packets.

Obviously, it won't show information that's not available in the radiotap or PPI or whatever other radio header is there, but it should show a summary of the information that's there. (11ac needs some more work, but it should have a reasonably complete display of 11n and older standards.)

(22 Jun '15, 18:23) Guy Harris ♦♦

showing 5 of 7 show 2 more comments