tcpdump

TCPDUMP(1)                   General Commands Manual                  TCPDUMP(1)



名前
       tcpdump - ネットワークのトラフィックをダンプする。

書式
       tcpdump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ]
               [ -i interface ] [ -r file ] [ -s snaplen ]
               [ -T type ] [ -w file ] [ expression ]

説明
       tcpdump は真偽値の 条件式 に一致するネットワークインターフェイス上のパケットのヘッダを表示する。

       nit か bpf を用いる SunOSの場合: tcpdump を動作させるためには /dev/nit かまたは /dev/bpf*
       にリード権限を持っている必要がある。 dlpi を利用する Solaris の場合: 仮想ネットワークデバイス、たとえば /dev/le
       といったものにリード権限を持っている必要がある。 dlpi を利用する HP-UX の場合: 実行者が root であるか、または root に
       setuid してインストールされている必要がある。 snoop を用いる IRIX の場合: 実行者が root であるか、または root に
       setuid してインストールされている必要がある。 Linux の場合: 実行者が root であるか、または root に setuid
       してインストールされている必要がある。 Ultrix および Digital UNIX の場合: まず、スーパーユーザが pfconfig(8)
       を用いて無差別透過モード(promicuous-mode)を有効にする必要がある。 その後は一般ユーザが tcpdump を実行可能である。
       BSD の場合: /dev/bpf* に対するリード権限が必要。

