pdump 0.8 - dumps, greps, monitors, creates, and modifies traffic on a network


     pdump  [ -abCfGILmMnNOpqRStTuUvxXzZ ] [ -A 'data string' ]    [ -B hostname ]
            [ -c count ]                   [ -d destination-host ] [ -D destination-port ]
            [ -e 'string' ]                [ -E 'expression' ]     [ -F file ]
            [ -g [ 'regexp' ] ]            [ -H 'regexp' ]         [ -i interface ]
            [ -J [ -1..9 ] ]               [ -l /pdump/directory ] [ -P 'regexp' ]
            [ -Q MAC address ]             [ -r file ]             [ -s snaplen ]
            [ -w file ]                    [ -W [ 'ftp, etc' ] ]   [ -y source-host ]
            [ -Y source-port ]


     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.


     -a    Will do  passive  network  mapping (passive  operating
          system  detection/fingerprinting),  similar  to siphon.
          This will attempt to show the operating  systems of all
          computers  which  are  incoming  or  outgoing  from the

     -A    This options requires -E to eliminate most problems :)
          What this option does is send packets into a connection
          without  disrupting it and keeping it in sync.  It does
          this by  sniffing  everything it can with -E and on the
          first connection it sees, it will 'zero in' on that one
          specific  connection.   Once  it has done that, it will
          send spoofed packets with  that data into the  connect-
          ion  without  hijacking  the  connection,   redirecting
          packets, and  without resetting the  connection.   This
          is a proof of concept and can show how easy it is to do
          things such as sending commands to a telnet  session or
          packets to an IRC server which would make some pretty
          easy takeovers of channels, etc..

     -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

     -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

     -d    Uses hostname as the  destination  hostname  when used
          with -M.

     -D    Uses port as the destination port when used with -M.

     -e    Will take string and  parse  it to have what comes out
          be only what the user wants.   Instead of having to see
          all information in the same order, you can specify only
          certain  things to be  displayed  and also things  that
          normally, if ever, aren't displayed.  See the 'Strings'
          section below for detailed  information along with many
          detailed examples.

     -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
          pdump  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

     -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

     -J    Will send  RST packets to all destination addresses or
          all destination  addresses  specified in an expression,
          using -E,  and will kill the connection.  Without using
          -E,  pdump  will kill all open  TCP  connections on the
          network.  This is identical to dsniff's tcpkill.

     -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 ``''.

     -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.

     -P    Matches  port  numbers and  services with the  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

     -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  and can be very easily

     -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.

     -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.   If  no  arguements are  specified,  all of the
          allowable arguements will be displayed.

     -x    Will dump all data in the packets in hex, very similar
          to tcpdump's -x option.

     -X    Will dump all data in  the packet in  hex  and  ascii,
          similar to tcpdump's -X option.
     -y    Uses  hostname  as the  source hostname when used with

     -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    This will sniff all traffic for FTP,  SMB,  and  Samba
          file  transfers.   When  it  sees one, it will give you
          some information and also  'swipe'  that file and stick
          it  in a  file  on  your local  machine  in the current
          directory  you're in.   It  will tell  you what file it
          places it in.


          are what allow the user to specify the look, feel,  and
          data that should be outputted with pdump instead of the
          conventional way.   Here is an example of what a normal
          TCP packet would look like with pdump:

18:39:35.488521 > P 134763246 ack 720092664 win 17520 (tcp)

          A lot of this information may be completely unimportant
          to you and there may be a lot of important  information
          missing from here that you want.  With the strings opt-
          ion on pdump (-e 'string')  you are  able to modify the
          output of pdump however you wish.   Here is an example:

bash# pdump -e '$time $source.$sserv > $dest.$dserv: $headers $sequence ack $ackseq win $winsize ($proto)' ( 0.780
(/usr/bin/pdump): listening on rl0 :: x.x.x.x []
18:39:35.488521 > P 134763246 ack 720092664 win 17520 (tcp)

          As you can see, this is exactly how the last packet  we
          saw looked like.   Here are  a  few  other  examples...

pdump -e '$source-$sport >>> $dest-$dport :: $seq _-_ tos $tos' >>> :: 134763246 _-_ tos 16

pdump -e '$saddr:$daddr - $sserv:$dserv' - http:4829

Here is the hash with information on what variables to use for what:

"saddr", $stest,     # source ip
"daddr", $dtest,     # dest ip
"source", $sname,    # source port
"dest", $dname,      # dest port
"shost", $sname,     # source hostname (ip if the ip doesn't reverse)
"dhost", $dname,     # dest hostname (ip if the ip doesn't reverse)

"sserv", $stype,
"dserv", $dtype,
"version", $vers,
"ihl", $ihl,

"tos", $tos,         # tos
"totlen", $tot,      # tot
"id", $id,           # id
"fragoff", $frg,     # fragment offset
"ttl", $ttl,         # ttl
"protocol", $pro,    # protocol number, example: 6
"proto", $prt,       # protocol name, example: tcp

"check1", $chc,
"rawsaddr", $saddr,
"rawdaddr", $daddr,

"sport", $sport,     # source port
"dport", $dport,     # dest port
"sequence", $seq,    # sequence
"seq", $seq,         # sequence (same as above)
"ackseq", $aseq,     # ack sequence

"doff", $dof,
"res1", $res1,
"res2", $res2,

"urg", $urg,         # returns 1 if urg is set
"ack", $ack,         # returns 1 if ack is set
"psh", $psh,         # returns 1 if psh is set
"rst", $rst,         # returns 1 if rst is set
"syn", $syn,         # returns 1 if syn is set
"fin", $fin,         # returns 1 if fin is set
"winsize", $win,     # window size
"hexwin", sprintf("%x", $win),  # hex output of the window size (good for fingerprinting)
"df", $df,           # returns (DF) if the packet frag offset is 16834
"check2", $chk,
"data", $data,       # data of packet
"time", $tm,         # millisecond

"headers", $headers, # headers, example: SR (for syn and rst)

        The strings on the left side are what you would use with the -e option,
        just with a $ in front of it stating that it's a variable.


          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

          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.

               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

          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

          src port port
               True if the packet has  a  source  port  value  of

          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

          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

          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
                    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

               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.


     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
          pdump -E "ip host ace and not helios"

     To print all traffic between local hosts and hosts at Berke-
          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'


     The output of  pdump  is protocol dependent.  The  following
     gives  a  brief description and examples of most of the for-

     (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? (37)
     Host h2opolo asked  the  domain  server  on  helios  for  an
     address   record   (qtype=A)   associated   with   the  name  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 (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
     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.


     By default, all output lines are preceded  by  a  timestamp.
     The timestamp is the current clock time in the form
     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.


     You can either join #pdump on  SUIDnet  (  or
     you can send me an  email at  and I'll
     reply as soon as I can with whatever questions/comments that
     you have.


     traffic(1C), nit(4P), bpf(4), pcap(3), tcpdump(1), ngrep(8),
     dsniff, siphon


     Samy Kamkar []
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of Calif- ornia, Berkeley, CA for parts of the Expressions and Output Format sections.


Please send bug reports to

     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''

     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

     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.