Wireshark-bugs: [Wireshark-bugs] [Bug 8356] 802.11ac VHT Capabilities might not be decoding prop
Comment # 6
on bug 8356
from Mark Phillips
I am confused by the screen capture because it doesn't look like the same data
is being decoded. Looking in fields to the left of the capabilities, you can
read off the binary 4 byte (i.e. 32 bit) value which is decoded. Regardless of
which order you read it, it doesn't appear to be the same as the number
omnipeek is saying it is decoding.
If you look further down, you will see omnipeek thinks the Tx MCS Map is all
zeros. I think that is extremely unlikely because it would means that the
device supports MCS0-7 for up to 8 Spatial Streams. On the other hand the
wireshark decode which says MCS0-9 is supported for 0-2 looks more correct
(though actually is should say SS1-3).
My conclusion is that either the displays do not match, or omnipeek is getting
confused somehow and decoding the wrong bytes/bit from the frame. The wireshark
decode looks sane to me, and the omnipeek one looks very strange.
PS. I have some editorial review comments which have been raised internally
(after I had already submitted). I'll see how many apply to the current code
head and maybe put together a proposed patch for them.
You are receiving this mail because:
- You are watching all bug changes.