Add TDS and OTS/OTP UUID, OTS PSM (I cannot find it, but
it seems to be linear), update CompanyIds and add three
EIR/AD codes: URI, Indoor Positioning and Transport Discovery Data.
Implementation of new "numbers" will be done later.
Change-Id: I8ad4d9c1d55c1824d87e88303c28e67dd445ec98
Reviewed-on: https://code.wireshark.org/review/13386
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Just get handles for the dissectors, don't go through the wtap_encap
dissector table.
Change-Id: I459249b98741cc069495c84ad4c47c0aa6768096
Reviewed-on: https://code.wireshark.org/review/13383
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's called from some places other than packet-frame.c, at least one of
which currently can't call anything else (the ATM dissector, for
VC-multiplexed bridged frames, where you don't know whether the frames
include the FCS or not), so the frame's pseudo-data doesn't necessarily
have the appropriate "FCS length" value. Have it explicitly check the
data argument, and explicitly pass the appropriate value to it.
Ping-Bug: 9933
Change-Id: I0c75f921d25d1e2b75e476c15ff9625205036b25
Reviewed-on: https://code.wireshark.org/review/13382
Reviewed-by: Guy Harris <guy@alum.mit.edu>
At least in the sample captures attached to bug 2631, the encapsulated
Ethernet frames don't include the FCS.
Bug: 9933
Change-Id: Ie14b87020c44d739173e5da9fc58a91924f38dfe
Reviewed-on: https://code.wireshark.org/review/13377
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The BNEP Version 1.0 spec says, for BNEP_GENERAL_ETHERNET packets,
"Note: Networking Protocol Types as used in this specification SHALL be
taken to include values in the range 0x0000-0x05dc, used to represent
the IEEE802.3 length interpretation of the IEEE802.3 length/type
field.", although it says that it's not mandatory to process those
packets.
We'll process them.
We don't need an Ethernet dissector handle, so don't fetch one.
Change-Id: I10b1fce62688fc0643435d0a01bdb969577df97e
Reviewed-on: https://code.wireshark.org/review/13376
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Bug: 11983
Change-Id: If8b0c4ff45014c0d7480e43afaaf12747590a56f
Reviewed-on: https://code.wireshark.org/review/13370
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Including a URL for a Cisco page with diagrams of the encapsulation.
Change-Id: I4fb4356ea6071ca7efb596a8d35f982478bf4896
Reviewed-on: https://code.wireshark.org/review/13367
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We should use both the captured length and original length, and we
should use them as the captured length and original length of the
tvbuff.
Clean up indentation and returning process while we're at it.
Change-Id: If7538268cd6ae557d9d5b85eefd57cf3e2e34a9e
Reviewed-on: https://code.wireshark.org/review/13366
Reviewed-by: Guy Harris <guy@alum.mit.edu>
At least in the sample capture attached to bug 3195, the encapsulated
Ethernet frames don't include the FCS.
Bug: 9933
Change-Id: I4440568deaa676ba8848694b80ed800244c8c5d9
Reviewed-on: https://code.wireshark.org/review/13363
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Found building with GCC 5.3.0 and CFLAGS="-g -Og".
Change-Id: I5bc29b6e91cc98332a513c9d03b02d2f6906608d
Reviewed-on: https://code.wireshark.org/review/13362
Reviewed-by: João Valverde <j@v6e.pt>
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
check that we have a line that contains OBJECT PROTOCOL ETHERNET
(at the moment, we fail if there's a line containing OBJECT PROTOCOL but
not ETHERNET and succeed otherwise
-> a file with some random lines will be identified as iseries)
initialize our line buffer with 0s to make sure we don't access uninitialized
data while parsing
don't set wth->priv unless the file is really an iseries file
free the iseries struct if the file is not our type
Bug: 11985
Change-Id: I0ac7003c047f54ca025d02e59b56d1ff4e2a6be7
Reviewed-on: https://code.wireshark.org/review/13360
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
like it's done for the other file types
Change-Id: I8caa360b9c527ea642ee6b5102759ad341ad0030
Reviewed-on: https://code.wireshark.org/review/13359
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
re-order things a bit so that don't display anything if we just relay
our packet to the netlink dissector
Bug: 12018
Change-Id: Ic115de82d682b7105a1e97fb8be2709ac4875232
Reviewed-on: https://code.wireshark.org/review/13335
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Use tvb_subset_remaining() or tvb_subset_length() - they calculate the
correct captured length for you. This fixes, for example, the EoIB
code, where you ended up with tvbuffs with captured length > reported
length.
Change-Id: Ie792b53a796d4b32242cb83020b54232a2a09698
Reviewed-on: https://code.wireshark.org/review/13355
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I haven't found an official spec for EoIB, but slide 10 of
http://downloads.openfabrics.org/Media/Sonoma2009/Sonoma_2009_Tues_converged-net-bridging.pdf
shows the "Eth Payload" following the "Eth Header" and optional "Vlan
tag", and doesn't show an FCS; "Payload" generally refers to the data
transported by the protocol, which wouldn't include the FCS.
In addition, the capture attached to bug 5061 includes no Ethernet FCS.
So we assume the Ethernet frames carried by EoIB don't include the
Ethernet FCS.
Bug: 9933
Change-Id: I310e5727c42e05498d1f1df08266a48fd6674388
Reviewed-on: https://code.wireshark.org/review/13351
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The I-D doesn't explicity indicate that the FCS isn't present in the
tunneled Ethernet frames, but it is missing from the captures attached
to bug 10282.
Update the I-D number while we're at it.
Bug: 9933
Change-Id: I6e78b20cb858e6c8c4d7380b17b88382db013d56
Reviewed-on: https://code.wireshark.org/review/13350
Reviewed-by: Guy Harris <guy@alum.mit.edu>
RFC 6325, section 4.1.4 "Frame Check Sequence (FCS)", says
"Thus, when a frame is encapsulated, the original FCS is not
included but is discarded."
meaning that the inner Ethernet frame does *not* include an FCS.
Change-Id: Ie764ceb66dd43b951da015870e3e652ccfc651b5
Ping-Bug: 9933
Reviewed-on: https://code.wireshark.org/review/13347
Reviewed-by: Guy Harris <guy@alum.mit.edu>
RFC 7348 Figures 1 and 2, in the Payload section, says
"(Note that the original Ethernet Frame's FCS is not included)"
meaning that the inner Ethernet frame does *not* include an FCS.
Also, update the protocol references (the I-D is now RFC 7348) and add
the I-D for the group policy stuff.
Remove some extra blank lines while we're at it.
Change-Id: Ib94a43b95b0761e97d1406a1cca3687ee640e12d
Ping-Bug: 9933
Reviewed-on: https://code.wireshark.org/review/13343
Reviewed-by: Guy Harris <guy@alum.mit.edu>
On the off chance that UMTS FP traffic is being carried over a
pseudowire. :-)
Change-Id: I8db0fbe96545c08f4748bf9ec046e2dc4f2c2cc6
Reviewed-on: https://code.wireshark.org/review/13342
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Discovered by changing wtap_encap_requires_phdr() to use a switch
statement and comparing the case arms.
Change-Id: I2a23b86ddfbc88c1b3251a0e97f7f00ee93f630e
Reviewed-on: https://code.wireshark.org/review/13341
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That lets us handle pseudo-headers derived from packet data in one
central place.
Change-Id: Ie8e1d2d7dac176ea45be08cdc49bd808d9f8cc5b
Reviewed-on: https://code.wireshark.org/review/13340
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That lets us handle pseudo-headers derived from packet data in one
central place.
Change-Id: I25cb7599a8d3c31e5cbcfda94b072557209f5342
Reviewed-on: https://code.wireshark.org/review/13337
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's not safe to pass a null data pointer to a link-layer header type
dissector that expects the data pointer to point to a pseudo-header.
Also, remove one extra layer of protocol tree.
Change-Id: I030d38fd7d2f99d471020227597e4d7d81506e3e
Reviewed-on: https://code.wireshark.org/review/13336
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This bug was introduced in d1cb746, when HAVE_PCAP is not defined.
Change-Id: I67cd51e4eec45cf7e7c3bdbfea9b8e164bb92883
Reviewed-on: https://code.wireshark.org/review/13333
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
remove some unnecessary if(tree) checks while at it
Change-Id: I2ed7153a25a96f9fa08476176980655117aae26e
Reviewed-on: https://code.wireshark.org/review/13334
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: I3e2fad7f0307e599802c37040b34c899efb0e603
Reviewed-on: https://code.wireshark.org/review/13328
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The new ADD_ADDR format contains a truncated HMAC value of 8 bytes.
The specifications can be found in RFC6824bis-04.
Change-Id: Ief5118aea06fcd6c502ff4e55f0a49bf3234fd09
Reviewed-on: https://code.wireshark.org/review/13304
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Use eapol key data length to differentiate between #2 and #4.
This should work around ieee802.11 client implementation errors.
Windows is setting the Secure Bit on #2 when rekeying and Bug 11994
has a sample capture with the Nonce set in #4 and are so both
violating the spec.
Bug: 11994
Change-Id: Ia9e9c68d08dae042cfa7fd9517892db211b0a00f
Reviewed-on: https://code.wireshark.org/review/13299
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Rewrote to avoid unneeded g_strdup/g_free constructs, made some
arguments const, simplified some code and fixed some whitespace.
Plugged a memory leak in extcap_free_info().
Change-Id: I0bfcd86e6464d8bc592329b05dc994191a430096
Reviewed-on: https://code.wireshark.org/review/13306
Petri-Dish: Roland Knall <rknall@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Roland Knall <rknall@gmail.com>
This reverts commit 67c5849744.
It's not *guaranteed* to be there in *every* UN*X, but it's in at least
the Single UNIX Specification V3, as well as in shells commonly used in
non-UNIX UN*Xes :-), so it'll be there in the UN*Xes we'll be run on.
Change-Id: I541f7607055a24d6933d10244f85eea60052a3d8
Reviewed-on: https://code.wireshark.org/review/13325
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Dissectors that need it should fetch it with
find_dissector_table("wtap_encap").
Change-Id: I4b12888f20182aa529274b934b81d36f7697e1a6
Reviewed-on: https://code.wireshark.org/review/13323
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When desegmentation is disabled (as is done with the SSL Decryption
(master secret)" test), the app_data dissection is ignored because the
app_data dissector it not yet known. Fix this by continuing when the
port-based dissector is known (as was done before).
Also add avoid setting a "(null)" protocol in the tree when the
app_handle is not set (because the encrypted data is not decrypted for
example, or when the heuristics dissector fails to set a protocol).
Fixes regression since v2.1.0rc0-1501-g50dc0e8 ("ssl: improve
interaction with heuristics subdissectors").
Change-Id: I65c1d4705dec8f6fea8b7ac02151fab9dc6152d6
Reviewed-on: https://code.wireshark.org/review/13312
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Include the pcapng block name in every error message to give user a better hint as to where the error is
Bug: 8798
Change-Id: Idd80a8541ac37a42b9bd2e988fa8da1ce7bc91a0
Reviewed-on: https://code.wireshark.org/review/13310
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
If a link-layer header type is one where Wiretap generates a
pseudo-header from the bytes at the beginning of the packet data, we
can't handle it, because we don't have code to process those bytes and
generate a pseudo-header. Punt on it.
Change-Id: I28c585e9d368216411cc841068ce3414f27f2d86
Reviewed-on: https://code.wireshark.org/review/13319
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Check for it with DISSECTOR_ASSERT().
Change-Id: I71ba81107f7a4aff21b0f0dbecb5158dc4ff6238
Reviewed-on: https://code.wireshark.org/review/13318
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If a packet has a comment, the Protocol Hierarchy Statistics dialog will
add its stats to a top-level "Packet comments" node instead of the
"Frame" node. Add a check for the pkt_comment protocol ID and skip over
it if we find it. Affects Wireshark 2.0, 1.12, 1.10, and probably
earlier versions.
As an alternative we could always force "Frame" to be the first item in
the tree.
Change-Id: If7cd817071caf6219515f5d8121b3a1a2c0d79a6
Reviewed-on: https://code.wireshark.org/review/13297
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Michal Labedzki