NAME
pdump 0.779-2 - dumps, greps, monitors, creates, and modifies traffic on a network
SYNOPSIS
pdump [ -aAbCfGhILmMnNOpqRStTuUvVXzZ ] [ -B hostname ] [ -c count ]
[ -d destination-host ] [ -D destination-port ] [ -E 'expression' ]
[ -F file ] [ -g [ 'regexp' ] ] [ -H 'regexp' ]
[ -i interface ] [ -l /pdump/directory ] [ -P 'regexp' ]
[ -Q MAC address ] [ -r file ] [ -s snaplen ]
[ -w file ] [ -W 'service1, service2' ]
[ -y source-host ] [ -Y source-port ]
DESCRIPTION
Pdump prints out the headers of packets on a network
interface that match the boolean expression. Pdump
does many other things such as sniffing raw data, sniffing
for passwords or specified packets, spoofing things such as
MAC addresses, modifies network packets, creates well
crafted packets, along with many other things. Pdump
requires root on all operating systems it's run on. Future
development on a pdump-specific perl module will attempt to
minimize the security risk and only require certain access
on specific systems.
OPTIONS
-a Will attempt to get the operating system of all of
the packets flying by by checking such things as the
window size, TTL, etc..
-A Print all valid arguements usable with pdump.
-b Sniffs all outgoing web GETs and POSTs and will output
all URLs sniffed and will also send your browser
directly to the pages that other users on the network
are browsing live. This is almost identical to dsniff's
webspy.
-B This will do the same thing as the -b option except it
will only sniff a certain user on the network. You
specify that user with their hostname, that being the
element passed to -B.
-c Exit after receiving count packets.
-C Case-insensitive to the regular expression used with
-H.
-d Uses hostname as the destination hostname when used
with -M.
-D Uses port as the destination port when used with -M.
-E Only dumps packets which match expression. Scroll
down for detailed information on expressions along
with examples in the expressions section.
-f Print `foreign' internet addresses numerically rather
than symbolically (this option is intended for
tcpdump to get around serious brain damage in Sun's yp
server - usually it hangs forever translating
non-local internet numbers).
-F Use file as input for the filter expression. An addi-
tional expression given on the command line is ignored.
-g Prints all data from a packet if the data matches the
regular expression. Scroll down to the expressions
for detailed information on the option, regular
expressions, and examples. If no regular expressoin is
given it will match all data going through the filter.
This option can also be used with the -L option. See
the -L option for further information.
-G Case-insensitive to the regular expression used with
-g.
-h Display help screen.
-H Matches hostnames and IP addresses with the regular
expression and will print all packets except for those
that matched.
-i Listen on interface. If unspecified, pdump searches
the system interface list for the lowest numbered,
configured up interface (excluding loopback). Ties
are broken by choosing the earliest match.
-I Case-insensitive to the regular expression used with
-P.
-l Will take the directory you specify and expect the lib
directory to be in the directory you specified so you
can run pdump from any directory. Example: your lib
directory is at /usr/pdump/lib. You aren't in the
/usr/pdump directory so you run 'pdump -l /usr/pdump'
and pdump will then use /usr/pdump/lib as the lib
directory automatically.
-L Will sniff all email going through the network and
display it in Berkeley mbox format, which is readable
offline by many clients such as mail(1) and pine(1).
You are able to use the -g option along with a regular
expression to match the header/body with. If the email
is matched, the message will be displayed, otherwise,
it won't be. The -G options will match the regular
expression with case-insensitivity. The -O option will
do the opposite of -g, using the regular expression
from -g and will display any messages where the
body/header doesn't match the regular expression. This
option is a 'clone' of dsniff's mailsnarf and does the
same exact thing that mailsnarf does, possibly even
what carnivore does. :)
-m Uses a different method of extracting IP addresses out
of packets. On a few systems pdump may display invalid
or incorrect IP addresses of packets and this function
should fix that problem if that problem occurs.
-M Floods the local network with random MAC addresses
the same way macof would and is able to crash some
network devices.
-n Don't convert addresses (i.e., host addresses, port
numbers, etc.) to names.
-N Don't print domain name qualification of host names.
E.g., if you give this flag then pdump will print
``nic'' instead of ``nic.ddn.mil''.
-O Matches any data from packets which don't match the
regular expression used with -g.
-p Don't put the interface into promiscuous mode. Note
that the interface might be in promiscuous mode for
some other reason; hence, `-p' cannot be used as an
abbreviation for `ether host {local-hw-addr} or ether
broadcast'. This is module specific. This option will
be active in the next module for pdump.
-P Matches port numbers and services with th e regular
expression and will print all packets except for those
that match.
-q Quick (quiet?) output. Print less protocol informa-
tion so output lines are shorter. With -g, doesn't
output any information other than packet headers and
their payloads.
-Q Sets MAC address as the destination address when using
-M.
-r Read packets from file (which was created with the -w
option). Standard input is used if file is ``-''.
-R Uses random destination MAC addresses when using -M.
-s Snarf snaplen bytes of data from each packet rather
than the default of 68 (with SunOS's NIT, the minimum
is actually 96). 68 bytes is adequate for IP, ICMP,
TCP and UDP but may truncate protocol information from
name server and NFS packets (see below). Packets trun-
cated because of a limited snapshot are indicated in
the output with ``[|proto]'', where proto is the name
of the protocol level at which the truncation has
occurred. Note that taking larger snapshots both
increases the amount of time it takes to process pack-
ets and, effectively, decreases the amount of packet
buffering. This may cause packets to be lost. You
should limit snaplen to the smallest number that will
capture the protocol information you're interested in.
-S Print port numbers instead of services.
-t Don't print a timestamp on each dump line.
-T Print an unformatted timestamp on each dump line.
-u Uses ANSI color for most everything. Colors are
defined at the top of pdump.pl and can be very easily
changed.
-U Outputs all requested URLs sniffed from HTTP traffic.
-v (Slightly more) verbose output. For example, the time
to live and type of service information in an IP packet
is printed.
-V Displays version information and exits.
-w Write the raw packets to file rather than parsing and
printing them out. They can later be printed with the
-r option. Standard output is used if file is ``-''.
-W Sniffs passwords, user names, and other information
from all services specified. Specify the services in a
comma-delimited fashion. All of the protocols that are
able to be sniffed are protocols that dsniff is able to
sniff.
-X Will do everything you specify or do not specify in
pdump except for sniffing any traffic that matches your
IP address.
-y Uses hostname as the source hostname when used with
-M.
-Y Uses port as the source port when used with -M.
-z Would be like using -g without any regular expression
at all so pdump would print all data from all packets
that are allowed to be printed.
-Z Lists all services that are usable with -W.
# Much of the below is from tcpdump's man page # Great explanations and examples for libpcap # and most of it is compliant with pdump
Expressions
select which packets will be dumped. If no expression
is given, all packets on the net will be dumped. Oth-
erwise, only packets for which expression is `true'
will be dumped.
The expression consists of one or more primitives.
Primitives usually consist of an id (name or number)
preceded by one or more qualifiers. There are three
different kinds of qualifier:
type qualifiers say what kind of thing the id name or
number refers to. Possible types are host, net
and port. E.g., `host foo', `net 128.3', `port
20'. If there is no type qualifier, host is
assumed.
dir qualifiers specify a particular transfer direction
to and/or from id. Possible directions are src,
dst, src or dst and src and dst. E.g., `src foo',
`dst net 128.3', `src or dst port ftp-data'. If
there is no dir qualifier, src or dst is assumed.
For `null' link layers (i.e. point to point proto-
cols such as slip) the inbound and outbound qual-
ifiers can be used to specify a desired direction.
proto
qualifiers restrict the match to a particular pro-
tocol. Possible protos are: ether, fddi, ip,
arp, rarp, decnet, lat, sca, moprc, mopdl, tcp and
udp. E.g., `ether src foo', `arp net 128.3', `tcp
port 21'. If there is no proto qualifier, all
protocols consistent with the type are assumed.
E.g., `src foo' means `(ip or arp or rarp) src
foo' (except the latter is not legal syntax), `net
bar' means `(ip or arp or rarp) net bar' and `port
53' means `(tcp or udp) port 53'.
[`fddi' is actually an alias for `ether'; the parser
treats them identically as meaning ``the data link
level used on the specified network interface.'' FDDI
headers contain Ethernet-like source and destination
addresses, and often contain Ethernet-like packet
types, so you can filter on these FDDI fields just as
with the analogous Ethernet fields. FDDI headers also
contain other fields, but you cannot name them expli-
citly in a filter expression.]
In addition to the above, there are some special `prim-
itive' keywords that don't follow the pattern: gate-
way, broadcast, less, greater and arithmetic expres-
sions. All of these are described below.
More complex filter expressions are built up by using
the words and, or and not to combine primitives. E.g.,
`host foo and not port ftp and not port ftp-data'. To
save typing, identical qualifier lists can be omitted.
E.g., `tcp dst port ftp or ftp-data or domain' is
exactly the same as `tcp dst port ftp or tcp dst port
ftp-data or tcp dst port domain'.
Allowable primitives are:
dst host host
True if the IP destination field of the packet is
host, which may be either an address or a name.
src host host
True if the IP source field of the packet is host.
host host
True if either the IP source or destination of the
packet is host. Any of the above host expressions
can be prepended with the keywords, ip, arp, or
rarp as in:
ip host host
which is equivalent to:
ether proto \ip and host host
If host is a name with multiple IP addresses, each
address will be checked for a match.
ether dst ehost
True if the ethernet destination address is ehost.
Ehost may be either a name from /etc/ethers or a
number (see ethers(3N) for numeric format).
ether src ehost
True if the ethernet source address is ehost.
ether host ehost
True if either the ethernet source or destination
address is ehost.
gateway host
True if the packet used host as a gateway. I.e.,
the ethernet source or destination address was
host but neither the IP source nor the IP destina-
tion was host. Host must be a name and must be
found in both /etc/hosts and /etc/ethers. (An
equivalent expression is
ether host ehost and not host host
which can be used with either names or numbers for
host / ehost.)
dst net net
True if the IP destination address of the packet
has a network number of net. Net may be either a
name from /etc/networks or a network number (see
networks(4) for details).
src net net
True if the IP source address of the packet has a
network number of net.
net net
True if either the IP source or destination
address of the packet has a network number of net.
net net mask mask
True if the IP address matches net with the
specific netmask. May be qualified with src or
dst.
net net/len
True if the IP address matches net a netmask len
bits wide. May be qualified with src or dst.
dst port port
True if the packet is ip/tcp or ip/udp and has a
destination port value of port. The port can be a
number or a name used in /etc/services (see
tcp(4P) and udp(4P)). If a name is used, both the
port number and protocol are checked. If a number
or ambiguous name is used, only the port number is
checked (e.g., dst port 513 will print both
tcp/login traffic and udp/who traffic, and port
domain will print both tcp/domain and udp/domain
traffic).
src port port
True if the packet has a source port value of
port.
port port
True if either the source or destination port of
the packet is port. Any of the above port expres-
sions can be prepended with the keywords, tcp or
udp, as in:
tcp src port port
which matches only tcp packets whose source port
is port.
less length
True if the packet has a length less than or equal
to length. This is equivalent to:
len <= length.
greater length
True if the packet has a length greater than or
equal to length. This is equivalent to:
len >= length.
ip proto protocol
True if the packet is an ip packet (see ip(4P)) of
protocol type protocol. Protocol can be a number
or one of the names icmp, igrp, udp, nd, or tcp.
Note that the identifiers tcp, udp, and icmp are
also keywords and must be escaped via backslash
(\), which is \\ in the C-shell.
ether broadcast
True if the packet is an ethernet broadcast
packet. The ether keyword is optional.
ip broadcast
True if the packet is an IP broadcast packet. It
checks for both the all-zeroes and all-ones broad-
cast conventions, and looks up the local subnet
mask.
ether multicast
True if the packet is an ethernet multicast
packet. The ether keyword is optional. This is
shorthand for `ether[0] & 1 != 0'.
ip multicast
True if the packet is an IP multicast packet.
ether proto protocol
True if the packet is of ether type protocol.
Protocol can be a number or a name like ip, arp,
or rarp. Note these identifiers are also keywords
and must be escaped via backslash (\). [In the
case of FDDI (e.g., `fddi protocol arp'), the pro-
tocol identification comes from the 802.2 Logical
Link Control (LLC) header, which is usually lay-
ered on top of the FDDI header. Pdump assumes,
when filtering on the protocol identifier, that
all FDDI packets include an LLC header, and that
the LLC header is in so-called SNAP format.]
decnet src host
True if the DECNET source address is host, which
may be an address of the form ``10.123'', or a
DECNET host name. [DECNET host name support is
only available on Ultrix systems that are config-
ured to run DECNET.]
decnet dst host
True if the DECNET destination address is host.
decnet host host
True if either the DECNET source or destination
address is host.
ip, arp, rarp, decnet
Abbreviations for:
ether proto p
where p is one of the above protocols.
lat, moprc, mopdl
Abbreviations for:
ether proto p
where p is one of the above protocols. Note that
pdump does not currently know how to parse these
protocols.
tcp, udp, icmp
Abbreviations for:
ip proto p
where p is one of the above protocols.
expr relop expr
True if the relation holds, where relop is one of
>, <, >=, <=, =, !=, and expr is an arithmetic
expression composed of integer constants
(expressed in standard C syntax), the normal
binary operators [+, -, *, /, &, |], a length
operator, and special packet data accessors. To
access data inside the packet, use the following
syntax:
proto [ expr : size ]
Proto is one of ether, fddi, ip, arp, rarp, tcp,
udp, or icmp, and indicates the protocol layer for
the index operation. The byte offset, relative to
the indicated protocol layer, is given by expr.
Size is optional and indicates the number of bytes
in the field of interest; it can be either one,
two, or four, and defaults to one. The length
operator, indicated by the keyword len, gives the
length of the packet.
For example, `ether[0] & 1 != 0' catches all mul-
ticast traffic. The expression `ip[0] & 0xf != 5'
catches all IP packets with options. The expres-
sion `ip[6:2] & 0x1fff = 0' catches only unfrag-
mented datagrams and frag zero of fragmented
datagrams. This check is implicitly applied to
the tcp and udp index operations. For instance,
tcp[0] always means the first byte of the TCP
header, and never means the first byte of an
intervening fragment.
Primitives may be combined using:
A parenthesized group of primitives and operators
(parentheses are special to the Shell and must be
escaped).
Negation (`!' or `not').
Concatenation (`&&' or `and').
Alternation (`||' or `or').
Negation has highest precedence. Alternation and con-
catenation have equal precedence and associate left to
right. Note that explicit and tokens, not juxtaposi-
tion, are now required for concatenation.
If an identifier is given without a keyword, the most
recent keyword is assumed. For example,
'not host vs and ace'
is short for
'not host vs and host ace'
which should not be confused with
'not ( host vs or ace )'
Expression arguments can be passed to pdump as either
a single argument or as multiple arguments, whichever
is more convenient. Generally, if the expression con-
tains Shell metacharacters, it is easier to pass it as
a single, quoted argument. Multiple arguments are con-
catenated with spaces before being parsed.
# Examples which pdump can handle (of course!)
EXAMPLES
To print all packets arriving at or departing from sundown:
pdump -E "host sundown"
To print traffic between helios and either hot or ace:
pdump -E "host helios and \( hot or ace \)"
To print all IP packets between ace and any host except
helios:
pdump -E "ip host ace and not helios"
To print all traffic between local hosts and hosts at Berke-
ley:
pdump -E "net ucb-ether"
To print all ftp traffic through internet gateway snup:
(note that the expression is quoted to prevent the shell
from (mis-)interpreting the parentheses):
pdump -E 'gateway snup and (port ftp or ftp-data)'
To print traffic neither sourced from nor destined for local
hosts (if you gateway to one other net, this stuff should
never make it onto your local net).
pdump -E "ip and not net localnet"
To print the start and end packets (the SYN and FIN packets)
of each TCP conversation that involves a non-local host.
pdump -E 'tcp[13] & 3 != 0 and not src and dst net localnet'
To print IP packets longer than 576 bytes sent through gate-
way snup:
pdump -E 'gateway snup and ip[2:2] > 576'
To print IP broadcast or multicast packets that were not
sent via ethernet broadcast or multicast:
pdump -E 'ether[0] & 1 = 0 and ip[16] >= 224'
To print all ICMP packets that are not echo requests/replies
(i.e., not ping packets):
pdump -E 'icmp[0] != 8 and icmp[0] != 0"
# More great tcpdump information
OUTPUT FORMAT
The output of pdump is protocol dependent. The following
gives a brief description and examples of most of the for-
mats.
(N.B.:The following description assumes familiarity with the
TCP protocol described in RFC-793. If you are not familiar
with the protocol, neither this description nor pdump will
be of much use to you.)
The general format of a tcp protocol line is:
src > dst: flags data-seqno ack window urgent options
Src and dst are the source and destination IP addresses and
ports. Flags are some combination of S (SYN), F (FIN), P
(PUSH) or R (RST) or a single `.' (no flags). Data-seqno
describes the portion of sequence space covered by the data
in this packet (see example below). Ack is sequence number
of the next data expected the other direction on this con-
nection. Window is the number of bytes of receive buffer
space available the other direction on this connection. Urg
indicates there is `urgent' data in the packet. Options are
tcp options enclosed in angle brackets (e.g., <mss 1024>).
Src, dst and flags are always present. The other fields
depend on the contents of the packet's tcp protocol header
and are output only if appropriate.
Here is the opening portion of an rlogin from host rtsg to
host csam.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
The first line says that tcp port 1023 on rtsg sent a packet
to port login on csam. The S indicates that the SYN flag
was set. The packet sequence number was 768512 and it con-
tained no data. (The notation is `first:last(nbytes)' which
means `sequence numbers first up to but not including last
which is nbytes bytes of user data'.) There was no piggy-
backed ack, the available receive window was 4096 bytes and
there was a max-segment-size option requesting an mss of
1024 bytes.
Csam replies with a similar packet except it includes a
piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN.
The `.' means no flags were set. The packet contained no
data so there is no data sequence number. Note that the ack
sequence number is a small integer (1). The first time
pdump sees a tcp `conversation', it prints the sequence
number from the packet. On subsequent packets of the
conversation, the difference between the current packet's
sequence number and this initial sequence number is printed.
This means that sequence numbers after the first can be
interpreted as relative byte positions in the conversation's
data stream (with the first data byte each direction being
`1'). `-S' will override this feature, causing the original
sequence numbers to be output.
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2
through 20 in the rtsg -> csam side of the conversation).
The PUSH flag is set in the packet. On the 7th line, csam
says it's received data sent by rtsg up to but not including
byte 21. Most of this data is apparently sitting in the
socket buffer since csam's receive window has gotten 19
bytes smaller. Csam also sends one byte of data to rtsg in
this packet. On the 8th and 9th lines, csam sends two bytes
of urgent, pushed data to rtsg.
UDP Packets
UDP format is illustrated by this rwho packet:
actinide.who > broadcast.who: udp 84
This says that port who on host actinide sent a udp datagram
to port who on host broadcast, the Internet broadcast
address. The packet contained 84 bytes of user data.
Some UDP services are recognized (from the source or desti-
nation port number) and the higher level protocol informa-
tion printed. In particular, Domain Name service requests
(RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS.
UDP Name Server Requests
(N.B.:The following description assumes familiarity with the
Domain Service protocol described in RFC-1035. If you are
not familiar with the protocol, the following description
will appear to be written in greek.)
Name server requests are formatted as
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
Host h2opolo asked the domain server on helios for an
address record (qtype=A) associated with the name
ucbvax.berkeley.edu. The query id was `3'. The `+' indi-
cates the recursion desired flag was set. The query length
was 37 bytes, not including the UDP and IP protocol headers.
The query operation was the normal one, Query, so the op
field was omitted. If the op had been anything else, it
would have been printed between the `3' and the `+'. Simi-
larly, the qclass was the normal one, C_IN, and omitted.
Any other qclass would have been printed immediately after
the `A'.
A few anomalies are checked and may result in extra fields
enclosed in square brackets: If a query contains an answer,
name server or authority section, ancount, nscount, or
arcount are printed as `[na]', `[nn]' or `[nau]' where n is
the appropriate count. If any of the response bits are set
(AA, RA or rcode) or any of the `must be zero' bits are set
in bytes two and three, `[b2&3=x]' is printed, where x is
the hex value of header bytes two and three.
UDP Name Server Responses
Name server responses are formatted as
src > dst: id op rcode flags a/n/au type class data (len)
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
In the first example, helios responds to query id 3 from
h2opolo with 3 answer records, 3 name server records and 7
authority records. The first answer record is type A
(address) and its data is internet address 128.32.137.3.
The total size of the response was 273 bytes, excluding UDP
and IP headers. The op (Query) and response code (NoError)
were omitted, as was the class (C_IN) of the A record.
In the second example, helios responds to query 2 with a
response code of non-existent domain (NXDomain) with no
answers, one name server and no authority records. The `*'
indicates that the authoritative answer bit was set. Since
there were no answers, no type, class or data were printed.
Other flag characters that might appear are `- ' (recursion
available, RA, not set) and `|' (truncated message, TC,
set). If the `question' section doesn't contain exactly one
entry, `[nq]' is printed.
Note that name server requests and responses tend to be
large and the default snaplen of 68 bytes may not capture
enough of the packet to print. Use the -s flag to increase
the snaplen if you need to seriously investigate name server
traffic. `-s 128' has worked well for me.
Timestamps
By default, all output lines are preceded by a timestamp.
The timestamp is the current clock time in the form
hh:mm:ss.frac
and is as accurate as the kernel's clock. The timestamp
reflects the time the kernel first saw the packet. No
attempt is made to account for the time lag between when the
ethernet interface removed the packet from the wire and when
the kernel serviced the `new packet' interrupt.
SEE ALSO
traffic(1C), nit(4P), bpf(4), pcap(3), tcpdump(1), ngrep(8)
AUTHORS
Samy Kamkar, SKamkar@LucidX.com -
Much of the information here was used from tcpdump(1)'s man
page which can be found (tcpdump) at ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
The authors of many of these sections are (as in tcpdump's
current man page):
Van Jacobson, Craig Leres and Steven McCanne, all of the
Lawrence Berkeley National Laboratory, University of Calif-
ornia, Berkeley, CA.
BUGS
Please send bug reports to SKamkar@LucidX.com.
# Last bit of tcpdump
NIT doesn't let you watch your own outbound traffic, BPF
will. We recommend that you use the latter.
pdump for Ultrix requires Ultrix version 4.0 or later; the
kernel has to have been built with the packetfilter pseudo-
device driver (see packetfilter(4)). In order to watch
either your own outbound or inbound traffic, you will need
to use Ultrix version 4.2 or later, and you will have to
have used the pfconfig(8) command to enable ``copyall''
mode.
Under SunOS 4.1, the packet capture code (or Streams NIT) is
not what you'd call efficient. Don't plan on doing much
with your Sun while you're monitoring a busy network.
On Sun systems prior to release 3.2, NIT is very buggy. If
run on an old system, pdump may crash the machine.
Some attempt should be made to reassemble IP fragments or,
at least to compute the right length for the higher level
protocol.
Name server inverse queries are not dumped correctly: The
(empty) question section is printed rather than real query
in the answer section. Some believe that inverse queries
are themselves a bug and prefer to fix the program generat-
ing them rather than pdump.
Apple Ethertalk DDP packets could be dumped as easily as KIP
DDP packets but aren't. Even if we were inclined to do any-
thing to promote the use of Ethertalk (we aren't), LBL
doesn't allow Ethertalk on any of its networks so we'd would
have no way of testing this code.
A packet trace that crosses a daylight savings time change
will give skewed time stamps (the time change is ignored).
Filters expressions that manipulate FDDI headers assume that
all FDDI packets are encapsulated Ethernet packets. This is
true for IP, ARP, and DECNET Phase IV, but is not true for
protocols such as ISO CLNS. Therefore, the filter may inad-
vertently accept certain packets that do not properly match
the filter expression.