Printing NULL string pointers with printf format %s is an undefined
behaviour.
pcap_datalink_val_to_name() may return NULL on unknown DLT_ value.
tcpdump terminated with Segmentation Fault on such case on Solaris 10
SPARC with Solaris Studio 12.3 compiler.
Also, don't use the length of the fixed-length portion of the PPI header
as the metadata length, use the *entire* length.
Otherwise, "-x" doesn't start printing at the link-layer payload.
The purpose of this macro was to enable the file-by-file switch to NDO,
after which only tcpdump.c had a use of it and the definitions guarded
by it. Update tcpdump.c not to require them any more and dismiss the
unused definitions.
Remove the TTEST{2}/TCHECK{2} macros. Rename all "ndo_printer" routines,
structures, and structure members to just "printer", and get rid of the
old routines/structures/structure members with those names.
Header printing (-e) had a stray ", " before the header; remove it.
Payload printing was skipping only the fixed portion of the PPI header,
not the entire header.
And, as we require at least autoconf 2.61, and as autoconf 2.61 and
later have AC_TYPE_UINTn_T and AC_TYPE_INTn_T macros, we use them to
define the uintN_t and intN_t macros if the system doesn't define them
for us.
This lets us get rid of bitypes.h as well.
Have them take a netdissect_options * argument, and get the "no name
resolution" flag from it.
Move the declaration of dnaddr_string to addrtoname.h, along with the
other XXX-to-string routines.
Both interface.h and netdissect.h include <pcap.h>, thus most files
should not include it regardless if these need it or not. The only
exceptions so far remain:
* addrtoname.c
* missing/datalinks.c
* missing/dlnames.c
* tcpdump.c
For headers included in only one source file, put the header contents in
the source file in question, and get rid of a bunch of stuff from the
header not used in the source file.
To: tcpdump-workers@lists.tcpdump.org
Date: Sat, 09 Apr 2011 12:51:14 +1000
Subject: [tcpdump-workers] Printing PPI packets
Printing PPI packets with tcpdump does not turn out
to be that hard.
My simple tests have produced the output as below.
It would be worthwhile having some changes made into
the tcpdump code base that were similar to the attached
that print them out.
