The Tcpdump Group git mirrors - tcpdump/blob - README-AFS

   1 RX Patches for tcpdump 3.4
   2
   3 This directory contains a patch to tcpdump that decodes the information
   4 inside of RX packets (the protocol used by AFS).  Specifically, all of
   5 the RX header information is decoded, and many of the arguments to the
   6 AFS calls.
   7
   8 Some examples:
   9
  10 11:02:26.961538 elvis.7001 > pike.afsfs: rx data fs call rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" (84) (DF)
  11
  12 This is a RX call from elvis (a client) to pike (a fileserver).  It can
  13 be broken down as follows:
  14
  15         rx data
  16
  17 This indicates it's an RX packet, and it's rx packet type is "data".
  18
  19         fs call
  20
  21 This is a packet to the fileserver service (port 7000), and it's an RPC
  22 call (as opposed to a reply).
  23
  24         rename
  25
  26 This is the "name" of the call.  This happens to be the rename call.
  27
  28         old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc"
  29
  30 These are the arguments specific to the RPC call.  In this case, "fid"
  31 refers to the File Identifier (the unique handle used by AFS to refer
  32 to every file).  536876964/1/1 is the FID for the directory entry for
  33 my home directory.  ".newsrc.new" is the name of the old filename,
  34 ".newsrc" is the new name of the filename.
  35
  36 11:02:26.963769 pike.afsfs > elvis.7001: rx data fs reply rename (220) (DF)
  37
  38 The difference here is:
  39
  40         fs reply rename
  41
  42 which indicates it's a response to the previous RPC call that did a rename.
  43 The tcpdump module contains a cache of requests (by default, 64) to match
  44 up RPC calls to replies.  It's possible that in some cases the request will
  45 be too far seperated from the reply for the cache to match them up.
  46
  47 Some other examples:
  48
  49 13:52:29.743835 elvis.7001 > pike.afsfs: rx data fs call fetch-acl fid 536876964/1/1 (44) (DF)
  50 13:52:29.750686 pike.afsfs > elvis.7001: rx data fs reply fetch-acl +{system:anyuser rl} +{kenh rlidwka} -{heidi rlidwka} (184) (DF)
  51
  52 This is the result of doing "fs listacl" on my home directory.  You see that
  53 the request contains the FID of my home directory, and the response contains
  54 the ACL.  Entries with a + are positive ACL entries, and entries with a -
  55 are negative ACL entries.
  56
  57 More examples:
  58
  59 13:58:48.397489 elvis.47375 > riker.afsprot: rx data pt call name-to-id "tmc.admin" (292) (DF)
  60 13:58:48.399103 riker.afsprot > elvis.47375: rx challenge (44) (DF)
  61 13:58:48.399509 elvis.47375 > riker.afsprot: rx response (140) (DF)
  62 13:58:48.402905 riker.afsprot > elvis.47375: rx data pt reply name-to-id ids: -584 (36) (DF)
  63 13:58:48.403438 elvis.47375 > riker.afsprot: rx data pt call name-to-id "tmc.admin" (292) (DF)
  64 13:58:48.405381 riker.afsprot > elvis.47375: rx data pt reply name-to-id ids: -584 (36) (DF)
  65 13:58:48.405757 elvis.47375 > riker.afsprot: rx data pt call id-to-name ids: <none!> (36) (DF)
  66 13:58:48.407058 riker.afsprot > elvis.47375: rx data pt reply id-to-name <none!> (32) (DF)
  67 13:58:48.407418 elvis.47375 > riker.afsprot: rx data pt call list-elements id -584 (36) (DF)
  68 13:58:48.409696 riker.afsprot > elvis.47375: rx data pt reply list-elements 1025 1099 2317 4081 (52) (DF)
  69 13:58:48.410077 elvis.47375 > riker.afsprot: rx data pt call id-to-name ids: 1025 1099 2317 4081 (52) (DF)
  70 13:58:48.413009 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF)
  71 13:58:50.817930 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF)
  72 13:58:53.477978 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF)
  73
  74 Here is the result of running "pts members tmc.admin" on our cell.
  75
  76 The first line shows the initial PTS call to find out the ID of the tmc.admin
  77 group.  The next two lines shows the RX authentication step (challenge/
  78 response packets).  Then the same call is made again (why?  I don't know).
  79 Then the ID to name call is made with no ids in the ID list (again, I don't
  80 know why this happens).  Then the call is made to list all of the members
  81 of group -584.  When this list is obtained, the id-to-name call is used
  82 to convert the list of userids into usernames.  Note that at this point
  83 because the pts program exits, the ptserver process sends multiple responses
  84 to the last packet because the final ack has never been received from
  85 the client.
  86
  87 In general, nearly every AFS RPC is decoded in some form.  Some only
  88 have the call name, while others decode the arguments to the call (as
  89 seen above).  In general, you can expect most arguments to fileserver,
  90 pts, vldb, and ubik calls to be decoded.  There is limited decoding
  91 of callback, kauth, and bos calls, and currently there is no decoding
  92 of volserver calls.  I generally tried to decode arguments I thought
  93 were useful/interesting to humans, but I don't claim to be complete.
  94
  95 Here are some hints/tips to using this patch successfully:
  96
  97 - By default, tcpdump only grabs the first 68 bytes of the packet.  This
  98   isn't enough to parse the complete RX header, much less the RPC
  99   arguments.  It's recommended you specify a large snap size to tcpdump
 100   using the -s flag (I usually do at least 200, and sometimes 300).
 101   If you don't specify a snap size, you'll see the following displayed:
 102
 103 14:33:28.497655 elvis.7001 > picard.afsfs: [|rx] (44) (DF)
 104 14:33:28.499769 picard.afsfs > elvis.7001: [|rx] (148) (DF)
 105
 106   [|rx] means "truncated rx packet".  There are similar things printed
 107   for packets truncated during RPC call decoding ([|fs], [|prot], etc
 108   etc).  Note that due to (IMHO) stupid RPC encoding, some RPC calls
 109   are very large and will require large snap lengths to decode
 110   completely.
 111
 112 - You can use two -v options (-vv) to enable printing of more information
 113   inside the rx header, as shown below.
 114
 115 14:37:10.700438 elvis.7001 > picard.afsfs: rx data cid 467592a8 call# 3372 seq 1 ser 5043 <client-init>,<last-pckt> fs call fetch-status fid 536881810/66/52 (44) (DF) (ttl 255, id 30359)
 116 14:37:10.703651 picard.afsfs > elvis.7001: rx data cid 467592a8 call# 3372 seq 1 ser 5537 <last-pckt> fs reply fetch-status (148) (DF) (ttl 255, id 27089)
 117
 118   In this packet, "cid" indicates the call identifies (which can be viewed
 119   if you're careful with rxdebug), "call#" refers to the RPC call number,
 120   "seq" is the RX sequence number, and "ser" is the RX serial number.
 121   This is followed by a comma-separated list of RX flags enclosed in <>.
 122   The list of possible flags are:
 123
 124         client-init     Indication that this is an RPC call initiated by a
 125                         client.
 126         req-ack         An ack is requested for this packet.
 127         last-pckt       This is the last packet in this RPC call.
 128         more-pckts      There are more packets in this RPC call.
 129         free-pckt       Note sure what this means
 130
 131   If you want even _more_ detail, add another -v (-vvv) and you will get
 132   two additional fields output" The security index for the connection and
 133   the service id of the RPC call.
 134
 135 - If there is an error, a "rx abort" packet will be returned.  In this
 136   case, the error code will be printed from the abort packet (except
 137   in the case of a Ubik "beacon" message, because that's how Ubik
 138   yes votes are returned, so a more meaningful response is printed).
 139
 140 - Many of arguments to the RPC calls will not make sense without a good
 141   understanding of AFS internals.  "Use the Source, Luke!".
 142
 143 Improvements and fixes to this code are welcome.  Share and enjoy!
 144
 145 Ken Hornstein
 146 kenh@cmf.nrl.navy.mil
 147 10/15/99