Do more fixups of the "phy" based on the data rate, so that it reflects
the modulation used for the packet.
Note, in comments, why we're doing this, and that there's no reiable
way, in radiotap, to determine the type of channel on which capturing is
being done, as some packet providers use the channel field to indicate
the channel type and others use it to indicate the modulation.
Only provide the "short preamble" for "11b", as that's now being used to
mean "DSSS modulation" - packets on an 11g channel will be marked as
"11g" if they're OFDM or "11b" if they're DSSS.
Make some other cleanups while we're at it.
S1G adapters should be shipping soon since Silex America has a dev-kit
available, so it is about time to add support for this.
Change-Id: I0225d87f78efbcbe88476921d4fce3d56a3ce0cd
These appear to be copy/paste errors detected by running
./tools/check_typed_item_calls.py --consecutive
Quite a few issues still remain after this batch.
A second batch of spelling errors, detected using a script
that uses pyspellcheck and a Wireshark-specific dictionary file.
I will take at least one more pass through the dissectors, as
further improvements are made to the script.
This patches adds support to parse the TX flags of the radiotap header,
including a new DONT_ORDER Tx flag.
Bug: 16732
Change-Id: Ia57c079e020a32219a3e3fcfb7da5ef260360b7e
Reviewed-on: https://code.wireshark.org/review/37944
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The static arrays are supposed to be arrays of const pointers to int,
not arrays of non-const pointers to const int.
Fixing that means some bugs (scribbling on what's *supposed* to be a
const array) will be caught (see packet-ieee80211-radiotap.c for
examples, the first of which inspired this change and the second of
which was discovered while testing compiles with this change), and
removes the need for some annoying casts.
Also make some of those arrays static while we're at it.
Update documentation and dissector-generator tools.
Change-Id: I789da5fc60aadc15797cefecfd9a9fbe9a130ccc
Reviewed-on: https://code.wireshark.org/review/37517
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Another instance of this problem that showed up when working on the fix
to the data types of those tables (fixing the data types mean that these
errors cause the conpile to fail; as indicated, that's one reason to fix
them).
Change-Id: Ia1953b95968101f27fedd98a5fc2854101779deb
Reviewed-on: https://code.wireshark.org/review/37509
Reviewed-by: Guy Harris <gharris@sonic.net>
The arrays of pointers to header field hf_ values were getting
overwritten if the fields in question are unknown; that meant that, in
all future dissections, they would be dissected as unknown *even for
packets where they are known*.
Make them auto arrays, instead, so that each call to the dissector has
its own copy, properly initialized at run time, that it can scribble
over as it chooses without damaging the array for the next call.
This involves a cast to work around the type of the array argument being
"const int **", which means "pointer to pointer to const int",
not "pointer to const pointer to (non-const) int". That meant that the
scribbling on the static array was *not* detected at compile time.
Fixing the type is a *lot* of work, but may catch other instances of
this problem, and may prevent future instances of it. That's a project
for a separate commit, however.
Bug: 16636
Change-Id: I985157063488739bb59f87780c017e94e2380343
Reviewed-on: https://code.wireshark.org/review/37502
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
Prof. Doppler's name is spelled with two "p"s.
Change-Id: Ia25d45b0a890be8c954a67b1ce5860753c1de25d
Reviewed-on: https://code.wireshark.org/review/37498
Reviewed-by: Guy Harris <gharris@sonic.net>
Bug: 16255 - support HE MCS to rate conversion
Change-Id: I4a4a6c3d62c167b654d150c397047a55f287e6c8
Reviewed-on: https://code.wireshark.org/review/37255
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
From Johannes Berg with changes by Richard Sharpe to make it easier for
people to add support for RADIOTAP Header TLVs in the future.
Change-Id: I66d69cbe16740abce1e75ca1e789a2034283306b
Reviewed-on: https://code.wireshark.org/review/36057
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
The range doesn't start at 60 GHz, it starts at 57 GHz; this fixes that,
and leaves it open to future fixes.
Change-Id: I51d7188f50479bf542babe0f6677638e8a683314
Reviewed-on: https://code.wireshark.org/review/35524
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This works around the lack of a defined radiotap field for 11ad.
Bug: 16272
Change-Id: Ia851c644aee52ff9a138a36b16015d4112b5bf92
Reviewed-on: https://code.wireshark.org/review/35401
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Set it as the PHY type if we see the HE field in a radiotap header, and
report that PHY type as "802.11ax" in the generic radio metadata
dissector.
Change-Id: I181d2717d82bdca73e04b6111b2483ca099d48bb
Ping-Bug: 13207
Reviewed-on: https://code.wireshark.org/review/35227
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(patch from Getachew Redieteab)
Change-Id: I180b20b513e901c2c157da9a2318a90c91fd040b
Reviewed-on: https://code.wireshark.org/review/34505
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The spec is now accepted, so bringing these up to date.
Change-Id: I9489cd8c0b9255446c829f8202410d2d94272607
Reviewed-on: https://code.wireshark.org/review/31723
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Those frames *don't* have their link-layer headers stripped, even on
PF_PACKET/SOCK_DGRAM captures (hopefully, nobody will consider that a
bug and "fix" it).
The "hatype" field is the ARPHRD_ value for the adapter, as returned by
SIOCGIFHWADDR; in monitor mode, those frames will have an hatype of
ARPHRD_IEEE80211_RADIOTAP. Add an "sll.hatype" dissector table, which
we check before checking the "sll.ltype" dissector table, and have the
radiotap dissector register in that table.
We still use the special hack for an hatype of ARPHRD_NETLINK, because,
for *those* frames, the "protocol" field of the nominal SLL header is
the netlink family, not an Ethertype or anything else that the SLL
dissector would handle.
Change-Id: If503a7daa9133adf1b8c330ec28c4c824d4f551d
Reviewed-on: https://code.wireshark.org/review/30592
Reviewed-by: Guy Harris <guy@alum.mit.edu>
1) it doesn't supply any information not supplied by the new
"wlan_radio" tap and, in fact, supplies less information (including not
supplying any presence flags);
2) it only works for radiotap headers, not for any other forms of radio
metadata;
3) its data structure wasn't declared in a header available to any
listeners, it was defined internally to the radiotap dissector.
Change-Id: Ie84a48bbf204b8b3bb40370c17ca82d39e5df3fb
Reviewed-on: https://code.wireshark.org/review/30415
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The radiotap spec says "dB antenna signal" and "dB antenna noise" are
unsigned. Make it universally so.
Change-Id: Iea2c5360d7352ca5e84862ea338d1fc689272191
Reviewed-on: https://code.wireshark.org/review/30410
Reviewed-by: Guy Harris <guy@alum.mit.edu>
While we're at it, only set the RSSI column once - no need to do it at
the beginning and later when we're setting fields.
Change-Id: Ia729019e5e6dfbe1cdad61f1f8397b0a3a171996
Reviewed-on: https://code.wireshark.org/review/30405
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When there is no data, which is indicated by the 0-length PDSU radiotap header,
there is no more data to dissect, so don't dissect any more as that causes an
exception.
Change-Id: I284b8128ec309ba26f24a012380d311eb3e48697
Reviewed-on: https://code.wireshark.org/review/29529
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
... Use of an unregistered ett leads to an abort.
Inspired by I3ee2f557ace1643dfba5a978add66c3c7ba7d895. Some day I should get
the ett_ registration checking code in checkAPIs ready for prime time...
Change-Id: I69162d4bcec571e6a517a107ac365aa78bfe8d25
Reviewed-on: https://code.wireshark.org/review/29474
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The RFC was posted in the Radiotap mailing list.
Change-Id: I8ddb1cd474d05c94d1b5a51eb5e16d548a313a86
Reviewed-on: https://code.wireshark.org/review/28923
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
We call that dissector even for zero-length PSDUs, so the radio
information is shown. We also show the zero-length PSDU type.
We don't call the 802.11 dissector for zero-length PSDU frames.
That way, you don't have to open up the radiotap information to find out
about zero-length PSDU frames, we can support zero-length PSDU
information for other pseudo-headers and file types if they support it,
and taps using the radio information can get zero-length PSDU frame
information.
Change-Id: I7d5da4ea978d8ca4889fc76160f11e3416b4d036
Reviewed-on: https://code.wireshark.org/review/29034
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The loop doesn't just add them to the protocol tree, it also does sanity
checking; we want to do the sanity checking regardless of whether we're
building the protocol tree or not, so that if we skip processing the
radiotap header because it's malformed, we do so regardless of whether
we're building a protocol tree.
This prevents a crash I saw where, on the first pass, we weren't
building a protocol tree, so we didn't check the bitmaps and proceeded
to process the bad radiotap header in a fuzzed file and set the
"zero-length PSDU" flag, and didn't call the 802.11 radio dissector, and
didn't allocate a "wlan radio information" structure and attach it to
the packet, but, when I went to the packet, and thus *did* build a
protocol tree, we *did* check the bitmaps in the process of adding them
to the protocol tree, skipped the part where we processed the rest of
the radiotap header, *didn't* set the "zero-length PSDU" flag, and
*did* call the 802.11 radio dissector, which crashed becaus the "wlan
radio information" pointer was null.
(No, checking the "wlan radio information" pointer isn't the correct
fix; the correct fix is to make sure we do the same processing, other
than adding items to the protocol tree, *regardless* of whether we're
building the protocol tree.)
Change-Id: If3c16f76981448e4f396a4a9730f1d5dce8f8eba
Reviewed-on: https://code.wireshark.org/review/29033
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Report an error and quit dissecting if it's less than 8.
Change-Id: I297fcb0ca754641a9e197037df1140361000fd25
Reviewed-on: https://code.wireshark.org/review/29022
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This is separate from the 802.11 preference, which only affects packets
where no file or packet metadata indicates whether there is an FCS (yes,
that is intentional behavior). This is specifically for radiotap, in
case some driver fails to set the FCS bit correctly (this is currently
an issue with Npcap, which currently assumes that the packet has an FCS
iff NDIS indicated the packet with the DOT11_RECV_FLAG_RAW_PACKET flag;
that doesn't appear to be a reliable indicator, and it's not clear there
*is* a reliable indicator, so Npcap might have to fall back on something
really gross like a quirks database for particular adapters).
Change-Id: Ia3b134d89004307442d42cfa5ed3cf8fb938235f
Ping-Bug: 15010
Reviewed-on: https://code.wireshark.org/review/28855
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Richard Sharpe