| RX Patches for tcpdump 3.4 |
| |
| This directory contains a patch to tcpdump that decodes the information |
| inside of RX packets (the protocol used by AFS). Specifically, all of |
| the RX header information is decoded, and many of the arguments to the |
| AFS calls. |
| |
| Some examples: |
| |
| 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) |
| |
| This is a RX call from elvis (a client) to pike (a fileserver). It can |
| be broken down as follows: |
| |
| rx data |
| |
| This indicates it's an RX packet, and it's rx packet type is "data". |
| |
| fs call |
| |
| This is a packet to the fileserver service (port 7000), and it's an RPC |
| call (as opposed to a reply). |
| |
| rename |
| |
| This is the "name" of the call. This happens to be the rename call. |
| |
| old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" |
| |
| These are the arguments specific to the RPC call. In this case, "fid" |
| refers to the File Identifier (the unique handle used by AFS to refer |
| to every file). 536876964/1/1 is the FID for the directory entry for |
| my home directory. ".newsrc.new" is the name of the old filename, |
| ".newsrc" is the new name of the filename. |
| |
| 11:02:26.963769 pike.afsfs > elvis.7001: rx data fs reply rename (220) (DF) |
| |
| The difference here is: |
| |
| fs reply rename |
| |
| which indicates it's a response to the previous RPC call that did a rename. |
| The tcpdump module contains a cache of requests (by default, 64) to match |
| up RPC calls to replies. It's possible that in some cases the request will |
| be too far seperated from the reply for the cache to match them up. |
| |
| Some other examples: |
| |
| 13:52:29.743835 elvis.7001 > pike.afsfs: rx data fs call fetch-acl fid 536876964/1/1 (44) (DF) |
| 13:52:29.750686 pike.afsfs > elvis.7001: rx data fs reply fetch-acl +{system:anyuser rl} +{kenh rlidwka} -{heidi rlidwka} (184) (DF) |
| |
| This is the result of doing "fs listacl" on my home directory. You see that |
| the request contains the FID of my home directory, and the response contains |
| the ACL. Entries with a + are positive ACL entries, and entries with a - |
| are negative ACL entries. |
| |
| More examples: |
| |
| 13:58:48.397489 elvis.47375 > riker.afsprot: rx data pt call name-to-id "tmc.admin" (292) (DF) |
| 13:58:48.399103 riker.afsprot > elvis.47375: rx challenge (44) (DF) |
| 13:58:48.399509 elvis.47375 > riker.afsprot: rx response (140) (DF) |
| 13:58:48.402905 riker.afsprot > elvis.47375: rx data pt reply name-to-id ids: -584 (36) (DF) |
| 13:58:48.403438 elvis.47375 > riker.afsprot: rx data pt call name-to-id "tmc.admin" (292) (DF) |
| 13:58:48.405381 riker.afsprot > elvis.47375: rx data pt reply name-to-id ids: -584 (36) (DF) |
| 13:58:48.405757 elvis.47375 > riker.afsprot: rx data pt call id-to-name ids: <none!> (36) (DF) |
| 13:58:48.407058 riker.afsprot > elvis.47375: rx data pt reply id-to-name <none!> (32) (DF) |
| 13:58:48.407418 elvis.47375 > riker.afsprot: rx data pt call list-elements id -584 (36) (DF) |
| 13:58:48.409696 riker.afsprot > elvis.47375: rx data pt reply list-elements 1025 1099 2317 4081 (52) (DF) |
| 13:58:48.410077 elvis.47375 > riker.afsprot: rx data pt call id-to-name ids: 1025 1099 2317 4081 (52) (DF) |
| 13:58:48.413009 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF) |
| 13:58:50.817930 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF) |
| 13:58:53.477978 riker.afsprot > elvis.47375: rx data pt reply id-to-name "chas" "tripicia" "heidi" "kenh" (1056) (DF) |
| |
| Here is the result of running "pts members tmc.admin" on our cell. |
| |
| The first line shows the initial PTS call to find out the ID of the tmc.admin |
| group. The next two lines shows the RX authentication step (challenge/ |
| response packets). Then the same call is made again (why? I don't know). |
| Then the ID to name call is made with no ids in the ID list (again, I don't |
| know why this happens). Then the call is made to list all of the members |
| of group -584. When this list is obtained, the id-to-name call is used |
| to convert the list of userids into usernames. Note that at this point |
| because the pts program exits, the ptserver process sends multiple responses |
| to the last packet because the final ack has never been received from |
| the client. |
| |
| In general, nearly every AFS RPC is decoded in some form. Some only |
| have the call name, while others decode the arguments to the call (as |
| seen above). In general, you can expect most arguments to fileserver, |
| pts, vldb, and ubik calls to be decoded. There is limited decoding |
| of callback, kauth, and bos calls, and currently there is no decoding |
| of volserver calls. I generally tried to decode arguments I thought |
| were useful/interesting to humans, but I don't claim to be complete. |
| |
| Here are some hints/tips to using this patch successfully: |
| |
| - By default, tcpdump only grabs the first 68 bytes of the packet. This |
| isn't enough to parse the complete RX header, much less the RPC |
| arguments. It's recommended you specify a large snap size to tcpdump |
| using the -s flag (I usually do at least 200, and sometimes 300). |
| If you don't specify a snap size, you'll see the following displayed: |
| |
| 14:33:28.497655 elvis.7001 > picard.afsfs: [|rx] (44) (DF) |
| 14:33:28.499769 picard.afsfs > elvis.7001: [|rx] (148) (DF) |
| |
| [|rx] means "truncated rx packet". There are similar things printed |
| for packets truncated during RPC call decoding ([|fs], [|prot], etc |
| etc). Note that due to (IMHO) stupid RPC encoding, some RPC calls |
| are very large and will require large snap lengths to decode |
| completely. |
| |
| - You can use two -v options (-vv) to enable printing of more information |
| inside the rx header, as shown below. |
| |
| 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) |
| 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) |
| |
| In this packet, "cid" indicates the call identifies (which can be viewed |
| if you're careful with rxdebug), "call#" refers to the RPC call number, |
| "seq" is the RX sequence number, and "ser" is the RX serial number. |
| This is followed by a comma-separated list of RX flags enclosed in <>. |
| The list of possible flags are: |
| |
| client-init Indication that this is an RPC call initiated by a |
| client. |
| req-ack An ack is requested for this packet. |
| last-pckt This is the last packet in this RPC call. |
| more-pckts There are more packets in this RPC call. |
| free-pckt Note sure what this means |
| |
| If you want even _more_ detail, add another -v (-vvv) and you will get |
| two additional fields output" The security index for the connection and |
| the service id of the RPC call. |
| |
| - If there is an error, a "rx abort" packet will be returned. In this |
| case, the error code will be printed from the abort packet (except |
| in the case of a Ubik "beacon" message, because that's how Ubik |
| yes votes are returned, so a more meaningful response is printed). |
| |
| - Many of arguments to the RPC calls will not make sense without a good |
| understanding of AFS internals. "Use the Source, Luke!". |
| |
| Improvements and fixes to this code are welcome. Share and enjoy! |
| |
| Ken Hornstein |
| kenh@cmf.nrl.navy.mil |
| 10/15/99 |
