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>
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>
lseek returns an off_t type which is system-dependent. Use ws_lseek64 in
favor of lseek as that supports 64-bit quanities.
Use ws_fstat64 instead of stat to support 64-bit file sizes on Windows.
For the majority of the changes, this makes no difference as they do not
apply to Windows ("ifndef _WIN32"; availability of st_blksize).
There are no other users of "struct stat" besides the portability code
in wsutil. Forbid the use of fstat and lseek in checkAPIs.
Change-Id: I17b930ab9543f21a9d3100f3795d250c9b9ae459
Reviewed-on: https://code.wireshark.org/review/3198
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I really don't understand why MSVC would make the result of this computation an
int64 then complain about down-casting to an int16 when *all* of the
participating variables are int16 or smaller...
Change-Id: I2d9c27ac22b51b10e4872a6640881c8d0ec566e7
Reviewed-on: https://code.wireshark.org/review/3180
Reviewed-by: Evan Huus <eapache@gmail.com>
Exported PDU may contains (Binary) Logcat, so it is possible to
"export" logcat binary from it.
Change-Id: Ic6607126e739ea3972b46c2bf19f064597d4e970
Reviewed-on: https://code.wireshark.org/review/3001
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>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
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>
That prevents some double-free issues (I got one when doing non-"Update
list of packets in real time" captures, if I do one such capture and
then another one).
Change-Id: Ia08034d9d1640bad21b74960efade8926dbfc5de
Reviewed-on: https://code.wireshark.org/review/3063
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The logcat version detector would crash with ASAN enabled because it did
not validate the payload length and hence a payload length of 0 would
trigger out-of-bounds access. (This happened on non-logcat data.)
This patch tries to get rid of all magic numbers by using a structure,
improves the version detector to validate the payload length and
prevents crashes due to missing nul-terminators in the input. Older
Android kernels would create entries with __pad with random contents, so
that cannot be used to determine version for v1. Instead, use heuristics
on the priority, tag and maybe the msg field.
Furthermore, Android is mostly (if not, always?) Little-Endian, so add
conversions where necessary (just in case WS supports BE arches).
"microseconds" has been renamed to "milliseconds" because that is what
they are, actually. A duplicate logcat_log loop has been refactored
such that one loop is sufficient, instead of separate buffers for each
log part, a single one is now used. get_priority does not really need
a pointer, just make it accept a character.
The output has been validated against v1 and v2 logcat binary formats
with __pad (hdr_size) equal to 0, and on attachment 9906.
Change-Id: I46c8813e76fe705b293ffdee85b4c1bfff7d8362
Reviewed-on: https://code.wireshark.org/review/2803
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Guy Harris