tcpdump.man

3 网卡驱动相关实例 这是和网卡NT KMD驱动程序有关的一些资料和例子。

       Appletalk addresses are printed in the form
              _n_e_t_._h_o_s_t_._p_o_r_t

              144.1.209.2 > icsd-net.112.220
              office.2 > icsd-net.112.220
              jssmag.149.235 > icsd-net.2
       _(_I_f  _t_h_e _/_e_t_c_/_a_t_a_l_k_._n_a_m_e_s doesn't exist or doesn't contain
       an entry for some appletalk host/net number, addresses are
       printed  in numeric form.)  In the first example, NBP (DDP
       port 2) on net 144.1 node 209 is sending  to  whatever  is
       listening  on  port  220 of net icsd node 112.  The second
       line is the same except the full name of the  source  node
       is  known  (`office').  The third line is a send from port
       235 on net jssmag node 149 to broadcast  on  the  icsd-net
       NBP  port  (note that the broadcast address (255) is indi-
       cated by a net name with no host number - for this  reason
       it's a good idea to keep node names and net names distinct
       in /etc/atalk.names).

       NBP (name binding protocol) and ATP (Appletalk transaction
       protocol)  packets have their contents interpreted.  Other
       protocols just dump the protocol name  (or  number  if  no
       name is registered for the protocol) and packet size.

       NNBBPP ppaacckkeettss are formatted like the following examples:
              icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
              jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
              techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
       TThhee  ffiirrsstt  lliinnee iiss aa nnaammee llooookkuupp rreeqquueesstt ffoorr llaasseerrwwrriitteerrss
       sseenntt bbyy nneett iiccssdd hhoosstt 111122 aanndd  bbrrooaaddccaasstt  oonn  nneett  jjssssmmaagg..
       TThhee nnbbpp iidd ffoorr tthhee llooookkuupp iiss 119900..  TThhee sseeccoonndd lliinnee sshhoowwss aa
       rreeppllyy ffoorr tthhiiss rreeqquueesstt ((nnoottee tthhaatt iitt hhaass tthhee ssaammee iidd)) ffrroomm
       hhoosstt  jjssssmmaagg..220099 ssaayyiinngg tthhaatt iitt hhaass aa llaasseerrwwrriitteerr rreessoouurrccee
       nnaammeedd ""RRMM11114400"" rreeggiisstteerreedd oonn ppoorrtt 225500..  TThhee tthhiirrdd lliinnee  iiss
       aannootthheerr  rreeppllyy ttoo tthhee ssaammee rreeqquueesstt ssaayyiinngg hhoosstt tteecchhppiitt hhaass
       llaasseerrwwrriitteerr ""tteecchhppiitt"" rreeggiisstteerreedd oonn ppoorrtt 118866..

       AATTPP ppaacckkeett ffoorrmmaattttiinngg iiss  ddeemmoonnssttrraatteedd  bbyy  tthhee  ffoolllloowwiinngg
       eexxaammppllee::
              jjssssmmaagg..220099..116655 >> hheelliiooss..113322:: aattpp--rreeqq  1122226666<<00--77>> 00xxaaee003300000011
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::00 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::11 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::22 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::33 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::44 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::55 ((551122)) 00xxaaee004400000000



                           30 June 1997                        16





TCPDUMP(1)                                             TCPDUMP(1)


              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::66 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp**1122226666::77 ((551122)) 00xxaaee004400000000
              jjssssmmaagg..220099..116655 >> hheelliiooss..113322:: aattpp--rreeqq  1122226666<<33,,55>> 00xxaaee003300000011
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::33 ((551122)) 00xxaaee004400000000
              hheelliiooss..113322 >> jjssssmmaagg..220099..116655:: aattpp--rreesspp 1122226666::55 ((551122)) 00xxaaee004400000000
              jjssssmmaagg..220099..116655 >> hheelliiooss..113322:: aattpp--rreell  1122226666<<00--77>> 00xxaaee003300000011
              jjssssmmaagg..220099..113333 >> hheelliiooss..113322:: aattpp--rreeqq** 1122226677<<00--77>> 00xxaaee003300000022
       JJssssmmaagg..220099 iinniittiiaatteess ttrraannssaaccttiioonn iidd 1122226666 wwiitthh hhoosstt hheelliiooss
       bbyy rreeqquueessttiinngg uupp ttoo 88 ppaacckkeettss ((tthhee ``<<00--77>>''))..  TThhee hheexx nnuumm--
       bbeerr  aatt tthhee eenndd ooff tthhee lliinnee iiss tthhee vvaalluuee ooff tthhee ``uusseerrddaattaa''
       ffiieelldd iinn tthhee rreeqquueesstt..

       Helios responds with 8  512-byte  packets.   The  `:digit'
       following  the  transaction  id  gives the packet sequence
       number in the transaction and the number in parens is  the
       amount  of  data  in the packet, excluding the atp header.
       The `*' on packet 7 indicates that the EOM bit was set.

       Jssmag.209 then requests that packets 3 & 5 be retransmit-
       ted.   Helios  resends  them  then jssmag.209 releases the
       transaction.   Finally,  jssmag.209  initiates  the   next
       request.   The  `*'  on  the  request  indicates  that  XO
       (`exactly once') was _n_o_t set.


       IIPP FFrraaggmmeennttaattiioonn

       Fragmented Internet datagrams are printed as
              ((ffrraagg _i_d::_s_i_z_e@@_o_f_f_s_e_t++))
              ((ffrraagg _i_d::_s_i_z_e@@_o_f_f_s_e_t))
       (The first form indicates there are more  fragments.   The
       second indicates this is the last fragment.)

       _I_d  is  the  fragment  id.   _S_i_z_e is the fragment size (in
       bytes) excluding the IP header.  _O_f_f_s_e_t is this fragment's
       offset (in bytes) in the original datagram.

       The fragment information is output for each fragment.  The
       first fragment contains the higher level  protocol  header
       and  the  frag  info  is  printed after the protocol info.
       Fragments after the first contain no higher level protocol
       header  and  the frag info is printed after the source and
       destination addresses.  For example, here is  part  of  an
       ftp from arizona.edu to lbl-rtsg.arpa over a CSNET connec-
       tion that doesn't appear to handle 576 byte datagrams:
              arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
              arizona > rtsg: (frag 595a:204@328)
              rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
       There are  a  couple  of  things  to  note  here:   First,
       addresses  in  the  2nd  line  don't include port numbers.
       This is because the TCP protocol information is all in the
       first  fragment  and  we  have  no  idea  what the port or
       sequence numbers are when we print  the  later  fragments.
       Second,  the tcp sequence information in the first line is



                           30 June 1997                        17





TCPDUMP(1)                                             TCPDUMP(1)


       printed as if there were 308 bytes of user data  when,  in
       fact,  there  are 512 bytes (308 in the first frag and 204
       in the second).  If you  are  looking  for  holes  in  the
       sequence  space  or  trying to match up acks with packets,
       this can fool you.

       A packet with the IP _d_o_n_'_t _f_r_a_g_m_e_n_t flag is marked with  a
       trailing ((DDFF)).

       TTiimmeessttaammppss

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

SSEEEE AALLSSOO
       traffic(1C), nit(4P), bpf(4), pcap(3)

AAUUTTHHOORRSS
       Van Jacobson, Craig Leres and Steven McCanne, all  of  the
       Lawrence Berkeley National Laboratory, University of Cali-
       fornia, Berkeley, CA.

       The current version is available via anonymous ftp:

              _f_t_p_:_/_/_f_t_p_._e_e_._l_b_l_._g_o_v_/_t_c_p_d_u_m_p_._t_a_r_._Z

BBUUGGSS
       Please send bug reports to [e-mail].

       NIT doesn't let you watch your own outbound  traffic,  BPF
       will.  We recommend that you use the latter.

       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  gener-
       ating them rather than tcpdump.

       Apple  Ethertalk  DDP packets could be dumped as easily as
       KIP DDP packets but aren't.  Even if we were  inclined  to
       do  anything  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.




                           30 June 1997                        18





TCPDUMP(1)                                             TCPDUMP(1)


       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  fil-
       ter  may  inadvertently accept certain packets that do not
       properly match the filter expression.
















































                           30 June 1997                        19