TCPDUMP(1)

名称
tcpdump - ネットワーク上のトラフィックデータをダンプする

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

解説

tcpdump は、1 つのネットワークインタフェースで捕捉されたパケットのうち expression にマッチするもののヘッダ部分を出力します。

SunOS 上で nit または bpf とともに使う場合、 tcpdump を実行するには、 /dev/nit または /dev/bpf* への読み込みアクセス権が必要です。 Solaris 上で dlpi とともに使う場合、 /dev/le などのネットワーク仮想デバイスへの読み込みアクセス権が必要です。 HP-UX 上で dlpi とともに使う場合、 root になるか、tcpdump が root に setuid されてインストールされていなければ なりません。 IRIX 上で snoop とともに使う場合、 root になるか、tcpdump が root に setuid されてインストールされていなければ なりません。 Linux の場合、 root になるか、tcpdump が root に setuid されてインストールされていなければ なりません。 Ultrix や Digital UNIX の場合、 いったんスーパユーザが、 pfconfig(8) を用いて promiscuous-mode オペレーションを許可すれば、どのユーザも tcpdump を起動できます。 BSD の場合、 /dev/bpf* への読み込みアクセス権が必要です。

オプション

-a  ネットワークアドレスやブロードキャストアドレスの名前への変換を試みます。

-c  count で指定した数のパケットを受信した後に終了します。

-d  コンパイルされたパケットマッチングコードを、人間が読みやすい形に 整形した後、標準出力にダンプして停止します。

-dd C プログラムの断片の形でパケットマッチングコードをダンプします。

-ddd
    (先頭に個数を付加した) 10 進数の形でパケットマッチングコードをダンプします。

-e  各ダンプ行ごとに、リンクレベルのヘッダを出力します。

-f  外部ホストの IP アドレスについては、シンボルでなく数値で表示します (このオプションは、Sun の yp サーバに重大な障害が発生するのを回避する ために使うことをことを想定しています。通常は、Sun の yp サーバは、 ローカルに存在しない IP アドレスを永久に変換しつづけてハングします)。

-F  フィルタの式として、file に記述してある内容を用います。 コマンドラインで式を追加しても、無視されます。

-i  interface を監視します。 指定されない場合には、tcpdump はシステムのインタフェースリスト内の 稼働中のインタフェースのうちで最も小さい番号のものを検索し、 監視するインタフェースとして設定します (この場合、ループバックインタフェースは 検索されるインタフェースには入りません)。 この動作は、最初にインタフェースが選択された時点で終了します。

-l  標準出力を行バッファリングします。データを捕捉しつつ そのデータを見たい場合には、このオプションが有効です。例えば
    ``tcpdump -l | tee dat'' や ``tcpdump -l > dat & tail -f dat'' のように使用します。

-n  アドレス (IP アドレスやポート番号など) から名前への変換をしません。

-N  ホスト名のうち、ドメイン名部分を表示しません。このオプションを指定すると、 例えば、``nic.ddn.mil'' とは表示されずに ``nic'' とだけ表示されます。

-O  パケットマッチングコードのオプティマイザを動かしません。このオプションは、 オプティマイザ中にバグがあるのではないかと疑った場合にだけ有効です。

-p  ネットワークインタフェースを、promiscuous-mode に設定しません。 注意しなければならない点は、ネットワークインタフェースは、 何らかの理由により promiscuous-mode に設定されることもあり得るということです。 ゆえに、`-p' オプションは、`ether host {local-hw-addr} or ether broadcast' の短縮形として使うことは出来ません。

-q  高速に (省略して?) 出力します。出力する行を短くするために、通常出力 されるプロトコル情報の一部は出力されません。

-r  パケットを、file で指定したファイル (-wオプションで作成されます) から読み込みます。file として ``-'' が指定された場合には、 標準入力からのデータが用いられます。

