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.
You either have to set it to 1 or 0 if you know whether it's shifted
time or set it to -1 if you don't.
Should address Coverity CID 1452227.
Change-Id: I7d435bb6b7dd8897b44bf5103578e3db1a30379e
Reviewed-on: https://code.wireshark.org/review/34175
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Only CAN protocol is supported. Extra information available in J1939
entries is ignored since the J1939 wireshark dissector works with
raw CAN frames and makes no use of this extra information.
The log format may also encapsulate LIN messages which are not
supported by wireshark and thus are ignored.
The only limitation is that relative timestamp format is not
supported. If a file defines relative format of timestamps, packets
are extracted, but timestamps are omitted, since random access deems
impossible without reparsing the whole file up to the packet of
interest. In order to support relative timestamps we need to parse
the whole file at once on open and either dump into a temporary
PCAP file or keep messages in a private list and provide access
to them on read()/seek_read().
The change also creates a separate header for CAN frame structure
definitions which are used by several file readers (candump and
busmaster for now).
Bug: 15939
Change-Id: I87c5555e4e5e1b142b9984b24544b2591d494fbc
Reviewed-on: https://code.wireshark.org/review/34083
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Guy Harris