Libpcap's done that for a while; we should do so as well.
(Ideally, we should use those bits, but there's an issue with pcapng,
where the FCS length in the IDB is described as being in units of bits,
but where we're treating it as being in units of bytes, that I'd like to
resolve first.)
Change-Id: Ibcb82f1dcaa8baae5bba55636cea8852a6af814e
Reviewed-on: https://code.wireshark.org/review/32303
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>
Actual changes from Trond Myklebust, I just merged them.
Change-Id: I1038419f38835cc3015d8a44daaf0c9c9d682e81
Reviewed-on: https://code.wireshark.org/review/32290
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
That tells then what name they *can't* use for their file-type plugin,
because it's already a built-in file type name in Wireshark.
Change-Id: Ibbbfda21e1109cf46275008a46b8ea65c8fcf4b5
Reviewed-on: https://code.wireshark.org/review/32291
Reviewed-by: Guy Harris <guy@alum.mit.edu>
this change adds support for reparse tags added by Windows Server for
NFS for special UNIX files (symlinks, devices, FIFOs, sockets).
previously code assumed all reparse tags were Windows symlinks and
would fail with "malformed packets" when parsing other tags.
Change-Id: Ia0a642ed8e196d3544168f47a6be9f59f03be6d4
Reviewed-on: https://code.wireshark.org/review/32273
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Moved cluster field before src field.
Change-Id: Id113ae60319f1ddb730aaa749a8daa5785da1fc0
Reviewed-on: https://code.wireshark.org/review/32282
Reviewed-by: Kenneth Soerensen <knnthsrnsn@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
tcp.stream and udp.stream are already unsigned identifiers. An upcoming
http2.hashed_stream identifier can exercise the full unsigned 32-bit
number space, so be sure not to treat the stream identifier as signed
integer.
Change-Id: Ic5d398b2bda7eba7555e385ef3fcd44b490f78c9
Reviewed-on: https://code.wireshark.org/review/32287
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Alexander Gryanko <xpahos@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
A router here sends the type and length of suboptions of the NTP Server
option in dhcpv6 replies in little endian. So the NTP Server option
looks like:
01:00:10:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:ff:fe:xx:xx:xx
instead of
00:01:00:10:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:ff:fe:xx:xx:xx
. This makes the dissector throw an exception "Malformed Packet" which
results in the following options not being dissected.
So check the suboption's length before adding the subtree. This improves
diagnostics ("suboption too long" instead of "Malformed Packet") and
results in the suboptions after the bogus one being parsed.
Bug: 15542
Change-Id: Ifbafc23b3dbb7ca389b89936e9d1d15ecc82396e
Reviewed-on: https://code.wireshark.org/review/32223
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@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>
Explicitly exclude our various Windows package targets from the Visual
Studio default build. This will hopefully keep the 32-bit Windows builder
from trying to build the portableapps_runtime target when it shouldn't.
Change-Id: Id8481e92abda9b1a4784b8c8e8b5a1b3f1b4647e
Reviewed-on: https://code.wireshark.org/review/32256
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
(January and February 2019)
Change-Id: I25a146c94868b7ec96d5910d9515778dec41e444
Reviewed-on: https://code.wireshark.org/review/32242
Reviewed-by: Anders Broman <a.broman58@gmail.com>
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>
Also ask, in a comment, how long the CRC is if we *do* have a CRC
rather than metadata.
Change-Id: I92da4d3ade9b69f65b39ea058915f3ee4530b786
Reviewed-on: https://code.wireshark.org/review/32237
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>
Make FCS length a variable.
Modify protocol configuration to include FCS type option.
Change-Id: I1e08f5b6b43907833464c20d798163343ce67a76
Reviewed-on: https://code.wireshark.org/review/32139
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Zero-initialize a variable. This should fix bug 15534, although I can't
reproduce it here.
Bug: 15534
Change-Id: I7ee685e99e225d054386ead998cb4de681a2e759
Reviewed-on: https://code.wireshark.org/review/32211
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
They're a capture filter if you're capturing live traffic; they're a
display (read) filter if you're reading a capture file.
Change-Id: Ia2f5bcdb0098bf3c2b4a3d99da5bfe768e09b5a0
Reviewed-on: https://code.wireshark.org/review/32207
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When copying from another profile which has been renamed:
show the new profile name in the info label "Created from".
When copying from another profile which is later deleted:
append "(deleted)" to the info label to indicate that the origin
profile is not in the list.
Do not show "Renamed from" when a profile name if renamed back to
it's original name.
Change-Id: I0bf0c868c5dfd150a23b2ef887e7c70030b48d05
Reviewed-on: https://code.wireshark.org/review/32201
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Multiple bugs have been found in the provided bug. Some of them have
been fixed in gefe920a, others here. The main problem is when malformed
files give wrong lenghts to the code, that casts and dereference it
without checking, causing oob reads. The fix introduces a check function
that prevents to go beyond the limits, early returning with a malformed
file message.
Other bugs have been fixed by forcing the string terminator that allows
the use of strlen() and MIN() that prevent wrong reads.
Bug: 15497
Change-Id: I8411208b5ea0f1a0720a17b882f704d03296d1c4
Reviewed-on: https://code.wireshark.org/review/32194
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
