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 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.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
Provide a wiretap routine to get an array of all savable file
type/subtypes, sorted with pcap and pcapng at the top, followed by the
other types, sorted either by the name or the description.
Use that routine to list options for the -F flag for various commands
Rename wtap_get_savable_file_types_subtypes() to
wtap_get_savable_file_types_subtypes_for_file(), to indicate that it
provides an array of all file type/subtypes in which a given file can be
saved. Have it sort all types, other than the default type/subtype and,
if there is one, the "other" type (both of which are put at the top), by
the name or the description.
Don't allow wtap_register_file_type_subtypes() to override any existing
registrations; have them always register a new type. In that routine,
if there are any emply slots in the table, due to an entry being
unregistered, use it rather than allocating a new slot.
Don't allow unregistration of built-in types.
Rename the "dump open table" to the "file type/subtype table", as it has
entries for all types/subtypes, even if we can't write them.
Initialize that table in a routine that pre-allocates the GArray before
filling it with built-in types/subtypes, so it doesn't keep getting
reallocated.
Get rid of wtap_num_file_types_subtypes - it's just a copy of the size
of the GArray.
Don't have wtap_file_type_subtype_description() crash if handed an
file type/subtype that isn't a valid array index - just return NULL, as
we do with wtap_file_type_subtype_name().
In wtap_name_to_file_type_subtype(), don't use WTAP_FILE_TYPE_SUBTYPE_
names for the backwards-compatibility names - map those names to the
current names, and then look them up. This reduces the number of
uses of hardwired WTAP_FILE_TYPE_SUBTYPE_ values.
Clean up the type of wtap_module_count - it has no need to be a gulong.
Have built-in wiretap file handlers register names to be used for their
file type/subtypes, rather than building the table in init.lua.
Add a new Lua C function get_wtap_filetypes() to construct the
wtap_filetypes table, based on the registered names, and use it in
init.lua.
Add a #define WSLUA_INTERNAL_FUNCTION to register functions intended
only for internal use in init.lua, so they can be made available from
Lua without being documented.
Get rid of WTAP_NUM_FILE_TYPES_SUBTYPES - most code has no need to use
it, as it can just request arrays of types, and the space of
type/subtype codes can be sparse due to registration in any case, so
code has to be careful using it.
wtap_get_num_file_types_subtypes() is no longer used, so remove it. It
returns the number of elements in the file type/subtype array, which is
not necessarily the name of known file type/subtypes, as there may have
been some deregistered types, and those types do *not* get removed from
the array, they just get cleared so that they're available for future
allocation (we don't want the indices of any registered types to changes
if another type is deregistered, as those indicates are the type/subtype
values, so we can't shrink the array).
Clean up white space and remove some comments that shouldn't have been
added.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
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>
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>
Pass the correct buffer size to find_signature so that we don't read
past it.
Bug: 15279
Change-Id: I822ed0fe8b48196dadd9c0062ed53fa1c4f6f404
Reviewed-on: https://code.wireshark.org/review/30809
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
We set the file encapsulation to WTAP_ENCAP_IXVERIWAVE when we open the
file; we don't need to update it when we read packets. and we don't need
to set the per-packet encapsulation because it's set to the file
encapsulation for us by wtap_read() and wtap_seek_read().
Change-Id: I2f123e3fb0d505334f3451685290bdbae77a598b
Reviewed-on: https://code.wireshark.org/review/30622
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>
If it's either going to be -1 or 1, and any value > 0 is "valid but
empty", that's just a Boolean, with -1 corresponding to false and 1
corresponding to true. Make it so.
Change-Id: Ib7418fe7573b5d2cd1e2ef5de601c0262c8d9de1
Reviewed-on: https://code.wireshark.org/review/25605
Reviewed-by: Guy Harris <guy@alum.mit.edu>
A short read isn't a clear error when you don't have a magic number and
are doing "does this look somewhat like a file of this type" test, it's
probably an indication that it's *not* a file of that type.
Change-Id: Iab2f32e7d169a777c50a36958eeb4e82a3809227
Reviewed-on: https://code.wireshark.org/review/25602
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Move the signature timestamp bounds checks inside get_signature_ts. Fix
what appears to be an off-by-one error.
Bug: 14297
Change-Id: I9ca1762a8418e47153f270a1a62b2d0d3a800130
Reviewed-on: https://code.wireshark.org/review/25229
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
If we're not going to subtract 4 from actual_octets, there's no reason
to treat actual_octets < 4 as an error.
This makes the "subtract 4 octets of crap" code similar in all cases,
hopefully further reducing the opacity of the code.
Change-Id: I41cda101b321422ce5fd4474fb6903bfe471cb63
Reviewed-on: https://code.wireshark.org/review/23534
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(In the hope of making the code slightly less opaque.)
Change-Id: Ic635eedac4eb9fb764b3633c9003608b9b4ae3df
Reviewed-on: https://code.wireshark.org/review/23533
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Be consistent in the treatment of those 4 octets.
Change-Id: If35c94bd299c3e7ec76306daf325d5aa5e3a19b9
Reviewed-on: https://code.wireshark.org/review/23530
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>
For HT mixed, set it the same way it's set for HT greenfield.
For pre-HT, set it to 0.
Also, for the "unknown" case, set rate_mcs_index to 0.
This should obviate the need to initialize either of those variables,
don't initialize them, so that failing to set them in an arm of the
switch statement shows up as an error if the compiler's dataflow
analysis actually bothers to check this.
Change-Id: I92703770dd5000a579b53609fb93a2085fd9fca3
Reviewed-on: https://code.wireshark.org/review/21573
Reviewed-by: Guy Harris <guy@alum.mit.edu>
I don't know whether this is a bug in the software or a lack of support
in the hardware.
This at least notes the issue in CID 1405905.
Change-Id: I481454bc38842a0f877cb8b52b73e1156fd362b5
Reviewed-on: https://code.wireshark.org/review/21558
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That's valid only for 3 or 6 spatial streams; return 0 as the bitrate
for all other values. Also, handle the 6 spatial streams case.
Give the conversion tables explicit sizes, to make it clear what
subscripts are valid.
Return 0 for an MCS > 9, for consistency with the other error return,
and to mark it as clearly wrong.
Fixes CID 1405908.
Change-Id: Icbf655c63c0e88fd6cec7c66bae85fd887a3bd9c
Reviewed-on: https://code.wireshark.org/review/21557
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That should remove the need to initialize them, make it clearer what
values are being used in the "RF only" case, and catch any cases where
they don't get set in the "not just RF" case in the future.
Change-Id: I10c3ecef608ed2f481111fb7bc32bb8494b68d27
Reviewed-on: https://code.wireshark.org/review/21536
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Prevents some compiler warnings
Change-Id: I9d62d0f3e6b7794c5ed43f37d52f86d81344a33c
Reviewed-on: https://code.wireshark.org/review/21531
Reviewed-by: Michael Mann <mmann78@netscape.net>
Add some parentheses to make an expression clearer to people who haven't
memorized the table of C operator precedences.
Don't fiddle the nss variable in place; explicitly combine it with the
IS_TX value when we put it in the header, to make it clearer what's in
that header byte.
Change-Id: I870b892fb9dab2bc210956f923e0183f4e147989
Reviewed-on: https://code.wireshark.org/review/21530
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The packet-ixveriwave.c dissector appears to do so.
Change-Id: Ie02c4611ef18e83abcd3b625bbc40014080ffca1
Reviewed-on: https://code.wireshark.org/review/21525
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Do the MCS -> NSS mapping for HT by a table lookup.
For VHT with Series II, do it the old way for now, under the assumption
that the MCS index and NSS are bit fields, but note that the MCS index
and NSS bit fields would overlap.
Change-Id: Ibc89590faf15900171b2a1b4ac1e50793ed70c32
Reviewed-on: https://code.wireshark.org/review/21523
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That maeks the code a little clearer.
It also makes it clearer that the "MCS index" is, for pre-HT, a rate
index, so rename some variables and macros.
Change-Id: I64b7bca073df0f837e5d968682345187000207fc
Reviewed-on: https://code.wireshark.org/review/21521
Reviewed-by: Guy Harris <guy@alum.mit.edu>
They're not necessary for most hardware; remove the unnecessary checks,
and add comments indicating why they're not necessary (or fix the
"maximum value of actual_octets is" part of the comment).
They *are* necessary for Series III hardware; put in the check.
Change-Id: Idd64a74099d5cf7398a2ddb850442e53c9206724
Reviewed-on: https://code.wireshark.org/review/21491
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add some additional blank lines, remove some extra, blank lines, fix
indentation.
Make vVW510024_E_IS_VLAN 32-bits, to match the other flags.
Change-Id: Id1cd63ff2b75764907a44e9f8525b1537666fde1
Reviewed-on: https://code.wireshark.org/review/21488
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There's only a 17-byte PLCP header with the Series III hardware.
Change-Id: Ice8dfbbc5daa0578ee4eb6588fc8a8b597806d0d
Reviewed-on: https://code.wireshark.org/review/21487
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That makes it clearer that the Series I hardware doesn't do HT or VHT.
Change-Id: Ibeccfcba997555bef06098828f01951dc32a6d2c
Reviewed-on: https://code.wireshark.org/review/21486
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Guy Harris