Have them take error code and error information string arguments and,
for various failures, fill them in as "internal error" indications.
Check their return codes to see if they got an error.
Let individual file type/subtype modules register their
backwards-compatibility names, rather than having a centralized table
that would need to be updated along with the module.
It only registers one file type/subtype, so rename it to
wtap_register_file_type_subtype().
That will also force plugins to be recompiled; that will produce compile
errors for some plugins that didn't change to match the new contents of
the file_type_subtype_info structure.
Also check to make sure that the registered file type/subtype supports
at least one type of block; a file type/subtype that doesn't return
*any* blocks and doesn't permit *any* block types to be written is not
very useful. That should also catch most if not all other plugins that
didn't change to match the new contents of the file_type_subtype_info
structure.
Don't make errors registering a file type/subtype fatal; just complain,
don't register the bogus file type/subtype, and drive on.
Register the pcap and pcapng file types/subtypes rather than hardwiring
them into the table.
Call the registration routines for them directly, rather than through a
generated table; they're always supposed to be there, as some code in
Wireshark either writes only one of those formats or defaults to writing
one of those formats. Don't run their source code through the
registration-routine-finder script.
Have the file type/subtype codes for them be directly exported to the
libwiretap core, and provide routines to return each of them, to be used
by the aforementioned code.
When reporting errors with cfile_write_failure_message(), use
wtap_dump_file_type_subtype() to get the file type/subtype value for the
wtap_dumper to which we're writing, rather than hardcoding it.
Have the "export PDU" code capable of supporting arbitrary file
types/subtypes, although we currently only use pcapng.
Get rid of declarations of now-static can_write_encap and
dump_open routines in various headers.
Adds a pre-commit hook for detecting and replacing
occurrences of `g_malloc()` and `wmem_alloc()` with
`g_new()` and `wmem_new()`, to improve the
readability of Wireshark's code, and
occurrences of
`g_malloc(sizeof(struct myobj) * foo)`
with
`g_new(struct myobj, foo)`
to prevent integer overflows
Also fixes all existing occurrences across
the codebase.
That makes them work as input to a mergecap that writes pcapng files.
File types that don't have a single per-file encapsulation type need
more work, with multiple fake IDBs, one for each packet encapsulation
type seen in the file, unless we can generate real IDBs.
Change-Id: I2859e4f7fb15ec0c0f31a4044dc15638e5db7826
Reviewed-on: https://code.wireshark.org/review/37983
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
It generates a fake IDB for files that don't have interface information
and that have a per-file encapsulation type, snapshot length, and time
stamp precision, and adds it to the file's list of IDBs.
Use it for libpcap.
We will use it later for other file formats, so that code such as the
mergecap code to merge into a pcapng file can handle input files that
don't have interface information.
(We should have a way to indicate whether the IDBs are real or fake, so
that capinfos and Statistics > Capture File Properties don't report
meaningless IDB information and make it look as if it's known that the
capture was done on one interface with the properties in question.)
Change-Id: Iec124bf3c7cbd4c69ec2ac7d0dd776e5287f8576
Reviewed-on: https://code.wireshark.org/review/37982
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
That can just be done at the end of libpcap_open(), rather than in
wtap_open_offline() immediately after the open routine - which, in this
case, would be libpcap_open() - returns. That's cleaner, as it puts
capture-file-type-dependent code in the capture-file-type-specific code.
Note, though, that it's a bit weird for LINKTYPE_ERF files (and it was
equally weird before this change), and that other capture file types
should be doing this as well.
Change-Id: Ida94779a2e1021c81314f82655ec1d0f2f14e960
Reviewed-on: https://code.wireshark.org/review/37022
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.net>
wiretap/erf_record.h has declarations for records in ERF files and in
LINKTYPE_ERF packets in pcap and pcapng files.
wiretap/erf-common.h has declarations of routines to be called by
pcap/pcapng reader code when processing LINKTYPE_ERF packets.
wiretap/erf.h is what's left, for use by wiretap/erf.c and the code with
the tables of file readers and writers.
Change-Id: Ia982e79b14a025a80dcbc7c812fb3b2cdb9c6aaa
Reviewed-on: https://code.wireshark.org/review/37021
Petri-Dish: Guy Harris <gharris@sonic.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <gharris@sonic.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>
That makes it - and the routines that implement it - work more like the
seek-read routine.
Change-Id: I0cace2d0e4c9ebfc21ac98fd1af1ec70f60a240d
Reviewed-on: https://code.wireshark.org/review/32727
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
If, in the process of opening the input file, we determine that it has
packets of more than one link-layer type, we can catch attempts to write
that file to a file of a format that doesn't support more than one
link-layer type at the time we try to open the output file.
If, however, we don't discover that the file has more than one
link-layer type until we've already created the output file - for
example, if we have a pcapng file with a new IDB, with a different
link-layer type from previous IDBs, after packet blocks for the earlier
interfces - we can't catch that until we try to write the packet.
Currently, that causes the packet's data to be written out as is, so the
output file claims it's of the file's link-layer type, causing programs
reading the file to misdissect the packet.
Report WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED on the write attempt
instead, and have a nicer error message for
WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED on a write.
Change-Id: Ic41f2e4367cfe5667eb30c88cc6d3bfe422462f6
Reviewed-on: https://code.wireshark.org/review/30617
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We always tell pcap_process_pseudo_header() to check to make sure the
pseudo-header isn't bigger than the captured data; no need for a flag
argument to tell it to do so.
Change-Id: I8310bb06a390a7f4a7a232ad140ae07955d52da1
Reviewed-on: https://code.wireshark.org/review/29833
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do all the per-record processing in a libpcap_try_record() routine. EOF
on the header is OK, but a short read on the header *might* be due to
the format being tested not being the format of the file rather than due
to the file having been cut short.
Change-Id: I5748ed550fa1079dc9c746fd93ee5c59187b80a1
Reviewed-on: https://code.wireshark.org/review/27135
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Try to read up to 3 pcap records, making the value a #define so that we
can crank it up if necessary.
Bug: 14595
Change-Id: Ie9d62a1763fe7d1d46fdd8781691ea975770f3d7
Reviewed-on: https://code.wireshark.org/review/27111
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Separate the stuff that any record could have from the stuff that only
particular record types have; put the latter into a union, and put all
that into a wtap_rec structure.
Add some record-type checks as necessary.
Change-Id: Id6b3486858f826fce4b096c59231f463e44bfaa2
Reviewed-on: https://code.wireshark.org/review/25696
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Instead, just:
assume a file with the regular pcap magic number is a regular pcap
file, not an unhelpfully-modified-without-changing-the-magic-number
format such as one of the (fortunately, short-lived) memory-mapped
capture formats or the Nokia format;
reject a file with the memory-mapped-capture-finally-changed-the-
magic-number magic number, as they then changed the *new* format
without changing its magic number;
and don't even leave a provision for multiple formats using the
"nanosecond pcap" magic number - not even when reading from a file -
so we can punish bad behavior (which is what changing the format
without changing the magic number is).
This should get rid of the last place where, when reading a pcap file
from a pipe, the first packet isn't displayed as soon as it arrives.
Bug: 14345
Change-Id: I2fcb3354dc84cdd2d8ec749a0db883e56971c4b4
Reviewed-on: https://code.wireshark.org/review/25383
Reviewed-by: Guy Harris <guy@alum.mit.edu>
IXIA^WKeysight Technologies's vitual IxNetwork version 8.30 will
create capture files in a modified format: It uses a different magic
and adds the total size of all records, i.e. the filesize minus the
headersize. Add support for this.
v2: Different file types use different magic numbers.
Not yet tested/supported: The default fileending is .lcap
Bug: 14073
Change-Id: Ida90b188ca66a78ff22dca237e4fd6b22e02dc14
Reviewed-on: https://code.wireshark.org/review/23614
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
In change 18a3b0659c, I moved the table
that uses it, but not the actual definition, from libpcap.c to
pcap-common.c; they both should have been moved. Make it so.
Change-Id: I266fce455df3848b873cdfadb12cecdbf9c8d4d3
Reviewed-on: https://code.wireshark.org/review/22216
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The only place the time stamp precision is used is in the libpcap code,
where it determines whether to write out microsecond-precision or
nanosecond-precision time stamps; we can determine that by looking at
the type/subtype field, which is also part of that structure, so do
that.
We weren't setting it consistently - we were only setting it in libpcap
and a few other capture file writers, and not in other capture file
writers - and none of the writers other than libpcap used it.
Change-Id: If53779cf4823ca936b8bf3e8a7dbcfea5850e652
Reviewed-on: https://code.wireshark.org/review/21171
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If the seek forward is just skipping record content that's not
(currently) interesting, use wtap_read_bytes() with a null buffer
pointer; it catches short "reads" and requires less seeking, so it may
work better when reading from a pipe.
Change-Id: Ifb07d20e0391a8ed97da85149d971b4e9ef093a8
Reviewed-on: https://code.wireshark.org/review/17976
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Allow file_read() to take a null pointer as a buffer argument; a null
argument means "do everything except copy the bytes from the file to the
user buffer". That means that wtap_read_bytes() and
wtap_read_bytes_or_eof() also support a null pointer as a buffer
argument.
Use wtap_read_bytes() with a null buffer argument rather than
file_skip() to skip forward over data.
This fixes some places where files were mis-identified as ERF files, as
the ERF open heuristics now get a short "read" error if they try to skip
over more bytes than exist in the file.
Change-Id: I4f73499d877c1f582e2bcf9b045034880cb09622
Reviewed-on: https://code.wireshark.org/review/17974
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add encap_priv pointer to libpcap_t.
Initialize erf_priv when ENCAP_ERF.
Use erf_populate_interface_from_header() to dynamically create interfaces.
Free encap_priv on pcap_close.
Ping-Bug: 12303
Change-Id: Ieda425ef3e50a124d9c38ee4538aa3644128ce60
Reviewed-on: https://code.wireshark.org/review/15362
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It doesn't actually *close* any handle, so it's best called a "finish"
routine rather than a "close" routine.
In libwiretap modules, don't bother setting the finish routine pointer
to null - it's already initialized to null (it's probably best not to
require modules to set it).
Change-Id: I19554f3fb826db495f17b36600ae36222cbc21b0
Reviewed-on: https://code.wireshark.org/review/11659
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That indicates that it's a problem specific to *writing* capture files;
we've already converted some errors to that style, and added a new one
in that style.
Change-Id: I8268316fd8b1a9e301bf09ae970b4b1fbcb35c9d
Reviewed-on: https://code.wireshark.org/review/5826
Reviewed-by: Guy Harris <guy@alum.mit.edu>
For cases where record (meta)data is something that can't be written out
in a particular file format, return WTAP_ERR_UNWRITABLE_REC_DATA along
with an err_info string.
Report (and free) that err_info string in cases where
WTAP_ERR_UNWRITABLE_REC_DATA is returned.
Clean up some other error reporting cases, and flag with an XXX some
cases where we aren't reporting errors at all, while we're at it.
Change-Id: I91d02093af0d42c24ec4634c2c773b30f3d39ab3
Reviewed-on: https://code.wireshark.org/review/5823
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That makes it clearer what the problem is, and that it should only be
returned by the dump code path, not by the read code path.
Change-Id: I22d407efe3ae9fba7aa25f08f050317549866442
Reviewed-on: https://code.wireshark.org/review/5798
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That makes it clearer what the problem is, and that it should only be
returned by the dump code path, not by the read code path.
Change-Id: Icc5c9cff43be6c073f0467607555fa7138c5d074
Reviewed-on: https://code.wireshark.org/review/5797
Reviewed-by: Guy Harris <guy@alum.mit.edu>
WTAP_ERR_UNSUPPORTED_ENCAP means "I can't *write* that particular
encapsulation type to a file of this format", which mainly means "that
file format simply can't handle packets of that type";
WTAP_ERR_UNSUPPORTED means "this file can't currently be supported by
Wireshark, as there's some feature in the file - such as a file or
per-packet encapsulation type - that we don't (yet) handle".
Change-Id: I53cadf9913d20efb2bccb29f61877b71d53807be
Reviewed-on: https://code.wireshark.org/review/5794
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Clean up some things we ran across while making those changes.
Change-Id: Ic0d8943d36e6e120d7af0a6148fad98015d1e83e
Reviewed-on: https://code.wireshark.org/review/4581
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Unlike the standard I/O routines, the code we introduced that supports
fast random seeking on gzipped files will always supply some specific
error code for read errors, so we don't need WTAP_ERR_CANT_READ.
Add WTAP_ERR_CANT_WRITE for writing, as we're still using the standard
I/O routines for that. Set errno to WTAP_ERR_CANT_WRITE before calling
fwrite() in wtap_dump_file_write(), so that it's used if fwrite() fails
without setting errno.
Change-Id: I6bf066a6838284a532737aa65fd0c9bb3639ad63
Reviewed-on: https://code.wireshark.org/review/4540
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Pcap-ng files don't have a per-file time stamp resolution, they have a
per-interface time stamp resolution. Add new time stamp resolution
types of "unknown" and "per-packet", add the time stamp resolution to
struct wtap_pkthdr, have the libwiretap core initialize it to the
per-file time stamp resolution, and have pcap-ng do the same thing with
the resolution that it does with the packet encapsulation.
Get rid of the TS_PREC_AUTO_XXX values; just have TS_PREC_AUTO, which
means "use the packet's resolution to determine how many significant
digits to display". Rename all the WTAP_FILE_TSPREC_XXX values to
WTAP_TSPREC_XXX, as they're also used for per-packet values.
Change-Id: If9fd8f799b19836a5104aaa0870a951498886c69
Reviewed-on: https://code.wireshark.org/review/4349
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If it fails due to, for example, the file being gzipped and having a bad
gzip CRC, the error returned is WTAP_ERR_DECOMPRESS and, for that error,
err_info is expected to be set to a string giving details of the
problem, so we need to pass back to our caller the string in question.
Bug: 10484
Change-Id: I3aa2a92d04fcc08946ff073a40efa708079bbb3e
Reviewed-on: https://code.wireshark.org/review/4201
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When trying to guess what type of capture a file is, look for as many
bogosities (caplen > len, microseconds >= 10^6/nanoseconds >= 10^9,
too-high caplen, too-high original len, caplen > snapshort length), to
increase the chances of guessing correctly.
(Every time somebody uses 0xa1b2c3d4 as the magic number for a capture
file that isn't standard pcap format, God kills a kitten. Please, think
of the kittens.)
Change-Id: I3f397d598ed61dc82e2832be30452ebe8ace98e8
Reviewed-on: https://code.wireshark.org/review/3808
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In particular, epan/wslua/lrexlib.c has its own buffer_ routines,
causing some linker warnings on some platforms, as reported in bug
10332.
(Not to be backported to 1.12, as that would change the API and ABI of
libwsutil and libwiretap. We should also make the buffer_ routines in
epan/wslua/lrexlib.c static, which should also address this problem, but
the name change avoids other potential namespace collisions.)
Change-Id: I1d42c7d1778c7e4c019deb2608d476c52001ce28
Reviewed-on: https://code.wireshark.org/review/3351
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Otherwise, if you link with both libwiretap and libfiletap, it's
anybody's guess which one you get. That means you're wasting memory
with two copies of its routines if they're identical, and means
surprising behavior if they're not (which showed up when I was debugging
a double-free crash - fixing libwiretap's buffer_free() didn't fix the
problem, because Wireshark happened to be calling libfiletap' unfixed
buffer_free()).
There's nothing *tap-specific about Buffers, anyway, so it really
belongs in wsutil.
Change-Id: I91537e46917e91277981f8f3365a2c0873152870
Reviewed-on: https://code.wireshark.org/review/3066
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Also, make the block of code containing that comment intended
consistently with spaces.
Change-Id: I8e8eb346833662f15c53ece5869b12cc430bad11
Reviewed-on: https://code.wireshark.org/review/2661
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Guy Harris