Created attachment 14897 [details]
1 stream mcs 9 vht ppdu
Build Information:
Wireshark 2.2.0 (Git Rev Unknown from unknown)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 4.8.7, with libpcap, without POSIX capabilities, with
GLib 2.48.2, with zlib 1.2.5, without SMI, with c-ares 1.11.0, without Lua,
without GnuTLS, with Gcrypt 1.7.3, with MIT Kerberos, with GeoIP, with
QtMultimedia, without AirPcap.
Running on Mac OS X 10.11.6, build 15G1004 (Darwin 15.6.0), with locale
en_US.UTF-8, with libpcap version 1.5.3 - Apple version 54, with Gcrypt 1.7.3,
with zlib 1.2.5.
Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz (with SSE4.2)
Built using clang 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31).
--
+++ This bug is related to Bug #12558 +++
I don't know the reason why data rate is not computed for 1/2 stream VHT PPDU
sent at e.g., MCS 9?
As per the spec, these data rates are invalid assuming BCC encoding however
pretty much most if not all chipset vendors support these MCSs when encoded
with LDPC.
If a system receives these PPDUs there is no reason for wireshark not to
compute the data rate when in fact it decodes other fields like MCS, encoding,
stream, etc.
There are two ways we could deal with this
1. ieee80211_vhtvalid[mcs].valid[bandwidth] check should take into account LDPC
or BCC being used, in former case should return True, or
2. eliminate ieee80211_vhtvalid[mcs].valid[bandwidth] entirely due to the fact
that wireshark is dissecting a valid received PPDU, which it would not have
been able to receive if BCC would have been used instead of LDPC on the
transmit side.
There will never be a pcap(ng) or a system, during live capture, can ever
receive a BCC encoded VHT PPDU with illegal MCSs like 1/2 stream MCS9: that
would be already dropped on transmit side, or undecoded by the receive MAC
firmware.
I prefer approach 2 above, being simple and makes more sense and the change
below at least meet my expectation [1]
It fills the gap when a valid good fcs PPDU is seen in wireshark but data rate
is not displayed (someone having a filter simply miss these)
[1]
--- wireshark-2.2.0/epan/dissectors/packet-ieee80211-radiotap.c 2016-09-07
09:59:03.000000000 -0700
+++ wireshark-2.2.0/epan/dissectors/packet-ieee80211-radiotap.c 2016-09-09
10:54:40.000000000 -0700
@@ -1804,8 +1804,8 @@ dissect_radiotap(tvbuff_t * tvb, packet_
}
if (can_calculate_rate && mcs <= MAX_MCS_VHT_INDEX &&
- nss <= MAX_VHT_NSS &&
- ieee80211_vhtvalid[mcs].valid[bandwidth][nss]) {
+ nss <= MAX_VHT_NSS /*&&
+ ieee80211_vhtvalid[mcs].valid[bandwidth][nss]*/) {
float rate =
ieee80211_vhtinfo[mcs].rates[bandwidth][gi_length] * nss;
if (rate != 0.0f && user_tree) {
rate_ti = proto_tree_add_float_format(user_tree,
You are receiving this mail because:
- You are watching all bug changes.