オプション
       -a     ネットワークとブロードキャストアドレスを DNS 名に変換する。

       -c     count 個のパケットを受信したのちに終了する。

       -d     コンパイルされたパケットマッチングコードを人間が読める形式で標準出力にダンプし、終了する。

       -dd    パケットマッチングコードを C 言語の一部として利用可能なかたちでダンプする。

       -ddd   パケットマッチングコードを 十進数でダンプする(count が先行する)。

       -e     各ダンプ行にリンクレベルヘッダを表示する。

       -f     「外部の」インターネットアドレスをシンボルではなくて数値で表示する(こ のオプションは馬鹿な Sun の yp
              サービスを迂回することを意図している — Sun の yp
              サービスはローカルではないインターネットアドレスを変換しようとすると永久に動作が停止してしまうバグがある)。

       -F     フィルター条件式の指示入力として file を用いる。これに追加してコ マンドラインで与えられた条件式による指示は無視する。

       -i     interface を監視する。指示のない場合は tcpdump
              はシステムのインターフェイスのリストから最も小さい番号で有効になっているもの(但し loopback
              は除く)を探し出す。指示されたインターフェイスが存在しない場合はもっとも近いものが選択される。

       -l     標準出力をバッファリングする。データを蓄積しながら監視する場合に有効で ある。使用例、
              ``tcpdump  -l  |  tee dat'' or ``tcpdump  -l   >
              dat  &  tail  -f  dat''.

       -n     アドレス(ホストアドレス、ポート番号など)を名前に変換しない。

       -N     ホストのドメイン名を表示しない。つまりこれを使用した場合 tcpdump は``nic.ddn.mil'' と表示するかわりに
              ``nic'' と表示する。

       -O     パケットマッチングコードオプティマイザを停止する。これはオプティマイザのバグを疑っている場合にのみ有益である。

       -p     無差別透過モードを 利用しない 。しかしながら、他の理由でインター
              フェイスが無差別透過モードになってしまうこともあることに注意せよ。この ため `-p' オプションは `ether host
              {loca-lw-addr} or ether broadcast' の省略形としては使用できない。

       -q     すばやい(というか静かな)出力。限定されたプロトコルの情報しか出力しないので、出力行は短いものとなる。

       -r     パケットを(-w オプションで作成した)fileから読み込む。file として ``-'' を指定した場合には標準入力が利用される。

       -s     デフォルトの 68 バイト(SunOS の NIT では最小は実際には 96 バイト)に代わって snaplen
              バイトをおのおののパケットから取り出し利用する。IP, ICMP ,TCP と UDP については 68
              バイトあれば十分だが、ネームサーバや NFS の情報には足りないかもしれない(後述)。

              snapshot 制限のために後ろが切り捨てられたパケットは出力時に``[|proto]'' の形式で示される 。ここで proto
              は切捨ての生じたレベルに対応するプロトコルの名前である。大きな snapshot
              を取ろうとすると、パケットを処理する時間は増加し、またこちらのほうが重要だが、バッファに溜めることができる量が減少してしまう点に注意すること。すなわちパケットが失なわれる可能性もある。プロトコルの情報が得られる必要最小限の
              snaplen とするように。

       -T     "expression"(条件式) で選択されたパケットに指示された type での翻訳を指示する。現在有効な type は rpc
              (Remote Procedure Call)、 rtp (Real-Time Applications protocol)、
              rtcp (Real-Time Applications control protocol)、 vat (Visual Audio
              Tool)、 wb (distributed White Board)。

       -S     TCP シーケンス番号を相対値ではなくて絶対値で表示する。

       -t     ダンプ行に時間情報を表示しない-tt    ダンプ行に表示する時間情報を整形しない。

       -v     (ちょっとだけ)詳細な出力。たとえば、IP パケットにおける 生存時間(TTL) や サービスの種類の情報を表示する。

       -vv    もっと詳細な出力。たとえば、NFS応答パケットにおける付加フィールドの表示。

       -w     パケットを解析、表示するかわりに生のまま file に書き出す。このファイルはあとで -r
              オプションを用いれば表示することができる。file として `-' を指示すると標準出力を用いる。

       -x     (リンクレベルヘッダを除く)すべてのパケットを十六進で表示する。パケット全体と snaplen バイトの小さい方だけを表示する。

        expression(条件式)
              ダンプするパケットの種類を選択する。expression
              が与えられないときは、ネットワーク上のすべてのパケットをダンプする。そうでなければ、expression が`true'(真)
              となるパケットだけをダンプする。

              expressionは一つ以上の primitives(要素) から成る。要素は一つ以上の修飾子を先行する一個の id
              (名前でも番号でもよい)である。修飾子には三つの種類がある:

              type   修飾子は id名または id 番号が指すものの種類を示す。利用可能なもの は host、 net、 port
                     である。例、`host foo'、`net 128.3'、`port 20'。 type 修飾子が無い場合は、
                     host が指示されているものとみなす。

              dir    修飾子は id に向けて、または id へ、のどちらかあるいは両方の通信方向を特定する。方向として指示できるのは
                     src、 dst、 src or dst 、 src and dst である。例、 `src foo'、`dst
                     net 128.3'、`src or dst port ftp-data'。 dir 修飾子が指定されない場合は
                     src or dst
                      が指示されいているものとみなす。`null' リンク層(すなわち slip のよう
                     なポイントツーポイントプロトコル)においては、方向を指定する修飾子とし て inbound outbound
                     も利用可能である。

              proto  修飾子は一致する特定のプロトコルに制限する。利用可能なプロトコルは以下の通り: ether、 fddi、 ip、
                     arp、 rarp、 decnet、 lat、 sca、 moprc、 mopdl、 tcp、 udp。
                     例、`ether src foor'、`arp net 128.3'、`tcp port 21'。 proto
                     修飾子が指示されない場合は type と矛盾しない範囲で全てのプロトコ ルが指示されているものとみなす。 例、`src
                     foo' は `(ip or arp or rarp) src foo' (このような書き方は文法あやまりだが)
                     を意味し、`net bar' は `(ip or arp or rarp) net bar' を意味し、また
                     `port 53' は `(tcp or udp) port 53' を意味する。

              [`fddi'は実際には `ether' の別名である;解析時に``特定のネットワー
              クインターフェイスが利用するデータリンク層''として扱われる。FDDI ヘッ
              ダーはイーサネット的なソースおよびディスティネーションアドレスを含み、ま たイーサネット的なパケットタイプも含むので、これらの
              FDDI フィールドを イーサネットの同類として選別できる。FDDI ヘッダにはその他のフィールド
              も含まれるが、これについてはフィルタの条件式で明示的に指示することはで きない。]

              上記に加えて、特別な`要素'を示すキーワードがある: gateway、 broadcast、 less、 greater
              とarithmtic expression(数値による条件式) 。これらについてはこのあとで記述する。

              もっと複雑なフィルタ条件式は and、 or、 not と各要素の組合せで表現できる。例、`host foo and not
              port ftp and not port ftp-data'。明示的な修飾子は省略してタイプ数を減らすことができる。例、`tcp
              dst port ftp or ftp-data or domain' は`tcp dst prot ftp or tcp dst
              port ftp-data or tcp dst prot domain'と全く同じ意味である。

              許容される要素の組み合わせは;

              dst host host
                     パケットの IP ディスティネーションフィールドが host であるとき真。アドレスでも名前でもよい

              src host host
                     パケットの IP ソースフィールドが host であるとき真。

              host host
                     パケットの IP ソースまたは IP ディスティネーションフィールドが host であるとき真。上記の各 host
                     を差す条件式には iparp、または rarp を付加してもよい。
                          ip host host
                     は下記と同等
                          ether proto \ip and host host
                     もし host の名前が複数の IP アドレスを持つ時はそれぞれのアドレスに一致する。

              ether dst ehost
                     イーサネットディスティネーションアドレスが ehost であるときに真。 ehost は /etc/ethers
                     か数値である(数値のフォーマットについては ethers(3N) を参照のこと)。

              ether src ehost
                     イーサネットソースアドレスが ehost であるときに真。

              ether host ehost
                     イーサネットソースアドレスかディスティネーションアドレスが ehost であるときに真。

              gateway host
                     パケットが host をゲートウェイとしているときに真。すなわち、イーサネットソース/ディスティネーションアドレスは
                     host であるが、IP ソース/ディスティネーションアドレスは host ではないときのこと。host
                     は名前であり、また /etc/hosts と /etc/ethers の両方に記載されていなければならない(こ
                     の条件式は host / ehost それぞれを名前か番号で記述する
                          ether host ehost and not host host
                     と同等である)。

              dst net net
                     パケットの IP ディスティネーションアドレスが net ネットワークを 含んでいるときに真。net
                     は/etc/networks に記載される名前かネット ワーク番号である( networks(4) を参照)。

              src net net
                     パケットの IP ソースアドレスが net ネットワークのものであるときに真。

              net net
                     パケットの IP ソース/ディスティネーションアドレスが net ネットワークであるときに真。

              net net mask mask
                     IP アドレスが netmask でマスクして net に一致するときに真。src dst で修飾してもよい。

              net net/len
                     IP アドレスが len ビットのnetmask でマスクして net に一致するときに真。src dst
                     で修飾してもよい。

              dst port port
                     パケットが ip/tcp か ip/udp である場合で、行き先の port 番号が port
                     であるときに真。Port は番号の数値か /etc/services による名前を利用できる( tcp(4P) udp(4P) を参照のこと)。名前が利用されている場合は port 番号と protocol
                     の両方で照合される。番号か多重に定義されている名前が利用されている場合は port 番号だけが照合される(例) dst
                     port  513 は tcp/login と udp/who の両方の通信を表示するし、port domain は
                     tcp/domain と udp/domain の両方を表示する。

              src port port
                     パケットが port 番号の port をソースにしているとき真

              port port
                     パケットのソースかディスティネーションが port であるとき真。この port を指定する条件式は tcp udp のキーワードを付加してもよい:
                          tcp src port portport をソースとする tcp のパケットのみに一致する。

              less length
                     パケットが length 以下のときに真。 これは下記と同じ:
                          len <= length.

              greater length
                     パケットが length 以上のときに真。 これは下記と同じ:
                          len >= length.

              ip proto protocol
                     パケットが protocol 型の IP パケット( ip(4P) を参照)のプロトコルのもので
                     あるとき真。protocol として利用できるのは数値と icmpigrpudpndtcp
                     である。tcpudpicmp はキーワードでもあるので、バックスラッシュ(\)でキーワード
                     として解釈されるのを回避する必要がある。C-Chell では \\ を使う。

              ether broadcast
                     パケットがイーサネットのブロードキャストであるとき真。ether はなくてもよい。

              ip broadcast
                     パケットが IP ブロードキャストパケットであるとき真。これは全て 0 と 全て 1
                     の両方のブロードキャスト形式に対応し、さらにサブネットマスクにも対応している。

              ether multicast
                     パケットがイーサネットのマルチキャストであるとき真。ether はなくて もよい。これは `ether[0] & 1
                     != 0'の省略記法である。

              ip multicast
                     パケットが IP のマルチキャストであるとき真。

              ether proto protocol
                     パケットが ether の protocol 型のものであるとき真。 protocol には番号か
                     iparprarp の名前が利 用可能。これらの識別子はキーワードでもあるので、バックスラッシュ(\)で
                     キーワードとして解釈されるのを回避する必要がある。 [ FDDI (たとえば `fddi protocol
                     arp')の場合、プロトコルの識別方法は 802.2 Logical Link Control (LLC)
                     ヘッダーによる。それは通常は FDDI ヘッダーの先頭に置かれている。tcpdump は プロトコル識別子で
                     フィルターする場合に、全ての FDDI パケットは LLC ヘッダーを持っていて、 その LLC ヘッダーは SNAP
                     と呼ばれる形式になっているものとみなす。 ]

              decnet src host
                     DECNET においてソースアドレスが``10.123''のようなアドレスや DECNETのホ
                     ストネームの形式で指示される host と一致するとき真。[DECNETのホストネーム形式は DECNETに接続された
                     ultrix システムにおいてのみ利用可能である。]

              decnet dst host
                     DECNETにおいてディスティネーションアドレスが host に一致するとき真。

              decnet host host
                     DECNETにおいて、ソースまたはディスティネーションアドレスが host に一致するときに真。

              ip, arp, rarp, decnet
                     下記において:
                          ether proto p
                     p をそのいずれかのプロトコルとするのと同等である。

              lat, moprc, mopdl
                     下記において:
                          ether proto p
                     p をそのいずれかのプロトコルとするのと同等である。 tcpdump
                     はこれらのプロトコルの解析方法は正確には知らない点に注意 すること。

              tcp, udp, icmp
                     下記において:
                          ip proto p
                     p をそのいずれかのプロトコルとするのと同等である。

              expr relop expr
                     関係式が成り立てば真。relop(演算子)は >、<、>=、<=、=、!= のいず れか一つであり、expr(表現)
                     は整定数による数値表現 (表現方法は標準 的な C
                     の文法にしたがう)、標準的な二項演算子[+、-、*、/、&、|]、長さ演算子、パ
                     ケットデータアクセス演算子のいずれか。パケット内のデータに対して適用するにはこのように記述する:
                          proto [ expr : size ]
                     proto ether、fddi、ip、arp、rarp、tcp、udpicmp
                     のいずれかで操作対象のプトロコル層を指示する。指示されたプ ロトコル層についてのバイトオフセットは expr
                     で指定する。 size を指示する場合は注目するフィールドでのバイト数で指示するが、 それは one、two また
                     four のいずれかを用いる。指示のない場合は one で あるとみなす。長さ演算子はキーワード len
                     で示され、パケット長を与える。 たとえば、`ether[0] & 1 != 0'という条件式はすべてのマルチキャスト
                     による通信をとらえる。`ip[0] & 0xf != 5' という条件式はすべてのオ プション付きの IP
                     パケットをとらえる。`ip[6:2] & 0x1fff = 0'はフラ グメント化されていないデータグラムか 0
                     番の(最初の)フラグメントだけを表示する。 なお、この条件は tcp udp への適用を暗示している。さら に
                     tcp[0] は TCP ヘッダ の最初のバイトを意味するが、フラ グメントの先頭のバイトではありえない。

              要素を複合させて用いる場合:

                     括弧でグループ分けする要素と演算子(括弧はシェルにとっても特別な意味を持つのでたぶんエスケープしなければならないだろう)。

                     否定 (`!' or `not').

                     結合 (`&&' or `and').

                     択一 (`||' or `or').

              否定はもっとも高い優先度をもつ。択一と結合は同等の優先度をもちまた左から 右へ評価される。 結合は併記するだけでなく明示的な and
              トークンが必要なことに注意すること。

              キーワードなしで識別子があらわれた場合、直前にあらわれたキーワードを共 なっているとみなされる。 たとえば、
                   not host vs and acenot host vs and host ace
              の省略であり、これは
                   not ( host vs or ace )
              とは違う。

              tcpdump
              に渡す条件式は都合のよいように、単一としても複数としてもよい。一般にシェルのメタキャラクタを含むような条件式の場合は単一のクオートした引数として渡すのがよい。複数の引数は評価の直前に空白で結合される。


       ホスト sundown にかかわる全ての入出力パケットを表示する:
              tcpdump host sundown

       ホスト helios hot あるいは ace との通信を表示する:
              tcpdump host helios and \( hot or ace \)

       ホスト ace helios を除く全てのホストとのIPパケットを表示する:
              tcpdump ip host ace and not helios

       ローカルネットのホスト群とネットワーク Berkeley のホスト群との通信を表示する:
              tcpdump net ucb-ether

       インターネットへのゲートウェイの snup を通過する全ての ftp
       通信を表示する(条件式はシェルが括弧を(誤って)解釈するのを避けるためにクオートされている点に注意せよ):
              tcpdump 'gateway snup and (port ftp or ftp-data)'

       ローカルホストへの入出力の通信を除外して表示する(他のネットワークへのゲートウェイであるとして、ローカルネットワークを除外する例):
              tcpdump ip and not net localnet

       ローカルホスト以外が関わる TCP 通信の TCP スタートとエンドのパケット(SYN と FIN のパケット)を表示する:
              tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'

       ゲートウェイ snup を通過する 576 バイト以上の IP パケットを表示 する:
              tcpdump 'gateway snup and ip[2:2] > 576'

       イーサネットのブロードキャストまたはマルチキャストを 必要としない IP のブロードキャストまたはマルチキャストを表示する:
              tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

       echo 要求/応答(つまり ping のパケット)以外のすべての ICMP パケットを表示する:
              tcpdump 'icmp[0] != 8 and icmp[0] != 0"

出力形式
       tcpdump の出力はプロトコルに依存する。下記は大部分の様式の簡単な解説と例である。

       リンクレベルヘッダ

       `-e' オプションが指示されている場合、リンクレベルヘッダが表示される。
       イーサネットではソースおよびディスティネーションのアドレスとパケット長が表示される。

       FDDI のネットワークにおいては '-e' オプションにより tcpdump は、ソ
       ースおよびディスティネーションのアドレスとパケット長からなるフレーム制御フィールドを表示する。(フレーム制御フィールドはパケットの残りの部分の解釈
       の制御をおこなう)。(IP データグラムを含むような)通常のパケットは優先度 0 から 7 を持つ`async' パケットである;たとえば
       `async 4'。この ようなパケットは 802.2 LLC を含むとみなされる。LLCヘッダはそれが ISO データグラムやいわゆる SNAP
       パケット でない ならば、表示される。

       (注:以下の記述は RFC-1144 による SLIP 圧縮アルゴリズムを理解しているものと みなして記述してある)。

       SLIP 接続では、方向指示(``I''が入力、``O''が出力)、パケットタイプと圧縮情報が表示される。 最初にパケットタイプが表示される。
       タイプには iputcpctcp の三種類がある。 ip パケットについてこれ以上のリンク情報は表示されない。
       TCPパケットは接続識別子が次に表示される。 パケットが圧縮されている場合はその符号化されたヘッダが表示される。 *S+n*SA+n
       と表示される特別な状態もある。ここで n はシーケンス番号(またはシーケンス番号と ack)が何回変更されたかを示す。
       特別な場合でなければ、ゼロかまたは変更の回数が出力される。 変更は U(urgent
       pointer)、W(windows)、A(ack)、S(sequence number)、I(packet ID)に差分(+n か
       -n)または新しい値(=n)の組合せで示される。 最後にパケットのデータすべてと圧縮されたヘッダの長さが表示される。

       この例は明示された接続識別子をもつ出力される圧縮TCPパケットを示す。 ack は 6回更新され、シーケンス番号は 49であり パケットの IDは
       6である; 3バイトのデータと6バイトの圧縮ヘッダを持つ
              O ctcp * A+6 S+49 I+6 3 (6)

       ARP/RARP パケット

       arp/rarp 出力は要求のタイプとその引数を表示する。フォーマットそれ自体 が自身の内容の説明となる。この短い例はホスト rtsg から
       csam への `rlogin' の開始時のものである。
              arp who-has csam tell rtsg
              arp reply csam is-at CSAM
       一行目は rtsg が インターネットホスト csam のイーサネットアドレスを尋ねる arp パケットを送信した様子。csam
       はイーサネットアドレスを返信している(この例でイーサネットアドレスは大文字で、インターネットアドレスは小文字で表示されている)。

       この例は tcpdump -n で実行するとこのように簡略化される:
              arp who-has 128.3.254.6 tell 128.3.254.68
              arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

       Tcpdump -e で実行すると最初のパケットがブロードキャストで二番目は point-to-point であることが見てとれる:
              RTSG Broadcast 0806  64: arp who-has csam tell rtsg
              CSAM RTSG 0806  64: arp reply csam is-at CSAM
       最初のパケットは source のイーサネットアドレスが RTSG
       で、ディスティネーションがイーサネットのブロードキャストであり、タイプフィールドは十六進の 0806(ETHER_ARP)、全長が 64
       バイトであることがわかる。

       TCP パケット

       (注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものと
       みなして記述してある。もしこのプロトコルに通じていないようなら、この記 述だけでなく、tcpdump そのものもやくにたたないだろうが。)

       一般的なフォーマットは下記の通り:
              src > dst: flags data-seqno ack window urgent options
       src dst は ソースとディスティネーションとなる IPアドレ スとポート番号である。flags は
       S(SYN)、F(FIN)、P(PUSH)か R(RST) の組合せか一つの `.'(フラグなし)である。data-seqno
       はこのパケットに含まれるデータのシーケンス空間の一部を示す(下記の例を参照)。ack はこの接続における次の期待される
       応答データのシーケンス番号。window はこの接続における応答に対して用意されているバッファ空間のバイト数。urg はこのパケットに
       `urgent' データが含まれることを示す。options は tcp のオプションで <>で囲まれる(例<mss 1024>)。

       src、dst flags はかならず表示される。他のフィールドはパケットの TCP プロトコルヘッダに依存するので必要な場合のみ表示される。

       これはホスト rtsg から csam へのrlogin の開始時の一部。
              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
       一行目は rtsg の tcp port 番号 1023 から csam の login ポートへ の送信パケットの表示である。S SYN
       フラグがセットされているこ とを示す。パケットのシーケンス番号は 768512 でこのパケットはデータを 含まない。(このように nbytes
       バイトのユーザデータを含むシーケ ンス番号 first から、last (last は含まれない)を示すために
       `first:last(nbytes)'と表記する)。またこのパケットには ack は設定されて おらず、受信 window は 4096
       バイト、最大セグメントサイズ(mss)オプショ ン が 1024 バイトに設定されていた。

       これに対して、csam は rtsg の SYN に対する ack を含む他は同等の内容のパケットを返している。そこで、rtsg は csam の
       SYN に ack 応答を返す。 `.'
       はフラグがセットされていないことを示す。このパケットにはデータが含まれないので、シーケンス番号もない。ack 応答のシーケンス番号は小さな整数 1
       である点に注意すること。 最初に tcp の「会話」を見いだすと、tcpdump はそのパケットのシー
       ケンス番号を出力する。その会話のパケットからは、そのシーケンス番号と 初期化されたシーケンス番号との差異が表示される。
       これは最初以外のシーケンス番号はその会話のデータグラムにおける相対的な バイト位置として解釈できることを意味する (各データグラムは 1 から始ま
       る)。 '-S' オプションはこの機能を無視して、本来のシーケンス番号を出力する。

       6 行目で rtsg は scam へ 19 バイト(rtsg から csam の方向へ、2 バイト目 から 20 バイト目まで)
       のデータを送る。このパケットには PUSH フラグが設定されている。7 行目で、 csam は rtsg
       が送信したデータを受信した、と言っているが、これには 21 バイト目は含まれない。csam の受信 window が 19
       バイト小さくなっていることか ら、このデータはソケットバッファに留まっていると推測される。csam はま た 1バイトのデータを rtsg
       に送信する。8 行目と 9 行目とで csam は urgent および pushed 付きのパケット 2バイト をrtsg へ送信している。

       もし、snapshot が小さすぎて tcpdump が TCP ヘッダの全てを捉えられなかった場合は、できるだけ
       の解釈をして、その残りには解釈不能だったものがあることを示すために ``[|tcp]''と表示する。ヘッダに意味不明なオプション(たとえば、小
       さすぎたり、ヘッダよりも長かったりする length とか)が設定されていた場 合は、tcpdump は ``[bad
       opt]''と表示し、それ以上のオプション解析 を中止する(それがどこから始められるかわからないので)。ヘッダ長がオプショ
       ンを送信したことを示しているのに、IP データグラム長はそこにオプションを含められないことを示す場合は tcpdump は ``[bad hdr
       length]''と表示する。

       UDP パケット

       UDP はこの rwho のパケットで説明する:
              actinide.who > broadcast.who: udp 84
       これはホスト actinide who のポートから udp データグラム がホスト broadcast
       すなわちインターネットブロードキャストアドレ スの who のポートへ送られたことを表示している。パケットはユーザデータ 84
       バイトを含んでいる。

       いくつのかの UDP サービスに関しては(そのソースまたはディスネーション のポート番号より)解釈することができ、より上位の層におけるプロトコル
       情報を表示する。特にドメインネームサービス要求(RFC-1034/1035)や NFS についての Sun RPC
       (RFC-1050)について出力される。

       UDP ネームサービス要求

       (注:以下は RFC-1035 で記述される ドメインネームサービスプロトコルを
       理解しているものとみなして記述している。もしこのプロトコルに通じていないようなら、以下の記述はちんぷんかんぷんかもしれない。)

       ネームサーバの要求は、
              src > dst: id op? flags qtype qclass name (len)
              h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
              のような形式である。
       ホスト h2opolo helios のドメインネームサーバに対して、ucb-bax.berkeley.edu.
       という名前についてのアドレスレコード(qtype=A)を尋ねる。問い合せの id は `3'。`+'は再帰可能(recursion
       desired)フラグが設定されていることを示す。 問い合わせは UDP と IP のヘッダは含まめずに 37バイトある。問合せは標準的な
       Query なので op フィールドは省略されている。もし、op フィールド を持つなら、それがなんであれ、`3' と `+'
       の間に表示する。また同様に、 問合せクラス(qclass)も標準的な C_IN なので、省略されている。ほかの問合せクラ スの場合は `A'
       に続いて表示する。

       例外的なものを検出した場合、追加のフィールドを[ ] で囲んで表示するだろ
       う:もし問合せ(query)に回答、ネームサーバ、権威セクションが含まれる場合、 ancount, nscount, arcount はそれぞれn
       をカウント数として、 `[na]'、`[nn]' か `[nau]' のように表示される。
       もし、第二および第三バイトにいくつかの応答bitが設定されている(AA、RAか または rcode)場合か、`must be zero'
       ビットが設定されている場合は `[b2&3=x]'と表示する。ここで x はヘッダの第二および第三バイトの十六進表現である。

       UDP ネームサーバ応答

       ネームサーバからの応答は、
              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)
              のような形式である。
       最初の例では、helios h2opolo の id 3 の要求に三個の回答
       レコード、三個のネームサーバレコードと七個の権威レコードを返答している。 最初の回答は A レコードで、このデータはインターネットアドレスの
       128.32.137.3 である。 応答のサイズは UDP と IP のヘッダは含まずに 273 バイトである。 (queryの) op と
       response code(この場合は NoError)は、A レコードのクラ ス(C_IN)と同様に省略されている。

       次の例は helios はドメインが存在しない、という response code (NXDomain)
       で回答はなし、ネームサーバは一個、権威レコードもなし、という返答をしている。 `*' は authoritative answer
       ビットが設定されていることを示す。 回答がないので、 type とクラスおよびデータは表示されない。

       ほかのフラグは`-'(RA(再帰可)が設定されていない)、`|'TC(まるめら れたメッセージ)が設定されている。`question'
       セクションが一つでない場合 には、`[nq]'と出力する。

       ネームサーバの応答はデフォルトの snaplen である 68バイトよりも大
       きくなりがちなので、そのパケットを表示するのに十分なだけの情報を捉えき れないことがある。 ネームサービスの通信を厳密に解析したいときは、-s
       フラグを利用して、snaplen を拡張するべきである。`-s 128'くらいが妥当であろう。


       NFS 要求と回答

       Sun NFS(Network File System)の要求と応答は次のように出力される:
              src.xid > dst.nfs: len op args
              src.nfs > dst.xid: reply stat len op results
              sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
              wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
              sushi.201b > wrl.nfs:
                   144 lookup fh 9,74/4096.6878 "xcolors"
              wrl.nfs > sushi.201b:
                   reply ok 128 lookup fh 9,74/4134.3150
       一行目はホスト sushi が id 6709 でトランザクション要求を wrl に送信している (src ホストに続く数字は port 番号
       ではなくて トランザクション id である点に注意せよ)。 要求は UDP と IP のヘッダを除いて 112
       バイトである。動作要求はファイルハンドル(fh) 21,24/10.731657119 に対する readlink
       (シンボリックリンクの値を読む)である。 (この例では、幸運なことに、デバイスの major および minor 番号の対と inode
       番号、generation 番号がファイルハンドルから抽出できている) Wrl はリンクの内容と `ok' を返答している。

       三行目では sushi wrl に対し ディレクトリファイル 9,74/4096.8678 から `xcolors'
       を探し出すように要求している。出力されるデータは操作の 種類によって依存していることに注意せよ。この出力形式は NFS プロトコル
       仕様とともに読んだ場合に自己説明になるよう意図された形式である。

       -v(verbose) フラグが与えられている場合、追加の情報も出力される。例:
              sushi.1372a > wrl.nfs:
                   148 read fh 21,11/12.195 8192 bytes @ 24576
              wrl.nfs > sushi.1372a:
                   reply ok 1472 read REG 100664 ids 417/0 sz 29388
       (-v は IP ヘッダの TTL と ID、フラグメンテーションフィールドも表示する が、この例では省略している)。一行目では、sushi wrl に対して、 file 21,11/12.195 のバイトオフセット 24576 から 8192 バイト読み出し要求を出 している。Wrl
       は `ok' を返している; 二行目に表示されているこのパ ケットはフラグメント化された返答の一番目のパケットであるため、1472 バ
       イトのみである(残りのバイトはその後のフラグメントとして続くが、それら のフラグメントは NFS ヘッダも UDP
       ヘッダも持たないので、フィルタ条件式の指定次第で表示されないことがある)。 また -v
       フラグがあたえられていることにより、いくつかのファイルの属性 も表示される(ファイルデータに付加して返答される): ファイルのタイプ
       (``REG'' は普通のファイル)、ファイルのモード(八進で)、uid と gid、またファイルのサイズなど。

       -v フラグが複数与えられると(-vvのこと)もっと詳細な情報が出力される。

       NFS の要求はとても大きいので、snaplen を増加しないと十分な情報が表示で きないかもしれないことに注意せよ。NFS
       の通信を監視する場合は `-s 192' を試してみるとよい。

       NFSの返答パケットは RPC操作によって識別することができない。しかしなが ら、tcpdump は
       ``最近の''要求を覚えておいて、返答がそのトランザ クション
       IDに一致するか調べる。応答が対応する要求の近くに通信されていない場合はきちんと解析できないかもしれない。

       KIP アップルトーク (UDP 内 DDP)

       UDP データグラム内に格納されたアップルトークの DDP パケットは取り出されて、DDP パケットとして表示される(すなわちすべての UDP
       ヘッダ情報は捨てられる)。 /etc/atalk.names ファイルが
       アップルトークネットとノード番号を名前に変換するのに利用される。ファイルの形式は下記の通り、
              番号        名前

              1.254     ether
              16.1      icsd-net
              1.254.110 ace
       最初の二行はアップルトークネットワークに名前を与える。三行目は特定のホストの名前を与える(ホストはネットワーク番号の第三オクテットで識別される -
       ネットワーク番号は二オクテットで なければならず、またホスト番 号は三オクテットで なければならない。番号と名前は空白文字で区切られる(blank
       か tab)。 /etc/atalk.names ファイルは空行とコメント行(`#'で始まる行)を含んでもよい。

       アップルトークのアドレスは次の形式で表示される
              net.host.port

              144.1.209.2 > icsd-net.112.220
              office.2 > icsd-net.112.220
              jssmag.149.235 > icsd-net.2
       ( /etc/atalk.names
       がない場合またはそれに適切なアップルトークのネット番号、ホスト番号が含まれない場合は、アドレスは数字で表示される)。 最初の例は ネットワーク
       144.1 のノード 209 の NBP(DDP のポート番号 2 )からネットワーク icsd のノード 112 ポート番号220
       番への送信を示す。 二番目も同様だが、ノード名(`office') がわかっている場合の例。 三行目はネットワーク jssmag のノード 149
       の 235 番ポートから icsd-net の NBPポートへのブロードキャストを示す。
       ブロードキャストアドレス(255)はホスト番号を伴わないネットワーク名だけの出 力で識別できることに注意すること -
       /etc/atalk.names にノード名とネッ トワーク名を記述しておくのはよい考えである)。

       NBP(名前解決プロトコル)と
       ATP(アップルトークトランザクションプロトコル)パケットについては、その内容も解析される、その他のプロトコルはプロトコル名(または、名前がわからなければ、番号)とパケットのサイズが表示されるだけである

       NBP パケット は次の例のように表示される:
              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
       一行目はネットワーク icsd の ホスト 112 から ネットワークjssmag
       へブロードキャストされるレーザライタを探す要求送信である。nbp の id は 190 。 二行目はその要求へのホスト jssmag.209
       からの応答(id 番号が同じであることに注意)で、``RM1140''という名前のレーザライタを 250 番ポートに持っていることを答えている。
       三行目は同じ要求に対する別の返答でホスト techpit が186番ポートに "tecpit" が登録されていることを答えている。

       ATP パケット は次のように表示される:
              jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
              helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
              jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
              helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
              helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
              jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
              jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
       jssmga.209 はホスト helios に対してで id 12266 でトランザクションを開始し最大
       8パケット(`<0-7>'と示す)を要求す る。行末の十六進数字は要求に含まれる `userdata'のフィールドである。

       helios は八個の 512 バイトのパケットを返答している。トランザクションid に続く `:数字'
       表現はトランザクションにおけるパケットのシーケンス番号で、カッコに囲まれた数字は atp ヘッダを除いたパケットのデータ量である。パケット 7
       番の `*' は EOM ビットが設定されていることを示す。

       jssmag.209 はパケット 3 番とパケット 5 番の再送を要求している。helios はそれらを再送し、jssmag
       はトランザクションを終了する。そして、 jssmag.209 は次の要求を開始する。要求の `*' は XO (`一回だけ')は設定 されていない
       ことを示す。


       IP フラグメント化(fragmentation)

       インターネットデータグラムのフラグメント化されたものは次のように表示す る
              (frag id:size@offset+)
              (frag id:size@offset)
       (最初の形式はまだ続くフラグメントがあることを示し、二番目の形式はそ れが最後のフラグメントであることを示す)

       id はフラグメントの id 。size はフラグメントの IP ヘッダを除くサイズ(バイトで)。offset
       はフラグメントのもともとのデータグラム内でのオフセット(バイトで)。

       フラグメントの情報はフラグメント毎に表示される。最初のフラグメントには 上位プロトコルのヘッダを含み、フラグメント情報はプロトコル情報に続いて
       表示される。二番目以降のフラグメントには上位プロトコルの情報を含まない ので、フラグメント情報はソースおよびディスティネーションアドレスにつづ
       いて表示される。以下の例は CSNET で接続された arizona.edu から lbl-rtsg.arpa へ の ftp
       接続の一部を示すが、これには 576バイトのデータグラムはあらわれていない:
              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
       二つの注意点がある: 一つ目として、二行目で示されるアドレスにはポート 番号は含まれていない点に注意せよ。これは TCP
       プロトコルの情報は最初のフラグメント に含まれるため、残りのフラグメントからは表示すべきポート番号やシーケン
       ス番号がわからないためである。二つ目は、一行目の TCP のシーケンス情報 には実際には 512 バイト(最初のフラグメントで 308
       バイト、二番目のフラ グメントで204 バイトの場合)のユーザデータが 308 バイトであるかのように
       表示されている点である。シーケンスの漏れやパケットの ack の対応を調査 するとき、ここに悩まされることがあるかもしれない。

       フラグメント化禁止フラグ の設定されたパケットの場合、行末に (DF)と表示する。

       時間表示

       デフォルトでは全ての出力行にはタイムスタンプが先行する。タイムスタンプは現在の時刻を次の形式で表示し、
              hh:mm:ss.frac
       これは、kernel の時間情報同様に正確である。タイムスタンプは kernel が
       パケットを確認した時点の時刻を反映している。イーサネットインターフェイス が回線からパケットを取得した時点からカーネルが `新しいパケット'
       による 割り込みを受ける時点までの時間差は反映されていない。

関連項目
       traffic(1C), nit(4P), bpf(4), pcap(3)

著者
       Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence
       Berkeley National Laboratory, University of California, Berkeley, CA.

       最新版は下記の ftp から取得可能である:

              ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

バグ
       バグがあったら報告を tcpdump@ee.lbl.gov まで送ってほしい。

       NIT は外へ出ていく通信は見ることができない。BPF はそれが可能である。後者の利用を推奨する。

       用途によっては、IPフラグメントを再構築したり、上位プロトコルの長さを計算するくらいのことは必要となるだろう。

       ネームサーバの逆引き要求は正確に表示できない。(空の)質問はむしろ回答の 中に含まれる要求として表示される。逆引き要求にはバグがふくまれていて、
       それを修正するのは tcpdump ではなくてネームサービスの方であるべきと考 えている人もいる。

       アップルの EtherTalk の DDP パケットは KIP DDP パケットのように容易に dump できるはずだが、行なわない。たとえ
       ethertalk を扱おうという気になっ ても(なってないが)、LBLが ネットワーク上のethertalk へのアクセスを許さ
       ないので、コードのテストができないのだ。

       夏時間にきりかわるときにパケットトレースを行なっていると時間がずれてし まう(時間の変更は無視される)。

       FDDI ヘッダに対するフィルタの条件式はすべての FDDI パケットがイーサネット
       のパケットをカプセル化しているものとみなして適用される。これは、IP,ARP と DECNET PhaseIV については正しく動作するが、ISO
       CLNS
       のようなプロトコルではうまくいかないだろう。それゆえにフィルターは条件式に一致しないようなパケットをあやまってあつかってしまうかもしれない。



                                  30 June 1997                        TCPDUMP(1)