-s  各パケットから、snaplen だけのデータを取得します。デフォルトは 68 バイトです (SunOS の NIT では、最小値は実際には 96 です)。68 バイトという データ長は、IP, ICMP, TCP, UDP のパケットを取得するぶんには十分ですが、 ネームサーバや NFS のパケットのプロトコル情報は切り詰められることが あります (下記参照)。スナップショットが限られた量しかとれずに 切り詰められたパケットは、出力に ``[|proto]'' がつくことで わかります。proto の部分には、切り詰められたプロトコルレベルの名前が 入ります。注意しなければならないのは、大きなスナップショットを使う場合には、 それだけパケット処理の時間がかかるということと、 パケットバッファリング用のバッファの量が減るということです。 これにより、パケットが消失するかもしれません。snaplen の大きさは、 必要なパケットの情報を取得できる必要最小限の大きさに とどめるようにしてください。

-T  "expression" で選択されたパケットを強制的に type で 指定されたタイプであると解釈します。有効なタイプは、 rpc (リモートプロシージャコール) rtp (リアルタイムアプリケーションプロトコル) rtcp (リアルタイムアプリケーション制御プロトコル) vat (ビジュアルオーディオツール) wb (ディストリビューテッドホワイトボード) です。

-S  TCP のシーケンス番号を、相対番号ではなく絶対番号で出力します。

-t  各ダンプ行のタイムスタンプを出力しません。

-tt タイムスタンプを、人間が読みやすい形式に変換せずに、各行ごとに出力します。

-v  (少しではありますが) 出力情報を増やします。例えば、IP パケット中の TTL や、サービス情報の型を出力します。

-vv さらに多くの情報を出力します。例えば、NFS の応答パケットの 追加フィールドを出力します。

-w  受信した生パケットを、解析したり画面に出力したりせずに file に出力します。このデータは、後で -r オプションを用いることで 出力することができます。file が ``-'' の場合には、標準出力が用いられ ます。

-x  各パケットの内容 (からリンクレベルヘッダを除いたもの) を 16 進数で出力します。 パケットサイズが snaplen バイトより小さい場合にはパケットの全部の内容を、そうでない場合には、 snaplen バイト分のデータがパケットごとに出力されす。

