URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=74c5ab0ff240edc1fd3f478128b378a0a0502190
Submitter: Guy Harris (guy@xxxxxxxxxxxx)
Changed: branch: master
Repository: wireshark
Commits:
74c5ab0 by Guy Harris (guy@xxxxxxxxxxxx):
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@xxxxxxxxxxxx>
Actions performed:
from 1dc608a Morph ProgressBar into CaptureProgressFrame.
adds 74c5ab0 Treat channel flags fields as just collections of bits, not as type fields.
Summary of changes:
epan/dissectors/packet-ieee80211-radiotap.c | 144 ++++++++++++---------------
epan/dissectors/packet-ppi.c | 87 +++++++---------
2 files changed, 97 insertions(+), 134 deletions(-)