WTAP_ENCAP_UNKNOWN is used for two different cases:
1. Encapsulation type values that are unsupported by libwiretap or
bogus values (and thus "unknown" to libwiretap).
2. An initial state where the encapsulation type is "not yet" known
for a file type like pcapng without a single encapsulation type in the
header, before any packets or interfaces that set the encapsulation type
have been read. (If the file has no packets, this may be the value after
the file is entirely read in.) This can be the value when an output file
is written out simultaneously with reading an input file, rather than
reading the entire input file first, and, e.g., there is a custom block
before any IDBs.
The first case can never be handled when writing out a file, but the
second case can possibly be handled, so long as (for pcapng) IDBs
are available to write when they become necessary, or (for file
types like pcap with a single link-layer type in the header) the
writer waits until a link-layer type is seen to create the output
header. (It is possible, of course, that writing would fail in the
middle if an unsupported encapsulation type appears, or if the
encapsulation becomes per-packet for file types that don't support that,
but that is an unavoidable risk when writing without reading the entire
input file(s).)
Introduce WTAP_ENCAP_NONE for the second case, and use it for pcapng,
where we guarantee that any necessary IDBs will be passed along.
Continue to use WTAP_ENCAP_UNKNOWN for the first case.
Allow pcapng files to open a file for writing with WTAP_ENCAP_NONE.
There are some other file types that support per-packet link-types,
and could also use WTAP_ENCAP_NONE, but they require more work to
generate IDBs. (Note that all of them currently are impossible to
write to pcapng when they have multiple encapsulations, even if
the encapsulations are all supported by pcapng, because they don't
properly generate IDBs.)
Remove the workaround in ef43fd48b4
for tshark writing to pcapng when the source file is WTAP_ENCAP_UNKNOWN,
since now such files will be WTAP_ENCAP_NONE and work properly (and
also work in editcap, mergcap, etc.)
Along with 8cddc32d35, fix#18449.
Forcing the use of a dedicated header to replace pcap.h is
unnecessary code and mental overhead in this case. We can
use config.h instead for the same purpose of defining a
macro symbol before including pcap.h.
Tweak the script used for creating a new skeleton dissector, to allow it
to create the dissector in `plugins/epan/PROTOSHORTNAME` instead of in
`epan/dissectors`. Handles modifying the appropriate CMake file in the
appropriate way, and generates the plugin's `CMakeLists.txt` if needed.
Intitialize some environment variables using `brew shellenv`.
Speexdsp is required. Make some variable names match their respective
command line flags.
Instead of having AUTHORS.src and copying that to a new AUTHORS
file with git log information appended to that have a single
AUHTORS file and update it in place with git log info.
Remove some unused historical files.
Aggressively disable warnings to keep the lemon source
pristine and avoid the maintenance burden for lemon itself.
Lemon has its own lax policy for warnings that doesn't match our
own and they won't accept external patches to remove the
warnings, so just ignore them. Lemon is just executed to generate
code for the Wireshark build and the minor code issues it has
have no influence at runtime.
For lemon generated code we selectively disable some linting
warnings.
Remove patches for lemon and lempar, they are no longer required
with these changes to silence warnings.
cmake is already in the basic list of packages. "cmake3" is
necessary for RHEL/CentOS 7 (where the "cmake" package is 2.8.12),
but that distribution isn't supported on 4.0 and later.
At the same time, the OpenSUSE 15.4 repository accidentally has
a "cmake3" package which is an earlier version than the "cmake" RPM,
which creates some conflicts when trying to install both.
(https://gitlab.com/wireshark/wireshark-containers/-/jobs/3328997023)
So, don't attempt to install cmake3 anymore.
Make changes to packet-skinny.c.in and SkinnyProtocolOptimized.xml
that incorporate changes from 67f05835ca
and 8efad466c4 made to the dissector
manually and regenerate. Also fix a case where a comment mixed
tabs and spaces, which caused the python conversion tool to complain.
Convert parse_xml2skinny_dissector.py to Python 3.
This is mostly the output of running 2to3, but some of the
uses of dict.keys() were left as is instead of being converted
to lists, since only membership was tested.
The dissector still needs to be regenerated, which will happen
in a next commit, so that this change can be easily backported.
Martin Mathieson