Switch RRCP and BGP functions from tok2strbuf() to tok2str() to avoid
unnecessary local buffer management. The latter function does it in a
way to allow up to 4 calls to itself from printf(). After that
tok2strbuf() remains used by tok2str() only and can be refined later.
Remove a duplicate macro and place the remaining definition into the
right file.
The checksum only covers the header, not the encapsulated packet, so
only checksum that. However, if that checksum fails, try checksumming
the entire packet, as, according to RFC 4601, packets with the entire
packet checksummed should also be accepted, for interoperability.
Add IS_NOT_NEGATIVE macro.
Avoid these warnings:
- comparison of unsigned expression >= 0 is always true [-Wtype-limits],
- comparison is always true due to limited range of data type [-Wtype-limits].
This header can be used with Marvell switches to direct packets in/out
of a specific port in a tree of interconnected switches. The header
uses its own Ethertype of 0xdada.
By default, only brief output is printed, showing the switch device,
port, and vlan the packet is to/from. However if -e is given, to print
the link-level header, all fields are printed.
This prevents the compiler issue mentioned in GitHub issue #451, and
also cleans up some other signed vs. unsigned stuff.
While we're at it, clean up bittok2str_internal() (just pass it the
separator string, not a Boolean value that's tested to choose the
separator string), and print unknown arguments to the bittok2str
routines in hex, not decimal.
Have llc_print() return the length of the LLC header, plus the length of
the SNAP header, if available - or, if it couldn't dissect the payload,
return the *negative* of that sum. Use that return value in link-layer
printers.
Don't print LLC header information for SNAP packets; if we have a SNAP
header, just call snap_print() and return its return value, regardless
of whether it's 1 or 0, don't fall into the code to print raw LLC header
information - and don't print it with -e, either.
If llc_print() returns 0, just call the default packet printer, don't
print the MAC-layer header or the extracted ethertype - llc_print() will
print the source and destination MAC addresses and whatever type
information is in the LLC or SNAP headers.
If we don't know the DSAP/LSAP, and it's an information frame (numbered
or not) and not an XID frame, return 0, so that we give a hex dump of
the raw payload.
In addition, print the length when printing SNAP header information with
-e.
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.
If libpcap has pcap_set_immediate_mode(), then default to immediate mode
if we're printing packets to a terminal, and use immediate mode if
--immediate-mode is specified.
While we're at it, just use the record count to when iterating over
records; the ND_TCHECK()s will make sure we don't run past the end of
the captured data.
Also get rid of an unused argument to cnfp_print().
"Text protocols" are protocols that have the general feel of FTP, with
command lines with a command name and space-separated arguments and
response lines beginning with a 3-digit reply code. They can also
include HTTP-style headers and an entity body.
We add support for the FTP control channel, HTTP, SMTP, and RTSP. We
also change the SIP printer to use it.
Always define and declare ip6_print(), always compile print-ip6.c, and
always call it if we recognize a payload as IPv6. If INET6 isn't
defined, ip6_print() will just print the length and note that printing
isn't supported.
That way, we don't do weird dissection of IPv6 packets on systems
without IPv6 support, due to, for example, ethertype_print() returning 0
("not dissected") for IPv6 packets on those systems (IPv6-over-Frame
Relay was dissected weirdly due to this).
Make it 131072, instead; the MTU on the Linux loopback interface, in at
least some versions of the kernel, is 65536, and that doesn't count the
fake Ethernet header, so we need a value bigger than 65536. We don't
want a value that's *too* large, so that it causes attempts to allocate
huge amounts of memory, however.
This (plus the corresponding change to libpcap) should fix GitHub issue
A while ago we introduced new API in libpcap which made possible to
request time stamps with higher precision (nanoseconds). This commit
aims to move things forward and implement missing bits. It introduces
new long option --time-stamp-precision. Note that there is no equivalent
short option.
When used for a live capture tcpdump will ask the kernel for time stamp
with desired precision and tcpdump will print fraction part of the time
stamp using respective format. We currently support only microsecond and
nanosecond precision. In the future we might support even more granular
time stamp precision, but we should be fine to support only
microseconds and nanoseconds for now. libpcap doesn't provide anything
else at the moment anyway.
When used in combination with -r/-w options then we obtain time stamps
appropriately scaled up or down from libpcap. Also note that distinct
magic number is used for savefiles containing nanosecond time stamps.
The sample capture was produced with two Linux hosts (aoetools version
36, kernel module version 85, vblade version 21). One of the hosts
exported a 1MB block device containing a freshly created filesystem and
the other mounted it, wrote a small file and then unmounted.
Merge m3ua.h into the only file that includes it (print-m3ua.c). Make
M3UA functions follow naming pattern, constify some of their arguments
and switch to ND_PRINT(). Make use of tok2str() and ternary conditional.
Eliminate declarations in the middle of code (C89).
