| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add @file markers for most files that
contain functions exported with
WS_DLL_PUBLIC so that Doxygen will
generate documentation for them.
|
|
Clients of libwireshark should not be required to initialize
explicitly wiretap, if they don't use it themselves.
|
|
|
|
Rcv.Wind.Shift and Snd.Wind.Shift were not displayed correctly by
the BBLog dissector and the TCP dissector was not using the
information about the shift values available in the BBLog file.
|
|
|
|
The new block type enlarge payload lens up to 4B,
to support larger payload sizes.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
|
|
This patch adds direction support, so that incoming and outgoing frames
can be differentiated.
|
|
Each "packet" in the USB encapsulation formats for at least
Linux and Darwin corresponds to an OS-level USB request, so
the packets can be much larger than a USB-level packet.
The default max packet length of 256 KiB prevents Wireshark
from loading capture files that contain requests >256 KiB.
(Saving such a capture already works fine.)
Fix this by making the Linux, Darwin, and FreeBSD formats
use the same max packet length as the USBPCap format, which
is 128 MiB.
|
|
Fix some warnings complaining of macro redefinitions with stdint.h.
Include stdint.h via wireshark.h everywhere so it stays fixed.
|
|
Remove ws_diag_control.h from config.h because that was a workaround
for the lack of a public global header. Fix the resultant build errors.
|
|
|
|
/home/pi/wireshark/wiretap/file_wrappers.c: In function ‘file_fdopen’:
/home/pi/wireshark/wiretap/file_wrappers.c:1136:27: error: comparison of integer expressions of different signedness: ‘__blksize_t’ {aka ‘long int’} and ‘unsigned int’ [-Werror=sign-compare]
if (st.st_blksize <= MAX_READ_BUF_SIZE)
^~
cc1: all warnings being treated as errors
|
|
Files not having the eri_enb_log_magic should not be opened as a
eNode-B raw log file format.
|
|
|
|
Very large 64 bit files are supported, so the CAM Inspector and
Ixia Veriwave heuristics, which are fairly weak and either always
(CAM Inspector) or possibly (Veriwave) try to read the entire file
should stop their heuristics and make a decision after some reasonable
length.
Without this, the GUI freezes for seconds, minutes, or even hours
by merely clicking on a large file in the file chooser, as
wtap_open_offline attempts to determine the file type. The same issue
occurs in capinfos, captype, tshark, editcap, etc.
In addition, previously the CAM Inspector heuristics could give the wrong
result on very large files, because 10 * invalid_pairs could overflow
its guint32 and then end up comparing as less than valid_pairs.
Fix #17620
|
|
This is part of the API and should also be renamed to avoid conflicts.
|
|
Support reloading a Lua FileHandler when this is in use for a
loaded capture file. Prompt to save the file if having unsaved
changes because the file must be reloaded.
Fixes #17615
|
|
The file type/subtype for built-in types are <=
wtap_num_builtin_file_types_subtypes - the plugin types are given
type/subtype values after the last built-in type/subtype value.
Fixes #17614.
|
|
|
|
|
|
If the *first* read for a packet gets an EOF, it means that there is an
EOF right at the point where you're reading, which means "no more
packets".
If you get an EOF on any *subsequent* reads for the packet, it means the
file was cut off in the middle of the packet's record, which is an error.
|
|
ws_debug() inserts the file name, line number, and function name into
the ws_debug() message (assuming the function name can be obtained from
a macro), so there's no need to include it in the text of the message
(we don't do so elsewhere).
|
|
Set the block, presence flags, capture length, and length there.
|
|
|
|
This has a few effects on the behavior of wtap_get_compression_type()
and wtap_get_all_compression_type_extensions():
Make capinfos correctly report the compression type (instead of
saying gzip compressed for zstd and lz4 compressed files).
Makes files with the .zstd and .lz4 extension show up in the file
chooser when "Files of type" is set to something other than "All Files",
such as "All Capture Files" or "Wireshark/... pcapng"
Makes the UI not default to gzip compression when saving a file
compressed as zstd or lz4 (write support for zstd and lz4 doesn't
exist yet, and the GUI doesn't have hooks for it anyway, though
this can help as a prerequisite for later support for writing.)
Also replace a couple of assert() with ws_assert().
Update the PURPOSE in CMakeLists for zstd and lz4 to note that they
can be used to read compressed capture files.
|
|
Fix indentation of a while() clause, so that it's indented less than the
body of the while() loop.
|
|
It's not used outside blf.c.
|
|
The Ubuntu build commented on some spelling errors in executable code
files. Fix the errors that don't come from external files containing
the spelling errors (USB product and vendor IDs, PCI IDs, ASN.1
specifications), and fix some errors that don't show up in the
executable code files (e.g., in comments and variable names).
|
|
As we did in earlier changes.
|
|
This patch adds support for LIN Messages in BLF.
|
|
Move the if_filter and packet_verdict option stuff after the custom
option stuff in various places.
Fix some comments while we're at it.
|
|
Use the same style of message for too-short block errors ("pcapng: total
block length XXX of {a,an} XXX is too small...").
Add an additional check for the "skip" Netflix cutom block, to make sure
it has enough room for the 4-byte "skipped" value.
|
|
|
|
|
|
wblock->internal is not initialized on pcapng_read_custom_block function
pcapng.c:3747:9: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
|
|
pcapng.c:2675:5: warning: Value stored to 'opt_cont_buf_len' is never read [deadcode.DeadStores]
|
|
nettrace_3gpp_32_423.c:256:2: warning: Value stored to 'prev_pos' is never read [deadcode.DeadStores]
nettrace_3gpp_32_423.c:295:2: warning: Value stored to 'next_msg_pos' is never read [deadcode.DeadStores]
nettrace_3gpp_32_423.c:487:4: warning: Value stored to 'port_type_defined' is never read [deadcode.DeadStores]
|
|
|
|
|
|
(It appears gsize/gssize are now the same size as size_t, even on 64-bit
Windows, i.e. they're long longs on 64-bit Windows.)
|
|
|
|
Use guint for them, and don't let the buffer sizes get bigger than 2^30,
so they all fit in a guint.
|
|
|
|
- Describe zstd and lz4 support in man pages
- Update AUTHORS
- Update mime types to recognize zstd and lz4
|
|
Use compute_options_size() to get the total size of all the options, and
use write_options() to write out the options for those blocks, as we do
for other blocks.
Get rid of wtap_block_option_get_value_size() and
wtap_block_get_options_size_padded(); they're no longer needed, and
their notion of an option's "size" is "size in a pcapng file", so that
doesn't belong in code that's intended to support all file types.
|
|
That routine now only processes frame records; call it
process_frame_record().
|
|
Have a routine to read the Sniffer record header, and call that in
ngsniffer_read() and ngsniffer_seek_read(). Only call
ngsniffer_process_record() for frame records that we understand, so that
we only allocate a block for those rather than for records we don't
understand or for EOF records, potentially leaking them.
|
|
Without that, you could add a comment to a record in a file format the
reading code for which doesn't allocate blocks, but the comment doesn't
get saved, as there's no block in which to save the comment option.
This simplifies some code paths, as we're either using the record's
modified block or we're using the block as read from the file, there's
no third possibility.
If we attempt to read a record, and we get an error, and a block was
allocated for the record, unreference it, so the individual file readers
don't have to worry about it.
|
|
It's already included by wtap/wtap.h, which this file includes, and it
doesn't need to be included that early, so that #include isn't
necessary.
|
|
That's how it's done in other files, and the two are somewhat connected
(the record type and block type are somewhat correlated).
|