expression
    ダンプするパケットを選択します。expression が指定されない場合には、 ネットワーク上のすべてのパケットがダンプされます。それ以外の場合には、 expression の条件が `真' になるパケットだけがダンプされます。

    expression は、1 つ以上の プリミティブ から構成されます。プリミティブは通常、 id (名前もしくは番号) とその前につく 1 つ以上のクオリファイアで構成されます。 クオリファイアは、3 種類あります:

    type
        id 名や番号が参照するものの種類を指すクオリファイアです。type には host, net, port があります。例えば、`host foo', `net 128.3', `port 20' のように用います。 type クオリファイアが指定されない場合には、 host が指定されたものとみなされます。

    dir パケットが id へ出ていく方向か、 id から来る方向か、もしくはその両方かという、特定の転送方向を指す クオリファイアです。指定可能な方向は、 src, dst, src or dst, src and dst の 4 つです。 例えば、`src foo', `dst net 128.3', `src or dst port ftp-data' のように 指定します。もし dir クオリファイアが指定されない場合には、 src or dst が指定されたものとみなされます。 `null' リンク層 (つまり、slip などの point-to-point プロトコル) では、 必要な方向を指定するのに inbound や outbound クオリファイアを用いる事ができます。

    proto
        特定のプロトコルに一致するパケットだけに制限するクオリファイアです。 指定可能なプロトコルは、 ether, fddi, ip, arp, rarp, decnet, lat, moprc, mopdl, sca, tcp, udp です。 例えば `ether src foo', `arp net 128.3',`tcp port 21' のように使用します。 もし proto クオリファイアが指定されない場合には、上記のプロトコルのうち、 適用可能なものすべてが指定されたものとみなされます。 例えば、`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 と算術演算式です。これら全てのプリミティブキーワードについては後で 説明します。

    プリミティブを単語 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 port ftp or tcp dst port ftp-data or tcp dst port domain' と全く同じ意味を持ちます。

    許可されているプリミティブは、以下の通りです:

    dst host host
        IP パケットの宛先フィールドが host で指定したものの場合に真となります。 host は、ホスト名もしくは IP アドレスのどちらでも構いません。

    src host host
        IP パケットの送信元フィールドが host で指定したものの場合に真となります。

    host host
        IP パケットの送信元フィールドもしくは宛先フィールドが host で指定した ものの場合に真となります。 上記の host 式の前には、キーワード ip または arp または 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 の両方で定義されていなければなりません (等価な式は、
        ether host ehost and not host host
        です。この場合は、host / ehost には名前と番号のどちらの 表記も用いることができます)。

    dst net net
        パケットの宛先 IP アドレスが、net で指定されたネットワークに属するもので ある場合に真となります。net は、ネットワークの番号または /etc/networks で定義されているネットワーク名のどちらでも構いません (詳細は networks(4) を参照してください)。

    src net net
        パケットの送信元 IP アドレスが、net で指定されたネットワークに 属するものである場合に真となります。

    net net
        送信元 IP アドレスもしくは宛先 IP アドレスが net で指定された ネットワークに属するものである場合に真となります。

    net net mask mask
        IP アドレスが、指定された net および netmask の値で決まる ネットワークに属するものである場合に真となります。 src や dst を指定する事も可能です。

    net net/len
        IP アドレスが、net および len のビット長のネットマスクで 決まるネットワークに属するものである場合に真となります。 src や dst を指定する事も可能です。

    dst port port
        パケットが ip/tcp (TCPパケット) もしくは ip/udp (UDP パケット) であり、 宛先ポート番号が port の場合に真となります。 port は、数値でも、/etc/services に定義されている名前でも 指定可能です ( tcp(4P) や udp(4P) を参照して下さい)。 名前で指定された場合には、ポート番号とプロトコルの両方がチェックされます。 数値や、あいまいな名前が指定された場合には、 ポート番号だけがチェックされます (例えば、dst port 513 は tcp/login と udp/who の両方のトラフィックを出力し、port domain は tcp/domain と udp/domain の両方のトラフィックを出力します)。

    src port port
        パケット内の送信元ポート番号が port である場合に真となります。

    port port
        パケットの送信元ポート番号もしくは宛先ポート番号が port の場合に真と なります。上記のどのポート番号の式でも、キーワード tcp もしくは udp をその前に付加することで、候補を絞り込むことが可能です。 例えば、
        tcp src port port
        と指定した場合には、送信元ポート番号 が port である tcp パケットだけが マッチします。

    less length
        パケットが length で指定した長さ以下の場合に真となります。 これは、
        len <= length
        の指定と等価です。

    greater length
        パケットが length で指定した長さ以上の場合に真となります。 これは、
        len >= length
        と等価です。

    ip proto protocol
        プロトコルの種類が protocol の IP パケット (詳細は ip(4P) を参照して下さい) の場合に真となります。 protocol は、数字もしくは icmp, udp, nd, tcp のいずれかの名前が指定可能です。識別子 tcp, udp, icmp はキーワードでもあるため、バックスラッシュ (\) (C-shell では \\) を用いてエスケープしなければならない点に注意してください。

    ether broadcast
        パケットがイーサネットブロードキャストパケットの場合に真となります。ether キーワードは、省略可能です。

    ip broadcast
        パケットが IP ブロードキャストパケットの場合に真となります。このチェックでは、 オール 1 とオール 0 の両方のブロードキャストアドレスと ローカルサブネットマスクを調べます。

    ether multicast
        パケットがイーサネットマルチキャストパケットの場合に真となります。ether キーワードは省略可能です。 なお、この指定は `ether[0] & 1 != 0' の短縮系です。

    ip multicast
        パケットが IP マルチキャストパケットの場合に真となります。

    ether proto protocol
        パケットが protocol で指定した ether 型のプロトコルの場合に真になります。 protocol は、数字もしくは ip, arp, rarp のような名前が 指定可能です。これらの識別子はキーワードでもあるので、バックスラッシュ (\) でエスケープされなければならないことに注意してください。 [FDDI の場合 (例えば `fddi protocol arp')、プロトコルの識別は IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。通常これは FDDI ヘッダの上の層にあります。tcpdump は、プロトコル識別子で フィルタリングするときは、すべての FDDI パケットは LLC ヘッダを含み、 かつその LLC ヘッダがいわゆる SNAP 形式であると仮定します。]

    decnet src host
        DECNET パケットの送信元アドレスが host の場合に真となります。これは ``10.123'' という形式のアドレスでも DECNET の ホスト名でも構いません。[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, udp, , icmp のいずれかであり、インデックス操作を行うプロトコル層を指示します。 指示したプロトコル層からの相対バイトオフセットは、expr で指定します。 size は省略可能であり、取得するフィールドのバイト長を指示します。この データ長としては、1, 2, 4 のいずれかを指定することが可能であり、デフォルトでは 1 が指定されたものとみなされます。 データ長演算子はキーワード 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 ace
    は、
    not host vs and host ace
    の短縮形ですが、
    not ( host vs or ace )
    と混同してしまいがちなので気をつけましょう。

    引数 expression は、単一の引数としても複数の引数としても、どちらか便利な 方で、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 による各通信のスタートパケットと エンドパケット (SYN と FIN パケット) を表示するには、 以下のように実行します:
    tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'

ゲートウェイ snup で中継される IP パケットのうち、576 バイト より大きいものを表示するには、以下のように実行します:
    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 の出力は、プロトコル依存です。以下では、 ほとんどのプロトコルのフォーマットの概要と例を示します。 リンクレベルヘッダ

イーサネットにおいては、送信元と宛先のアドレス、プロトコル、そして パケット長が出力されます。

FDDI ネットワークの場合、'-e' オプションが指定されると、tcpdump は `フレーム制御' フィールド、発信元と宛先アドレス、パケット長を出力します。 `フレーム制御' フィールドでパケットの残りの部分の解釈が決定します。 (IP データグラムを含むような) 通常のパケットは `async' パケットで、 0 から 7 の間の優先順位を持っています。例えば、`async4' です。こうした パケットは IEEE802.2 の論理リンク制御 (LLC) パケットを含むと仮定され、 それが ISO データグラムでない場合やいわゆる SNAP パケットのときには LLC ヘッダが出力されます。

(注意: 以下の記述は、利用者が RFC1144 に記述されている SLIP 圧縮アルゴリズム についての知識があるという前提で書いています。)

SLIP によるリンクにおいては、方向指示子 (``I'' が入力方向、``O'' が出力方向)とパケットの種類と圧縮情報が出力されます。 パケットの種類が最初に出力されます。パケットの種類には ip, utcp, ctcp の 3 つがあります。ip パケットの場合には、 上記以外のリンク情報は表示されません。TCP パケットの場合には、 コネクションの識別子がパケットの種類に続いて出力されます。 パケットが圧縮されている場合には、エンコードされたヘッダが出力されます。 特殊な場合は *S+n や *SA+n のように出力されます。ここで n は、シーケンス番号 (もしくはシーケンス番号および ack) が変更された 回数です。特殊な場合でなければ、0 回以上の変更について出力されます。 変更は、U (緊急 (urgent) ポインタ)、W (ウィンドウ)、A (ack)、 S (シーケンス番号)、I (パケット 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

1 行目は、ホスト 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 として起動した場合には、最初のパケットは ブロードキャストパケットであり、次のパケットはポイントツーポイントのパケット であることがわかります:

    RTSG Broadcast 0806  64: arp who-has csam tell rtsg
    CSAM RTSG 0806  64: arp reply csam is-at CSAM

最初のパケットは、送信元のイーサネットアドレスは RTSG であり、 宛先はイーサネットブロードキャストアドレス、型フィールドには 16 進数の値 0806 (ETHER_ARP を意味します) が格納されており、総パケット長は 64 バイト であると表示しています。 TCP パケット

(注意: 以下の記述は、RFC793 に記述されている TCP プロトコルについての知識 があることを前提に記述されています。このプロトコルに関する知識がない場合、 この解説と tcpdump のいずれもあなたには役に立たないでしょう。)

TCP プロトコルの行の一般的な形式は、以下の通りです:

    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 ポート 1023 番からホスト csam の login ポートに対してパケットを送信していることを意味します。S は、 パケットの SYN フラグが設定されていることを意味します。 パケットのシーケンス番号は 768512 番であり、データは含んでいません (`first:last(nbytes)' という表記で、これは `シーケンス番号 first から last までの last を含まない nbytes のユーザデータ' ということを意味しています)。 このパケットに ack は積まれておらず、有効な受信ウィンドウの大きさは 4096 バイトであり、最大セグメントサイズオプションが付加されていて、 mss として 1024 バイトを要求しています。

csam は、rtsg から送られたパケットと類似したパケットを送り返しますが、 rtsg の送った SYN に対する ack が含まれるところが異なります。 それから rtsg は、csam の SYN に対し ACK パケットを返します。 `.' はどのフラグも立っていないことを意味します。 このパケットはデータを含んでいないため、データのシーケンス番号はありません。 ack のシーケンス番号が小さい整数 (1) である点に注意して下さい。 tcpdump は、初めて TCP の `通信' を検出すると、パケットから取得した シーケンス番号を表示します。通信のその後のパケットについては、現在の パケットシーケンス番号と、この最初のシーケンス番号との間の差が表示されます。 これは、2 番目以降のシーケンス番号は、その通信のデータストリーム内の バイト単位での相対位置として解釈できることを意味します (各方向の最初のデータバイトが 1 です)。`-S' が指定されると、 この機能に代ってオリジナルのシーケンス番号が表示されるようになります。

6 行目では、rtsg は csam に 19 バイトのデータ (rtsg → csam の方向の 通信における、2 バイト目から 20 バイト目までのデータ) を送信しています。 このパケットには PUSH フラグが設定されています。 7 行目では、csam は、rtsg から 20 バイトまでのデータを受けとった旨の レスポンスを rtsg に返しています。csam の受信ウィンドウが 19 バイト小さく なったことから、これらのデータのほとんどはソケットバッファの中に存在する らしいということが分かります。csam はこのパケットの中で、rtsg に 1 バイトの データを送信しています。 8 行目と 9 行目では、csam は緊急 (urgent) で PUSH フラグの設定された 2 バイトのデータを rtsg へ送信しています。

パケットのスナップショットが小さかったために tcpdump が TCP ヘッダを完全に捕まえることができなかった場合、 ヘッダ中のできるだけ大くの部分を解釈し、そして 残りの部分を解釈できなかったことを示す ``[|tcp]'' を表示します。 ヘッダに bogus オプション (ヘッダ長がすごく小さいものについているか、 そうでなければヘッダの最後尾より先についています) がついている場合は、 tcpdump は ``[bad opt]'' を表示することでそれを示し、 それから先のオプションは (どこから始まったかがわからないので) 解釈しません。 ヘッダ長を示すオプションがあるが、IP データグラムの長さが そのオプションを含めることができるだけの長さぶんない場合、 tcpdump は ``[bad hdr length]'' を表示します。 UDP パケット

UDP フォーマットを、rwho パケットの例で示します:

    actinide.who > broadcast.who: udp 84

これは、ホスト actinide の who ポートから、UDP データグラムを、 インターネットブロードキャストアドレスであるホスト broadcast の who ポートに対して送信していることを表しています。このパケットには 84 バイトのユーザデータが含まれています。

いくつかの UDP サービスは (送信元もしくは宛先のポート番号から) サービスの種類 が判断され、上位レベルのプロトコル情報が表示されます。 ドメインネームサービス要求 (RFC1034/1035) や Sun RPC コール (RFC1050) を用いた NFS サービスなどがこれに該当します。 UDP ネームサーバリクエスト

(注意: 以下の記述は、RFC1035 に記述されているドメインサービスプロトコルの 知識があることを前提に書かれています。もしこのプロトコルの知識がない場合には、 以下の記述は未知の言語で書かれているかのように見えるでしょう)

ネームサーバへの問い合わせは、以下のようなフォーマットになります:

    src > dst: id op? flags qtype qclass name (len)

    h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

ホスト h2opolo は、helios 上のドメインサーバに対して、 ホスト名 ucbvax.berkeley.edu に対応するアドレスレコード (qtype=A) を問い合わせています。 問い合わせの ID は `3' です。`+' は recursion desired フラグが 設定されていることを表しています。問い合わせの長さは 37 バイトであり、 この値には UDP および IP のプロトコルヘッダの長さは含まれません。 この場合の問い合わせ操作は普通の操作 (uery) なので、op フィールドは 省略されます。op が他のいずれかであった場合、`3' と `+' の間に それが表示されます。 同様に、qclass も普通の操作 (C_IN) なので、省略されます。 他の qclass の場合は、`A' の直後に表示されます。

いくつか変則性がチェックされ、その結果によってはカギカッコで囲まれた 付加フィールドにその結果が表示されるかもしれません。 問い合わせが応答やネームサーバやオーソリティセクションを含む場合は、 ancount, nscount, arcount が、`[na]', `[nn]', `[nau]' のような形式で表示されます。 ここで n は、それぞれの個数です。 レスポンスビットのいずれか (AA もしくは RA もしくは rcode) が設定されている 場合、もしくは `0 でなければならない' ビットが 2 バイト目と 3 バイト目に 設定されている場合には、`[b2&3=x]' が出力されます。ここで x は、 ヘッダの 2 バイト目および 3 バイト目の値が 16 進で表示されます。 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)

最初の例は、h2opolo からの問い合わせ ID 3 のリクエストに対し、 helios が 3 つのアンサーレコード、3 つのネームサーバレコード、 7 つのオーソリティレコードを持っているパケットで応答している というものです。 最初のアンサーレコードは、タイプ A (アドレス) であり、そのデータは IP アドレス 128.32.137.3 です。UDP と IP のヘッダを除いた総サイズは 273 バイト です。クラス (C_IN) は、A レコードであるため、op (Query) およびレスポンスコード (NoError) は省略されます。

2 つ目の例は、helios が問い合わせ ID 2 のリクエストに対し、存在しない ドメイン (NXDomain) というレスポンスコードとともに、0 個のアンサーレコード、 1 つのネームサーバレコード、0 個のオーソリティレコードを含んだ レスポンスを返しています。`*' は、authoritative answer ビットが設定され ていることを示します。 アンサーレコードがないため、型やクラスやデータは出力されません。

これら以外に出力されるかもしれないフラグキャラクタとしては、 `-' (再帰利用 (recursion available, RA) が設定されていない) および `|' (メッセージ切捨て (truncated message, TC) が設定されている) があります。`question' セクションに含まれるエントリがきっかり 1 つでない 場合には、`[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 に送信しています (送信元ホストに続く数字はトランザクション ID であり、送信元のポート番号でないことに注意して下さい)。リクエストサイズは、 UDP および IP ヘッダのサイズを除いて 112 バイトです。操作は、 ファイルハンドル (fh) 21,24/10.731657119 に対する readlink (シンボリックリンク読み込み) です (この例のように、運が良ければ、ファイルハンドルはデバイスのメジャー、 マイナー番号のペアと、それに続く i ノード番号と世代番号と解釈することがで きます)。 wrl はリンクの内容とともに `ok' と応答しています。

3 行目では、sushi は wrl に対し、ファイルハンドル 9,74/4096.6878 のディレクトリ中の `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 に対してファイル 21,11/12.195 のオフセット 24576 バイト目から 8192 バイトを読むように要求しています。wrl は `ok' と応答しています。 2 行目に示したパケットは応答の最初のフラグメントなので、1472 バイトしか ありません (その他のデータは継続するフラグメント中に続きますが、 これらのフラグメントは NFS ヘッダも UDP ヘッダさえも持たないので、使用する フィルタリングの式によっては出力されないでしょう)。-v フラグが指定されている ので、いくつかのファイル属性 (ファイルデータに追加されて返されてくる) が 出力されていて、ファイルの型 (普通のファイルなら ``REG'')、 (8 進数表現の) ファイルモード、uid と gid、そしてファイルの大きさ が出力されています。

-v フラグが複数指定されると、さらに詳しい情報が出力されます。

NFS リクエストは非常に大きなデータになるため、snaplen を大きく しなければ詳しい出力は得られません。NFS トラフィックを監視するには、 `-s 192' と指定してみて下さい。

NFS 応答パケットは RPC 操作であることを明示的には示しません。その代り、 tcpdump は ``最近の'' リクエストを追跡して、トランザクション ID を用いて 応答と照合します。応答が対応する要求のすぐ後に続かないと、 解析することはできません。 KIP Appletalk (DDP in UDP)

UDP データグラムでカプセル化された Appletalk DDP パケットは、カプセル化 を解かれ、DDP パケットとしてダンプされます (全ての UDP ヘッダ情報は破棄 されます)。Appletalk ネット番号およびノード番号から名前への変換には ファイル /etc/atalk.names が用いられます。このファイルは、以下のような形式になります:

    number	name
    1.254		ether
    16.1		icsd-net
    1.254.110	ace

最初の 2 行は、Appletalk ネットワーク名を決めています。3 行目の内容は、 特定のホストの名前を決めています (ホストは、3 オクテット目の有無で ネットワークと区別されます。ネットワーク番号は 2 オクテットの数値から、 ホスト番号は 3 オクテットの数値から構成される必要があります)。 番号と名前は、空白文字もしくはタブ文字で区切られます。 /etc/atalk.names ファイルは、空行もしくは `#' 文字で始まるコメント行を含んでもかまいません。

Appletalk アドレスは、以下のように表示されます:

    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 port 2) が、 ネットワーク icsd のノード番号 112 のホストのポート番号 220 番を listen している何者かにデータを送信しています。 次の行は、1 行目とほぼ同じ例ですが、送信元のノード名が既知である (`office') ところが異なります。 3 行目の例は、ネットワーク jssmag のノード番号 149 のポート 235 から、 icsd-net の NBP ポートにデータ送信をしています (ブロードキャストアドレス (255) は、ホスト番号なしでネットワーク番号のみが 表示されているところでわかります。このことから、/etc/atalk.names では ノード名とネットワーク名を区別しておく方がよいでしょう)。

NBP (name binding protocol) パケットと ATP (Appletalk transaction protocol) パケットは、その内容が解釈されます。 他のプロトコルの場合は、プロトコル名 (もしくは、プロトコル名が登録されていない 場合には、プロトコル番号) とパケットサイズが単にダンプされるだけです。 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

最初の行は、laserwriter の名前検索要求であり、ネットワーク icsd の 112 番 ホストからネットワーク jssmag へとブロードキャストされています。 この検索の nbp ID は 190 です。 2 行目は、この要求に対する jssmag.209 からの応答 (同じ ID を持つことに 注意してください) で、ポート 250 に登録された RM1140 という名前の laserwriter があると答えています。 3 行目は、同じ要求に対する別の応答で、 ホスト techpit が laserwriter "techpit" を持っており、 ポート 186 に登録されていると答えています。 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

jssmag.209 は、ホスト helios に対し最大 8 個までのパケット (`<0-7>') を 要求して、トランザクション ID 12266 のトランザクションを開始します。 行の最後の 16 進数は、リクエスト中の `userdata' フィールドの値です。

helios は、8 個の 512 バイトのパケットで応答しています。トランザクション ID の後につづく `:数' はパケットシーケンス番号を、括弧中の数値は ATP ヘッダ を除いたパケット中のデータ量を示しています。パケットシーケンス 7 のところの `*' は、EOM ビットが設定されていることを示しています。

それから jssmag.209 は、パケットシーケンス番号 3 と 5 のパケットの 再送要求をしています。 helios はそれらを再送し、その後 jssmag.209 はそのトランザクションを解放します。 最後に、jssmag.209 は次のリクエストを発行します。このリクエストの表示 で付加されている `*' は、XO (`exactly once') が設定されていないことを 示しています。 IP フラグメンテーション

フラグメント化されたインターネットデータグラムは、以下のように表示されます:

    (frag id:size@offset+)
    (frag id:size@offset)

(最初の形式では、まだフラグメントがあることを示し、2 番目の形式は、 これが最後のフラグメントであることを示しています。)

id は、フラグメント ID です。size は、フラグメントサイズを バイト単位であらわしたものです。ただし IP ヘッダサイズは含みません。 offset は、オリジナルのデータグラム内でのこのフラグメントのオフセット (単位はバイト) です。

フラグメント情報は、各フラグメントごとに表示されます。最初のフラグメントには、 上位レベルのプロトコルヘッダが含まれるので、フラグ情報がプロトコル情報の後に 表示されます。2 つ目以降のフラグメントには上位レベルのプロトコルヘッダが 含まれないので、フラグ情報は送信元および宛先アドレスの後ろに表示されます。 たとえば、以下の例は arizona.edu から lbl-rtsg.arpa へ CSNET 経由で 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

ここで注意すべきことが 2 つあります。まず最初ですが、2 行目のアドレス部分には ポート番号が含まれていません。これは、TCP プロトコル情報は、最初のフラグメント に全て入っており、その後のフラグメントを出力する時にはポート番号やシーケンス 番号を知る術がないからです。 次に、最初の行の TCP シーケンス情報は、パケットが 308 バイトのユーザデータ を持ってるかのように表示されていますが、実際には 512 バイトのユーザデータを 持っています (308 バイトが最初のフラグ分で、204 バイトが 2 番目のフラグ分 です)。シーケンススペースの穴を探したり、パケットの ack の対応が正しいかを このデータで見ようとしてはいけません。

フラグメント不可フラグが設定されたパケットは、トレイリング (DF) の 印が付けられます。 タイムスタンプ

デフォルトでは、すべての出力行の先頭にタイムスタンプがつきます。 タイムスタンプは、以下の形式で現在の時刻を表示し:
    hh:mm:ss.frac
この精度は、カーネルクロックの精度に依存します。 タイムスタンプは、カーネルがそのパケットを最初に見つけた時間を反映します。 イーサネットインタフェースがワイヤからパケットを取り出し、 `新規パケット' 割り込みに対してカーネルがサービスを行うまでのタイムラグは 補正しません。

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

作者
Van Jacobson, Craig Leres, Steven McCanne, Lawrence Berkeley Laboratory, University of California, Berkeley, CA. の全員

最新バージョンは anonymous ftp で入手可能です:

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

バグ
バグレポートは tcpdump@ee.lbl.gov に送ってください。

NIT では、外に出ていくトラフィックを観察できません。BPF ならできます。 後者を用いることを推奨します。

上位プロトコルのために、IP フラグメントの再構成か、 少なくともパケットの正しい長さの計算を試みるようにすべきです。

ネームサーバについての逆引きは、正しくダンプされません。(空の) クエスチョンセクションが、アンサーセクション内にある本当の query の 代りに出力されます。逆引きはそれ自身がバグを含んでいることがあり、 これは tcpdump ではなく逆引きを要求するプログラムの方を修正したほうがいい と考える人たちもいます。

Apple Ethertalk DDP パケットは、KIP DDP パケットと同様に簡単にダンプ出来る ようにしたいのですが、実際はそうではありません。 もし我々が、Ethertalk の利用を奨めるために何かやろうという気になったとしても (そうではないのですが)、LBL (Lawrence Berkeley Laboratory) のどの ネットワーク上にも Ethertalk を通すことは許されていませんから、そのコード の試験は出来ません。

夏時間の変更を跨いでパケットトレースを行うと、タイムスタンプがずれて しまいます (時間変化は無視されます)。

FDDI ヘッダを操作するようなフィルタの式においては、全ての FDDI パケットは Ethernet パケットにカプセル化されていると仮定しています。 これは、IP, ARP, DECNET フェーズ 4 については正しいですが、ISO の CLNS 等の プロトコルについては正しくありません。したがって、フィルタ表現に正しく マッチしないようなパケットを偶然に受け入れてしまうことがあります。