According to IEEE 802.15.4-2020 Section 7.3.5.1 Destination PAN ID field is
present when PAN ID Present bit is set. Therefore we should check for the bit.
Fixes: wireshark/wireshark#17496
Most of the time, the return value tells us nothing useful, as we've
already decided that we're perfectly willing to live with string
truncation. Hopefully this keeps Coverity from whining that those
routines could return an error code (NARRATOR: They don't) and thus that
we're ignoring the possibility of failure (as indicated, we've already
decided that we can live with string truncation, so truncation is *NOT*
a failure).
Improve dissection of IEEE 802.15.4 TAP DLT by reporting the number of
data bytes of the original data frame and create a separate packet bytes
pane containing just that data without the TAP TLV content.
In captures where a lot of packets are missing, requests and ACKs are
sometimes incorrectly paired. With this improvement, ACKs must arrive in
a reasonable time to be paired with a request.
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.
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>
Only use proto_tree_add_bytes_item() if you
1) are processing a hex string rather than binary byte array;
2) need the raw byte data.
While we're at it, fix the encoding argument in some calls adding
FT_BYTES fields to be ENC_NA, and, for some cases that could use
FT_UINT_BYTES, use proto_tree_add_item_ret_uint() to handle the length
and add a comment about that.
Change-Id: I6a1baca5c7da3001c0a6669f9c251e9773346c8c
Reviewed-on: https://code.wireshark.org/review/36967
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
true_false_strings have no helper function to properly retrieve the
string representing the true or false value, much like unit_strings,
even though this is not uncommon in dissectors.
This change introduces the helper function and modifies the dissectors,
so that they use this helper i.s.o. their own expressions.
Change-Id: I477ed2d90a9a529fc5dcfef7e3ea42ec180d27ae
Reviewed-on: https://code.wireshark.org/review/36920
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
There is a good chance that the required information is still
valid even with a wrong FCS.
Change-Id: I244b2b4a857b7cefd1f4ef22eb151d5ac3ee4133
Reviewed-on: https://code.wireshark.org/review/35953
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This makes the address representation in ieee802154_transaction_t and
ieee802154_packet consistent.
Change-Id: I6ae66b48c3b2afe5843e6a82fe5adf1c6be5a7cd
Reviewed-on: https://code.wireshark.org/review/35780
Reviewed-by: Martin Boye Petersen <martinboyepetersen@gmail.com>
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: I86a0aae9409ab5f81a70560997c637f8f16718fa
Reviewed-on: https://code.wireshark.org/review/35754
Petri-Dish: Jim Young <jim.young.ws@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For the same reason as in g89c9d909.
Change-Id: I5e344ebdf8ba05d169484aa32b409d84edc6124f
Reviewed-on: https://code.wireshark.org/review/34943
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Wake-up frames in 802.15.4e have a specific structure that is not
consistent with the fields present in a single-byte FCF.
As a special case when 802154e_compatibility is enabled, detect
multi-purpose frames that are exactly 12 bytes long and contain
a Rendezvous Time IE and parse them as an 802.15.4e wake-up frame.
Bug: 16102
Change-Id: I87c6317fffb0670dae0d5bdd499271fe02a40b22
Reviewed-on: https://code.wireshark.org/review/34684
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add support for IEEE802.15.4-2015 multipurpose frames, which are
similar to data frames with the following exceptions:
- The Frame Control Field can be either 1 or 2 octets, with different
bit offsets for all fields except for Frame Type.
- The Frame Version field, when present, must always be set to 00.
- The source PAN ID is always absent
- Instead of a PAN ID Compression field, there is a PAN ID Present
field for the destination PAN ID only.
See Section 7.3.5 of IEEE802.15.4-2015 (esp Figure 7-19) for details.
Bug: 16101
Change-Id: I1e64d90694b567573ca10395b823adb9015f8917
Reviewed-on: https://code.wireshark.org/review/34682
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a new 802154e_compatibility preference.
When enabled, it will attempt to handle certain PAN ID compression schemes
that are permitted in 802.15.4e-2012 but not in 802.15.4-2015.
Specifically, when either the source or destination address are present
in short form and the PAN ID Compression bit is cleared, 802.15.4-2015 expects
the source PAN ID to be present, whereas 802.15.4e-2012 does not.
Bug: 16102
Change-Id: I7fea7bd6d0a78c859360a1130b242e90eac8feec
Reviewed-on: https://code.wireshark.org/review/34683
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
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 title of a decode_as_t was used by the GTK UI. It's no
longer required for Qt.
Change-Id: Ibd9d4acbe9cad2c1af520340d04e550326a97ebe
Reviewed-on: https://code.wireshark.org/review/33557
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
ACK tracking did not work for protocols like ZigBee because the ACK is
send without address information. By moving the ACK tracking out-side
the conversation and only use the interface and the sequence number to
match requests and ACKs this is now working.
If addresses are present in the ACK they will still be used to avoid
invalid matches.
The nature of the wmem_tree ensures that the ACK tracking will always
work on the latest requests.
Change-Id: I5c763e34ec340b19a7998ddcfe9f72fccfd2acd1
Reviewed-on: https://code.wireshark.org/review/32927
Reviewed-by: James Ko <jck@exegin.com>
Tested-by: Petri Dish Buildbot
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
for function 'ieee802154_create_tap_tlv_tree' [-Wmissing-prototypes]
Change-Id: I74de53e945685a289c302a784afd3d3f5f22891b
Reviewed-on: https://code.wireshark.org/review/32799
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Channel Center Frequency (Type=11). In addition to or instead of
channel number for packet reception, the channel center frequency may be
specified in kHz as IEEE-754 floating point number.
Channel Plan (Type=12) - Allow reporting of a generic channel plan used
to calculate channel numbers. The channel plan consists of the channel
0 center frequency, channel spacing and number of channels.
Change-Id: I41fa585e9c2fd8986b1fb61a49de74ee2adac4fa
Reviewed-on: https://code.wireshark.org/review/32415
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a new subtree with Header fields Version, Reserved and Length.
Include padding length in the TLV entry.
Change-Id: I7c39253f4d2f5f3b2d5721d10af3f8b563ea0d04
Reviewed-on: https://code.wireshark.org/review/32346
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Fixing some "implicit conversion loses integer precision" warnings
reported by clang with -Wshorten-64-to-32 option
Change-Id: Ica92971e689c28c6d1ea995e821d648a19186c09
Reviewed-on: https://code.wireshark.org/review/32331
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
That was what was being done before; do it in the main dissector
routine, as 1) the main dissector routine doesn't call the FCS or TI
CC24xx dissector if we don't have an FCS or TI CC24xx metadata trailer
and 2) that means we pull duplicate code out of those dissectors.
Also, those routines are only called if we have the full FCS/metadata
available, so there's no need for them to check for that. (Arguably,
they should be called if the data is present, according to the reported
length, even if it's not available in the captured data, so we mark the
frame as having been cut off so the full data isn't available.)
Change-Id: I6be2a1f71a27bc41aea93e3c92743fc12c997c94
Reviewed-on: https://code.wireshark.org/review/32281
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Put the "mark frames with an invalid CRC" stuff into the main dissector
code, as it's the same regardless of whether you have an FCS that can be
checked or metadata with an "FCS bad" flag.
Change-Id: I2540c1934032c91f22b66babd81fb928212f18b5
Reviewed-on: https://code.wireshark.org/review/32280
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Those fields have nothing in common.
Change-Id: Ida29ce36a8a3e311b58a900a5631e314ebc39662
Reviewed-on: https://code.wireshark.org/review/32279
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Use local variables and parameters instead.
Change-Id: If491ef9c4e961848bb59f48d107157372f93e43f
Reviewed-on: https://code.wireshark.org/review/32278
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There's the value the user configured, which should neither be used nor
modified by the 802.15.4 TAP dissector; that dissector should just set
the FCS length variable. It should also call the common dissector, as
most of the other top-level dissectors do.
That lets us have separate types for the "configured FCS type" and "tap
FCS type" variables; do so.
Speaking of calling the common dissector, the "non-ASK" dissector should
do so as well. Make it so.
While we're at it, fail if there's an unknown FCS type in the tap
header.
Change-Id: Ib0de81764670302c771be3851e9717f0a8399ac6
Reviewed-on: https://code.wireshark.org/review/32277
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The CCITT was part of the ITU, and was renamed the ITU-T:
https://en.wikipedia.org/wiki/ITU-T#History
so just say ITU-T. As for whose idea those particular 16-bit and 32-bit
CRC generator polynomials originally were, I don't know. 802.15.4 speaks
of "a 32-bit CRC equivalent to ANSI X3.66-1979", but there ain't no
32-bit CRC in that standard, and its 16-bit CRC is Yet Another
x^16 + x^12 + x^5 + 1 CRC that they claim came from CCITT/ITU-T V.41;
V.42 has both 16-bit and 32-bit CRCs.
Clean up more comments about the TI CC24xx metadata trailer.
The "non-ASK PHY" name may have made sense when the type was created, as
all the PHYs other than ASK, at the time, may have had the same
preamble/SFD/PHR, but that's no longer true. List, in a comment, the
ones to which it applies, all of which have 16-bit CRCs.
Change-Id: Ie509dc06d06aec9738447f8da254c4edc5971a92
Reviewed-on: https://code.wireshark.org/review/32276
Reviewed-by: Guy Harris <guy@alum.mit.edu>
tvb_new_subset_length() is sufficient, and correctly calculates the
captured length of the tvbuff, rather than possibly setting it too large
by setting it based on the length of the TLV header.
Change-Id: I510ee6742fcbc08ae7331585a65c768e98e6b3d9
Reviewed-on: https://code.wireshark.org/review/32271
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's simpler, and is not incorrectly using the *captured* length to set
the *reported* length.
Change-Id: If4b7f1c431f4c39dcc568698358667a1b4fc1a12
Reviewed-on: https://code.wireshark.org/review/32268
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Data handed to dissect_ieee802154_decrypt() should have, and does, have
the FCS stripped off, so we don't need to use the FCS length.
While we're at it:
Update more comments for CC24xx metadata not being an FCS.
Do the header IE processing loop with a "data remaining" counter,
explain why we're doing a "data remaining" check and why it includes the
MIC length, and note that we should use the "data remaining" counter to
do more checks for invalid frames.
Change-Id: I928dbf6142b5876b6a25b954f798936c9e97ac0d
Reviewed-on: https://code.wireshark.org/review/32267
Reviewed-by: Guy Harris <guy@alum.mit.edu>
New link type for IEEE 802.15.4 with pseudo-header and optional
meta-data TLVs, PHY payload exactly as it appears in the spec (no
padding, no nothing), and FCS if specified by FCS Type TLV.
Specification at https://github.com/jkcko/ieee802.15.4-tap
Bug: 15429
Change-Id: I67bd154891ad5818be9a1630aa5cbb863b55509a
Reviewed-on: https://code.wireshark.org/review/32141
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
All the complicated stuff to see whether the captured data includes all
of, some of, or none of the FCS is necessary, and should not have been
removed. The previous code would sometimes dissect packet data at the
end as both payload *and* FCS.
This also means that the decryption code doesn't have to worry about the
FCS, and expects the payload handed to it *not* to have the FCS. Update
callers to handle that.
This puts back the changes from
e4d3916530, for which the comment was:
Clean up the way we handle the FCS.
For the "802.15.4 with FCS" link-layer type, strip what FCS we find,
if any, off and use that new tvbuff for all dissection except for
checking and dissection of the FCS itself.
For the "802.15.4 without FCS" link-layer type, don't fake an
uncaptured FCS by increasing the reported length, just use the
tvbuff as is.
This means we handle 802.15.4 the same way we handle other
link-layer types where the FCS might, or might not, appear as
part of the captured data.
"Handling stuff at the ends of packets is hard, let's go shopping!"
Change-Id: Iaf3e8392efec9d1c35f73966e22f2a3ae91317a1
Reviewed-on: https://code.wireshark.org/review/32254
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There's no MIC at the end of an unencrypted packet, and thus we're not
removing any MIC.
Change-Id: Ie19790afc573b66f5dd09a4f8afc0fe69895eabe
Reviewed-on: https://code.wireshark.org/review/32249
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Use tvb_new_subset_length(), rather than (incorrectly) attempting to
calculate the captured length ourselves.
Change-Id: I9f608ee5bf59f261111b2a75900dddad12fb5554
Reviewed-on: https://code.wireshark.org/review/32245
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Don't call it an "FCS" in the CC24xx case. It's not an FCS; it's not
even just an "FCS OK" bit.
Display the metadata in question in bit order, from the "CRC OK" bit
downwards.
Change-Id: I8da29bbb1f8b5ef3905af75dd34c1563b904a4d8
Reviewed-on: https://code.wireshark.org/review/32228
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add flag to protocol configuration to enable ACK tracking.
Fix duplicate strings in dissector.
Change-Id: I245f2f2c9aad408a8e8429e8ac5ea5dac37a4f69
Reviewed-on: https://code.wireshark.org/review/32140
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Vladimir Bespalov