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>
Instead of reading the 16-byte blob and record length at the same time,
just read the 16-byte blob, and then fall through to the record-length
reading code.
Change-Id: Ib2819a2d654e2670233821882bac79d7cd656b12
Reviewed-on: https://code.wireshark.org/review/4480
Reviewed-by: Guy Harris <guy@alum.mit.edu>
For code that's used in more than one place, use macros. This combines
a bunch of checks into the output macros.
Change-Id: Ic32dce75e1c531fd28bfed180856e230277bfe58
Reviewed-on: https://code.wireshark.org/review/4451
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>
The dump of the address info list must be differed to the end of the processing so as to know which host name was actually used in the capture
Bug: 10507
Change-Id: I44dbfae918d4ae92f9740c309804c7ff21bb4e1b
Reviewed-on: https://code.wireshark.org/review/4327
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>
It was being checked against the wrong value, so some invalid records
passed the check.
Also, change one comparison (rec_size is in the range [0, 65535], even
though it's in an int, so we can safely cast it to guint) and fix the
metadata length value when reading Ethernet packets.
Bug: 10495
Change-Id: I2ce5c93fe50d836ec0accfcdef31654ba6b5b7c7
Reviewed-on: https://code.wireshark.org/review/4278
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's called both from the read and seek-read routines, so it shouldn't
always read from the sequential handle.
Change-Id: I8cb33b9f5b7219f335b0aeeef29c479916276f89
Reviewed-on: https://code.wireshark.org/review/4276
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Make sure to zero the *entire* thing, and only access it as a given type when
that's the type indicated by the (non-union) type field.
Bug: 10498
Change-Id: I3e94a9c5d399d3ee4aedcd49f1aa2d7678ecf7ce
Reviewed-on: https://code.wireshark.org/review/4273
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
On errors *other* than a short read, we were driving on and processing
the non-data that we didn't read.
Change-Id: I6289ddf31ff7896918a030af9d1261bdc194e7d3
Reviewed-on: https://code.wireshark.org/review/4270
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Should fix the remaining test suite failures.
Change-Id: I50a6cb1bf57bd6a973d4777349708b75aeb41620
Reviewed-on: https://code.wireshark.org/review/4264
Reviewed-by: Evan Huus <eapache@gmail.com>
We can't use wtap_file_read_expected_bytes() in the _v7 version, as that
version returns an int, not a Boolean; just expand
wtap_file_read_expected_bytes() in the _v56 version, to make it look
similar to the _v7 version.
Change-Id: Id907bac265c123ad5821591c1cf081b5747724d8
Reviewed-on: https://code.wireshark.org/review/4262
Reviewed-by: Guy Harris <guy@alum.mit.edu>
wtap_file_read_expected_bytes() is a macro that can return a Boolean
FALSE; it should not be used in routines that don't return a Boolean.
In addition, both EOF *and* a short read, in that routine, should be
treated as a "not an IPFIX file" indication.
While we're at it, a seek failure should be treated as an error.
Change-Id: I97815bc9e78169ded567b60835cc7bcf6a0e6f0c
Reviewed-on: https://code.wireshark.org/review/4261
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I *think* I got all the cases; I got most of them, at any rate, and enough to
shut up valgrind in all the test cases I ran.
Change-Id: I393bac0756f577b65e400b792f6719fa6ec4056a
Reviewed-on: https://code.wireshark.org/review/4244
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
(If somebody wants to convert the entire file to 4-space indentation, go
ahead.)
Change-Id: I1e3829289ac67db79eea2eb16e6a4ba40c449a8d
Reviewed-on: https://code.wireshark.org/review/4250
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Most interesting are:
warning: cannot optimize loop, the loop counter may overflow [-Wunsafe-loop-optimizations]
warning: ISO C forbids zero-size array [-Wpedantic]
warning: ISO C90 doesn't support unnamed structs/unions [-Wpedantic]
warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual
warning: initializer element is not computable at load time [enabled by default]
Change-Id: I5573c6bdca856a304877d9bef643f8c0fa93cdaf
Reviewed-on: https://code.wireshark.org/review/3174
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
The only place where a short read should be treated as an EOF is if the
read of the block header reads 0 bytes. All other short reads,
including reads of the block header returning at least 1 byte but not
enough for a complete block header, and any reads of the stuff
*following* the block header even if they return 0 bytes, should be
treated as "short read" errors.
If the option length is bigger than the option buffer size, treat that
as a bad file (I'm not sure that can happen, so maybe it should be
treated as an internal error instead).
Use file_skip() rather than file_seek() when skipping forward N bytes.
If it fails, treat that as an error under all circumstances.
When reading the first section header block in the open routine, have
pcap_read_block() return -2 if it doesn't look like an SHB (too short,
wrong block type, bad block length, unknown byte-order magic number), as
that means the file isn't a pcap-ng file and the open should return 0.
Return -1, not 0, for all errors in various block-reading routines.
file_seek() returning 0 is *not* an error. file_seek() returning -1 (or
any other negative number *is* an error; its return value is signed, so
don't assign it to an unsigned variable.
This might fix the test errors for the Lua file format handler tests.
Change-Id: Ifa7d9834c38bf238461c9cc9625a2aa761cb6ff2
Reviewed-on: https://code.wireshark.org/review/4238
Reviewed-by: Guy Harris <guy@alum.mit.edu>
pcap_read_block() takes err and err_info arguments, and sets them on
error; no need to call file_error() if pcap_read_block() fails.
Change-Id: I33b96d31395bf7d66abdecbebd5cf775e8662004
Reviewed-on: https://code.wireshark.org/review/4209
Reviewed-by: Guy Harris <guy@alum.mit.edu>
If file_read() doesn't return the exact number of bytes you asked for,
and you really need all those bytes to be there, you have to call
file_error() to find out what the problem is.
Change-Id: I4cc87bc1b6cc5a49bbcbf93b56106f57af290d20
Reviewed-on: https://code.wireshark.org/review/4205
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>
I don't know why it was unavailable at some point, but it appears to be
available again. Update the comment to reflect that.
Change-Id: I7dc1fcb554e73d3b0fc2bd2fbdf6235e791a4253
Reviewed-on: https://code.wireshark.org/review/4200
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: Ied0778af9d5ff0e49c6efd4ea9411ae1a72cb8e5
Reviewed-on: https://code.wireshark.org/review/4190
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Add all logcat format like brief, threadtime, long, etc. when try to save
logcat logs where there is EXPORTED_PDU layer.
Change-Id: I338f0bbd46dd8db984efc1c03980c7e9c7401a44
Reviewed-on: https://code.wireshark.org/review/4164
Reviewed-by: Michal Orynicz <michal.orynicz@tieto.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Check the input pointer in the while clause of the loop, so that we
handle an empty input buffer.
When reading a bit mask, check before fetching the bit mask that we have
two bytes of bit mask and the byte after it.
Before putting an uncompressed input byte into the output, make sure we
wouldn't run past the end of the output buffer.
Before copying an earlier string from the output buffer, make sure it
doesn't run past the end of the data we've decompressed so far.
Bug: 10461
Change-Id: I8bb8d0d291368ae8bf0ac26970ff54d3262a7e6e
Reviewed-on: https://code.wireshark.org/review/4083
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We probably won't get files that big, but let's at least be prepared;
that squelches some compiler warnings.
Change-Id: Ia43ff78af7df63c7204c41d8331fea946de63116
Reviewed-on: https://code.wireshark.org/review/4015
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>
It's *NOT* an error; it's just a file that isn't a NetScaler file.
Otherwise, we report errors on files that should just be passed on to
other open routines.
Also, NetScaler files are *NOT* text files, and we should *NOT* use
".txt" as the suffix.
Change-Id: If001abbbbc3de3ea27439a44a47ce1d6071d38ae
Reviewed-on: https://code.wireshark.org/review/3678
Reviewed-by: Guy Harris <guy@alum.mit.edu>
-1 means "I got an error reading this file, so there's no point in
trying any more open routines". It doesn't mean "I couldn't find any
matching pattern in the text"; that's 0, for "this isn't my type of
file, but keep trying".
Change-Id: I9d2e8b8fe6720052cacf70f0bacdcbc1175202cc
Reviewed-on: https://code.wireshark.org/review/3674
Reviewed-by: Guy Harris <guy@alum.mit.edu>
* fix exporting "beginning of" frame logs into info field
* add missing "Failure" level to regexp in wiretap part
* remove usage of GDateTime from wiretap part
Change-Id: Ibdea730623241cccbbc1694a34daa308e48c0a89
Reviewed-on: https://code.wireshark.org/review/3493
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Wireshark already supports reading and writing logcat
logs saved in binary files. Binary format, although
better, is used less often than saving those logs to
text files.
This patch extends wireshark's support for android logcat
logs to reading and writing logcat logs in text files.
Features:
* support for tag, brief, process, thread, time, threadtime
and long formats
* saving in original format
* it's generally awesome
Change-Id: I013d6ac2da876d9a2b39b740219eb398d03830f6
Reviewed-on: https://code.wireshark.org/review/1802
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Guy Harris