Use it for OPT_COMMENT in the SHB, as there may be ore than one instance
of OPT_COMMENT in an SHB.
Also, use wtap_optionblock_get_option_string for OPT_SHB_HARDWARE,
OPT_SHB_OS, and OPT_SHB_USERAPPL; they're specified as "only one
instance allowed".
Change-Id: I23ad87e41e40b7ae1155e96c0523a6f8caad5204
Reviewed-on: https://code.wireshark.org/review/15750
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Don't put them in the summary structure; the summary routines should
calculate summary statistics, not dig up every bit of information that
*could* appear in a summary.
Instead, have the GUI code call wtap_file_get_shb() to get the SHB
information and call wtap_optionblock_get_option_string() to fetch the
option values.
Move the option code definitions into wtap_opttypes.h, as they're used
by the API.
Change-Id: Icef11f5fb30fdc3df1bb0208aae9ed0aebaf0182
Reviewed-on: https://code.wireshark.org/review/15748
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This doesn't try to use any data from multiple Name Resolution blocks, it
just converts single Name Resolution block usage into a GArray, so the
potential is there to then use/support multiple Name Resolution blocks
within a file format (like pcapng)
Change-Id: Ib0b584af0bd263f183bd6d31ba18275ab0577d0c
Reviewed-on: https://code.wireshark.org/review/15684
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This doesn't try to use any data from multiple Section Header blocks, it
just converts single Section Header block usage into a GArray, so the
potential is there to then use/support multiple Section Header blocks
within a file format (like pcapng)
Change-Id: I6ad1f7b8daf4b1ad7ba0eb1ecf2e170421505486
Reviewed-on: https://code.wireshark.org/review/15636
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Ping-Bug: 10203
Change-Id: Ifa24870d711449b87e9839dd46af614e4aa28fde
Reviewed-on: https://code.wireshark.org/review/15608
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
Register Wireshark for PacketLogger, ERF, IPFIX, and VWR files on
freedesktop.org, OS X, and Windows (we were already registered for ERF and VWR
files on Windows).
Change-Id: I8105997cb15ea06e1c078489fd88763d4ce9e40c
Reviewed-on: https://code.wireshark.org/review/15635
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I666d4f546d9fdc026ccd7fac7750e80df7f9b697
Reviewed-on: https://code.wireshark.org/review/15611
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The write functionality was too PCAPNG-specific and the intention is to
keep the option blocks as generic as possible.
So moved the write functionality back to pcapng.c and added a
wtap_opttype API to loop through all options in the block
(wtap_optionblock_foreach_option)
Change-Id: Iaf49126a1a3e2ed60ae02c52878ca22671dac335
Reviewed-on: https://code.wireshark.org/review/15525
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Also add a length parameter to wtap_optionblock_set_option_string
Change-Id: I8c7bbc48aa96b5c2a91ab9a17980928d6894f1ee
Reviewed-on: https://code.wireshark.org/review/15505
Reviewed-by: Anthony Coddington <anthony.coddington@endace.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Fix sanity checking overflow in wiretap ERF_TYPE_META parsing segfault.
Fix final tag of exactly 4 bytes not being dissected.
Fix not setting bitfield tag subtree (was working due to proto.c internal behaviour).
Add dissector expertinfo for truncated tags. Dissect type and length on error.
Bug: 12352
Change-Id: I3fe6644f369e4d6f1f64270cb83c8d0f8a1f1a94
Reviewed-on: https://code.wireshark.org/review/15357
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I2d23148c6f8d847aacec1d25cb694793ec9bb84e
Reviewed-on: https://code.wireshark.org/review/15504
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
They're not marshalled as a 64-bit integer in pcapng files, they're
marshelled as 2 32-bit integers, the first of which is the upper 64 bits
of the value and the second of which is the lower 64 bits of the value.
Bug: 12349
Change-Id: I2bde51ac11b2518ef2ddaecf43672c984f26081a
Reviewed-on: https://code.wireshark.org/review/15492
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Set len and caplen in pcap_read_post_process to actual wlen/payload length like for native ERF.
This fixes padding incorrectly showing as an Ethernet trailer or equivalent as
well as packet length calculations being incorrect.
Fix up rlen when writing ENCAP_ERF so it isn't longer than the actual record
length. This differs from native ERF behaviour which pads the record instead
but there is currently no non-hackish way to do this for pcap/pcap-ng.
Note: This means records captured from a DAG card in Wireshark (or old
PCAP(-NG) files opened) will have padding stripped when saved as PCAP(-NG) and
thus cannot be transmitted when converted to native ERF without aligning first.
However, if the file is saved as native ERF originally the padding will be
preserved (and zeroed). Given that extension header write support was very
broken and transmission of PCAP(-NG) is not supported without conversion this
is not expected to have been common.
Ping-Bug: 3606
Change-Id: I49dce03984d7f07431b6eb7e16a993aeb571f288
Reviewed-on: https://code.wireshark.org/review/15359
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
cast one of the factors to uint64 to make sure that the calculation uses
uint64 and not uint32 which may overflow
Change-Id: Iec14f870a694008f5a734294d9154117b6c64b78
Reviewed-on: https://code.wireshark.org/review/15346
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Write ERF subheader after extension headers, especially important for Ethernet
(other types predate extension headers for the most part).
Add missing ERF_TYPE_MC_AAL2 and ERF_TYPE_COLOR_HASH_ETH.
Truncate final ERF extension header when too many. Rlen is not currently
adjusted so may be incorrect (see followup patch). Existing tools generally
check against PCAP incl_len anyway as there are other scenarios where this can
happen like naive snapping or Wireshark ERF-to-PCAP.
Properly fixing this will involve getting rid of the ERF pseudoheader.
Consistent with the ERF wiretap (except for different padding behaviour).
Bug: 3606
Change-Id: I6086cbc3fef948586fbad6f585f648d99adfff4f
Reviewed-on: https://code.wireshark.org/review/15358
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: Guy Harris <guy@alum.mit.edu>
The lex files use malloc and friends which is prohibited; don't check them
(until checkAPIs becomes smart enough to realize this is OK).
This mirrors what is done in cmake.
Change-Id: Ie80ea7a9b7c0e25c70c8edf3671e80a493ea1b2f
Reviewed-on: https://code.wireshark.org/review/15377
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
the option length should be 1 byte, not 4 bytes.
Change-Id: I1b356c7ce101f9bbdc9793fc280b6564e12f303f
Reviewed-on: https://code.wireshark.org/review/15265
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This generates a top level target, checkAPI, that is
excluded from the ALL build target, so must be run separately.
On Windows using a Visual Studio generator, call
msbuild /p:Configuration=RelWithDebInfo checkAPI.vcxproj
Change-Id: I44a57c564dcfc75499463b942436f4b920a82478
Reviewed-on: https://code.wireshark.org/review/14873
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Check for destination or source MAC addresses that aren't 12 characters
(hex dump of 6 octets) long and type/length fields that aren't 4
characters (hex dump of 2 octets) long.
The buffer into which we copy the hex dump characters doesn't need to be
null-terminated, so don't bother to null-terminate it. Use the final
offset into the buffer as the buffer length, rather than using strlen().
Just memcpy the MAC addresses and type/length fields into the buffer;
the buffer is guaranteed to be big enough for all of them, and, as
noted, it doesn't need to be null-terminated.
Change-Id: I790e953542ae8443af01c81229a8deb877448ee3
Reviewed-on: https://code.wireshark.org/review/15239
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We don't check against it. Insteead, use phdr->caplen as the buffer
size; that's based on the number of hex digits we've found.
While we're at it, also get rid of ISERIES_PKT_ALLOC_SIZE - it makes it
less obvious that it's based on the packet length from the packet
header.
Change-Id: I8ad6306c62e7bc4cf896b335f39a5a77780fb2ea
Reviewed-on: https://code.wireshark.org/review/15236
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12394
Change-Id: I4b19b95f2e1ffc96dac5c91bff6698c246f52007
Reviewed-on: https://code.wireshark.org/review/15230
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12395
Change-Id: I43b458a73b0934e9a5c2c89d34eac5a8f21a7455
Reviewed-on: https://code.wireshark.org/review/15223
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Bug: 12396
Change-Id: I54fe8f61f42c32b5ef33da633ece51bbcda8c95f
Reviewed-on: https://code.wireshark.org/review/15220
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The scanf family of functions are as annoyingly bad at handling unsigned
numbers as strtoul() is - both of them are perfectly willing to accept a
value beginning with a negative sign as an unsigned value. When using
strtoul(), you can compensate for this by explicitly checking for a '-'
as the first character of the string, but you can't do that with
sscanf().
So revert to having pkt_len be signed, and scanning it with %d, but
check for a negative value and fail if we see a negative value.
Change-Id: I6450d468504e942df72342176a0e145e5ac3db5f
Reviewed-on: https://code.wireshark.org/review/15216
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And note that our limit (which is what we use as the fixed buffer size)
is less than WTAP_MAX_PACKET_SIZE, so we don't have to check against
WTAP_MAX_PACKET_SIZE.
Change-Id: I28cd95c40fd2fba9994a5d64ef323f1d8c1c4478
Reviewed-on: https://code.wireshark.org/review/15204
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
A normal packet should be Ethernet-sized; initially make the buffer big
enough for a maximum-sized Ethernet packet.
Once we know the payload length, check to make sure the packet length
won't be > WTAP_MAX_PACKET_SIZE and fail if it will. Then boost the
buffer size to be large enough for the packet, even if it's bigger than
a maximum-sized Ethernet packet.
Change-Id: I75b2108dd68f5bc5cd436bf5b82990089a7116bf
Reviewed-on: https://code.wireshark.org/review/15200
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Share more code between the read and seek-read routines.
Also note why that code doesn't have to check against
WTAP_MAX_PACKET_SIZE.
Change-Id: I09086fcd3c16883c2598fb0aeb172c66f480d315
Reviewed-on: https://code.wireshark.org/review/15193
Reviewed-by: Guy Harris <guy@alum.mit.edu>
These file formats have 16-bit packet lengths, so, even with some extra
metadata added, the packet data length will never be bigger than
WTAP_MAX_PACKET_SIZE. (No, we won't ever reduce WTAP_MAX_PACKET_SIZE.)
Change-Id: I9e1b1d90971f91cc6e5d66d0aa93841445b2bc22
Reviewed-on: https://code.wireshark.org/review/15186
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And note the cases where we don't have to check, as the length in the
file is 2 bytes long, and 65535 + the metadata length is <
WTAP_MAX_PACKET_SIZE.
Change-Id: I1e690eeee900b9aa7484dc0bd0c106dc38c77269
Reviewed-on: https://code.wireshark.org/review/15180
Reviewed-by: Guy Harris <guy@alum.mit.edu>
And use the actual packet length, rather than a fixed value, as the
buffer size we need for the packet.
Change-Id: I3af6724210a85b50610839d1bdf97fcf5a152b2f
Reviewed-on: https://code.wireshark.org/review/15179
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Merge the header and packet data parsing routines while we're at it.
Bug: 12396
Change-Id: I7f981f9cdcbea7ecdeb88bfff2f12d875de2244f
Reviewed-on: https://code.wireshark.org/review/15176
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Merge the header and packet data parsing routines while we're at it.
Bug: 12395
Change-Id: Ia70f33b71ff28451190fcf144c333fd1362646b2
Reviewed-on: https://code.wireshark.org/review/15172
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Treat the packet length as unsigned - it shouldn't be negative in the
file. If it is, that'll probably cause the sscanf to fail, so we'll
report the file as bad.
Check it against WTAP_MAX_PACKET_SIZE to make sure we don't try to
allocate a huge amount of memory, just as we do in other file readers.
Use the now-validated packet size as the length in
ws_buffer_assure_space(), so we are certain to have enough space, and
don't allocate too much space.
Bug: 12394
Change-Id: Ifa023ce70f7a2697bf151009b035a6e6cf8d5d90
Reviewed-on: https://code.wireshark.org/review/15169
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Chances are they want to include the file extension in wiretap's list of
file extensions (for the File->Open dialog) as well as the various files
needed for integration with the various desktop environments that
Wireshark supports.
(I should have put this advice there years ago when creating the
freedesktop.org mime-package file.)
Add a comment to the mime-package file explaining its purpose, giving
a link to the specification, and talking about MIME types and the registration
thereof.
Change-Id: I60540bf88062b7a90653888534405f6aef4f657c
Reviewed-on: https://code.wireshark.org/review/15011
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Guy Harris