TCPDUMP

索引

名称

索引

書式

索引

解説

tcpdump は、オプションで指定されたネットワークインタフェース上で 取得可能なパケットのヘッダのうち expression にマッチするものを出力 します。 パケットデータを後で分析するためファイルに保存するよう、 -w フラグで実行することもできます。 また、 -r フラグで、ネットワークインタフェースからのパケットではなく、 ファイルに保存されたパケットから読み込むことができます。 すべての場合に、 expression にマッチするパケットだけ、 tcpdump によって処理されます。

tcpdump は、 -c フラグで実行しない場合、SIGINT シグナル ( 例えば、一般的な手法として 割り込み文字列である control-C の入力) か SIGTERM シグナル (一般的な手法として kill(1) コマンド) によって割り込みがあるまで、パケットを捕捉し続けます。 -c フラグで実行する場合は、 SIGINT シグナル や SIGTERM シグナルで割り込みされるか、 指定されたパケット数まで処理します。

tcpdump がパケットの捕捉を終了したとき、以下の合計を 表示します。

packets ``captured'' (これは tcpdump が受信し処理したパケット数です);

packets ``received by filter'' (この意味は、 tcpdump を実行している OS に依存しますし、 おそらく OS のコンフィギュレーション方法にも依存するでしょう。 filter がコマンドラインで指定された場合、 ある OS では filter expression に一致したかどうかに関わらず、 また filter expression に一致したものであっても、 tcpdump が読み込み、処理したものであるかどうかに関わらずパケットを数えます。 別の OS では、filter expression に一致したパケットのみ数えますが、 tcpdump が読み込み、処理したものであるかどうかには関わりません。 また別の OS では、filter expression によって一致し、 tcpdump によって処理されたパケットのみを数えます);

packets ``dropped by kernel'' (OS がアプリケーションにその情報を報告する場合には、 バッファスペースの不足により、 tcpdump が走っている OS の パケット捕捉制御機構から、落ちてしまったパケット の数です。 それ以外の場合には、0 が表示されます。)

(Mac OS X を含む) 大抵の BSD や Digital/True64 UNIX のような SIGINFO シグナルがサポートされているプラットホームでは、SIGINFO シグナル を受信したとき、それらの合計を表示して、パケットの捕捉を引き続き行います (SIGINFO シグナルは、例えば典型的には ``status'' 文字である control-T の 入力によって生成されます。 しかし Mac OS X などいくつかのプラットフォームでは、``status'' 文字は デフォルトでは設定されていませんので、これを使用するには stty(1) によって設定する必要があります)。

ネットワークインタフェースからパケットを読むには、 権限を必要とします。

SunOS 3.x、4.x 上の NIT ないし BPF の場合:

/dev/nit ないし /dev/bpf* への読み込みアクセス権が必要です。

Solaris 上の DLPI の場合:

/dev/le 等のネットワーク仮想デバイスへの読み書きアクセス権が必要です。 少なくとも Solaris のいくつかのバージョン上では、 tcpdump が promiscuous モードで捕捉するには、 この条件だけでは不十分です。 それらの Solaris のバージョンでは、root になる必要があります。 もしくは promiscuous モードで捕捉するには root に setuid されてインストールされている場合のみ tcpdump の実行が可能になります。 多くの (おそらくすべての) インタフェースにおいて、promiscuous モードで 捕捉しないと、送出されるパケットは見ることができないでしょう。 そのため、promiscuous モードで捕捉が行われない場合は、 あまり役に立たないであろうことに注意してください。

HP-UX 上の DLPI の場合:

使用者が root であるか、 tcpdump が root に setuid されてインストールされている場合のみ実行可能です。

IRIX 上の snoop の場合:

使用者が root であるか、 tcpdump が root に setuid されてインストールされている場合のみ実行可能です。

Linux の場合:

使用者が root であるか、 tcpdump が root に setuid されてインストールされている場合のみ実行可能です (ただし、使用しているディストリビューションが、 CAP_NET_RAW などのケーパビリティビットをサポートするカーネルを持ち、 これらのケーパビリティビットを特定のアカウントに与えることができ、 そのユーザがログインした時の最初のプロセスにそのビットがセットされるような コードを持っている場合は、この限りではありません。 その際には、パケットを捕捉するためには CAP_NET_RAW が、そして例えば -D フラグによってネットワークデバイスを列挙するためには CAP_NET_ADMIN が必要です)。

ULTRIX および Digital UNIX/Tru64 UNIX の場合:

どのユーザも tcpdump を使用して、ネットワークトラフィックを捕捉できます。 しかしながら、捕捉を行うインタフェースに対して、スーパユーザが pfconfig(8) を用いて promiscuous モードの操作を許可しない限り、 どのユーザも (スーパユーザでさえも)、そのインタフェースにおいて promiscuous モードで捕捉を行うことはできません。 また、捕捉を行うインタフェースに対して、スーパユーザが pfconfig を用いて copy-all モードの操作を許可しない限り、 どのユーザも (スーパユーザでさえも)、そのインタフェースにおいて マシンが送受信するユニキャストトラフィックを捕捉することはできません。 したがって、あるインタフェースにおいて 有用な パケットの捕捉を行うには、promiscuous モードか copy-all モードの操作、 もしくは両モードの操作が、そのインタフェースにおいて 有効になっている必要があります。

BSD の場合 (Mac OS X を含む):

/dev/bpf* への読み込みアクセス権が必要です。 ただし devfs を使用する BSD (Mac OS X も含まれる) では、 単にスーパユーザ権限を持つユーザが BPF デバイスの所有者やパーミッションを 設定するだけでは十分でないかも知れません。 なぜなら、システムが起動する度に毎回、所有者やパーミッションを 設定しなければならないからです。 起動時に設定する機能を備えた devfs を使っているシステムでは、 そのための設定も必要になるかも知れませんし、 その機能がないシステムでは、何らかの方法を使って、起動時にその設定が 行われるようにする必要があるでしょう。

保存されたパケットファイルを読むには、権限を必要としません。  

索引

オプション

-A

各々のパケット (からリンクレベルのヘッダを除いたもの) を ASCII で表示します。 Web ページを捕捉する場合に便利です。

-c

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

-C

保存ファイルに raw パケットを書き込む前に、 現在のファイルが file_size より大きいかどうか をチェックします。 もし大きいなら、現在の保存ファイルを閉じて新しいものを開きます。 付けられるファイル名は、最初の保存ファイルを除く 2 番目以降の保存ファイルから -w フラグで指定されたファイル名の 後にそれぞれ番号がつきます。 その番号は、2 から始まり順に大きくなります。 file_size の単位は 100 万バイト (1,000,000 バイト。1,048,576 バイトの ことではない) です。

-d

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

-dd

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

-ddd

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

-D

そのシステム上で利用可能で、 tcpdump がパケットを捕捉できるネットワークインタフェースのリストを出力します。 それぞれのネットワークインタフェースに対して、番号とインタフェース名、 そして可能であればそのインタフェースの説明を表示します。 ネットワークインタフェース名、および番号は、捕捉を行うインタフェースを -i フラグで指定する際に使用できます。

これは、インタフェースをリストするコマンドを持たない システムにおいて有用です (例えば、Windows システムや ifconfig -a を持たない UNIX システム)。 また番号は、Windows 2000 以降のシステムのように、インタフェース名が 何か複雑な文字列の場合に便利です。

tcpdump が pcap_findalldevs() 関数を持たない古いバージョンの libpcap を使って構築された場合、 -D フラグはサポートされません。

-e

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

-E

spi@ipaddr algo:secret を、addr 宛でセキュリティパラメータ インデックスの値 spi を含む IPsec ESP パケットの解読に使用します。 この組み合わせを、コンマか改行で区切って繰り返し指定することができます。

今では IPv4 の ESP パケットに対する secret が設定できるようになりました。

アルゴリズムは des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, none のいずれかです。 デフォルトは des-cbc です。 パケット解読能力は、 tcpdump が暗号機能付きでコンパイルされた場合のみ存在します。

secret は、ESP 秘密鍵の ASCII テキストです。 0x で始まっている場合、16 進数値として読み込まれます。

本オプションは、RFC1827 ESP ではなく、RFC2406 ESP を仮定します。 本オプションは、デバッグ専用であり、 本当の「秘密」鍵に対する使用は勧められません。 IPsec 秘密鍵をコマンドラインに置くと、 ps(1) 等によって他者に見えてしまいます。

上記の構文に加えて、tcpdump が指定されたファイルを読み込むのに file name という構文が使用できます。 ファイルは、最初の ESP パケットを受信した際にオープンされます。 そのため、tcpdump に与えられているであろうすべての特別なパーミッションは、 それまでに破棄しておくべきでしょう。

-f

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

外部ホストの IPv4 アドレスに対する検査は、捕捉を行っているインタフェースの IPv4 アドレスとネットマスクを用いて行われます。 もし、そのアドレス、またはネットマスクが無効だった場合、 このオプションは正しく動作しません。 これは、捕捉を行っているインタフェースにアドレス、もしくはネットマスクが 設定されていなかったり、または 2 つ以上のインタフェース上で捕捉を行える Linux の "any" インタフェースを使用している場合に起こります。

-F

フィルタの表現として、file に記述してある内容を用います。 コマンドラインで指定された追加表現は、無視されます。

-i

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

2.2 以降のカーネルの Linux システムでは、 interface 引数 ``any'' を指定して全インタフェースからのパケットを捕捉可能です。 ``any'' デバイスでの捕捉は、promiscuous モードではないことに注意してください。

-D フラグがサポートされている場合、このフラグで表示されるインタフェース番号は interface 引数に使用できます。

-l

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

-L

インタフェースの既知のデータリンクタイプを列挙し、終了します。

-m

SMI MIB モジュールの定義を、ファイル module からロードします。 複数の MIB モジュールを tcpdump にロードするために、 複数回このオプションを使用することができます。

-n

アドレス (IP アドレスやポート番号など) を名前に変換しません。

-N

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

-O

パケットマッチングコードのオプティマイザを動かしません。本オプションは、 オプティマイザ中のバグを疑う場合にのみ有効なものです。

-p

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

-q

素早い (静かな?) 出力を行ないます。出力する行を短くするために、通常出力 されるプロトコル情報の一部は出力されません。

-R

ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に基いているものと仮定します。 指定すると、tcpdump はリレー防止フィールドを表示しません。 ESP/AH 仕様にはプロトコルバージョンフィールドがありませんので、 tcpdump は ESP/AH プロトコルのバージョンを推定できません。

-r

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

-S

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

-s

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

-T

"expression" により選択されたパケットを強制的に type で 指定されたタイプと解釈します。有効なタイプは、 aodv (アドホックオンデマンドディスタンスベクタープロトコル) cnfp (Cisco NetFlow プロトコル), rpc (リモートプロシージャコール) rtp (リアルタイムアプリケーションプロトコル) rtcp (リアルタイムアプリケーション制御プロトコル) snmp (シンプルネットワークマネージメントプロトコル) tftp (トリビアルファイル転送プロトコル) vat (ビジュアルオーディオツール) wb (ディストリビューテッドホワイトボード) です。

-t

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

-tt

各ダンプ行毎にタイムスタンプを人間が読みやすい形に変換せずに出力します。

-ttt

直前のダンプ行と現在のダンプ行の差分 (マイクロ秒単位) を表示します。

-tttt

各ダンプ行で、デフォルト書式でタイムスタンプを表示し、その前に日付を付けます。

-u

デコードされてない NFS 操作を出力します。

-U

-w オプションで保存される出力を、「パケットバッファ」モードにします。 つまり、出力バッファがいっぱいになった時のみ書き出すのではなく、 各パケットが保存される度に出力ファイルに書き出します。

tcpdump が pcap_dump_flush() 関数を持たない古いバージョンの libpcap を使って構築された場合、 -U フラグはサポートされません。

-v

(少しではありますが) 出力情報を増やします。例えば、IP パケット中の TTL、識別、全長、IP パケット中のオプションが表示されます。 追加のパケットの完全性確認が有効になります。 これは例えば IP および ICMP のヘッダのチェックサムです。

-vv

さらに多くの情報を出力します。例えば、NFS の返答パケットの追加 フィールドや完全にデコードされた SMB パケット を出力します。

-vvv

もっと多くの情報を出力します。例えば、telnet SB ... SE オプションが完全に表示されます。 -X 付きでは、telnet オプションが 16 進数で表示されます。

-w

受信した生パケットを、解析したり画面に出力したりせずに file で指定 したファイルに出力します。本オプションを用いて取得したパケットは -r オプションを用いることで情報を見ることができます。file で指定す るファイル名が ``-'' の場合には、標準出力を用います。

-x

リンクレベルヘッダを除いた各パケットの内容を 16 進数で出力します。 パケットサイズが snaplen バイトより小さい場合にはパケットの全部の内容を、それ以外の場合には、 snaplen バイト分のデータをパケットごとに出力します。 ここで出力されるのはリンク層のパケット全体であるため、 パディングするようなリンク層 (例えばイーサネット) の場合、 上位層のパケットが必要な長さよりも短かった時には パディングされたバイトも表示されることに注意してください。

-xx

各々のパケットを、リンクレベルのヘッダも 含めて 、16 進数で表示します。

-X

各々のパケット (からリンクレベルのヘッダを除いたもの) を、 16 進数と ASCII で表示します。 新規プロトコルを解析するのに非常に便利です。

-XX

各々のパケットを、リンクレベルのヘッダも 含めて 、16 進数と ASCII で表示します。

-y

パケット捕捉中に使用するデータリンクタイプを datalinktype に 設定します。

expression

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

expression は、1 つ以上の プリミティブ から成り立ちます。 プリミティブは通常 1 つ以上の限定子のついた id (名前もしくは番号) から成り立ちます。限定子は、3 種類あります。

型

限定子は id 名や番号が参照するものの種類を指します。型には host, net, port があります。例えば、`host foo', `net 128.3', `port 20' のように用います。 型限定子が指定されない場合には、 host が指定されたものとみなされます。

方向

限定子は、 パケットが id へ出ていく方向か、 id から来る方向か、 もしくはその両方かという、特定の転送方向を指定します。 指定可能な方向は、 src, dst, src or dst, src and dst の 4 つです。 例えば、`src foo', `dst net 128.3', `src or dst port ftp-data' のように 指定します。もし方向限定子が指定されない場合には、 src or dst が指定されたものとみなします。 SLIP や、``any'' や他のデバイスタイプを用いた Linux の ``cooked'' 捕捉モードのようなリンク層では、 必要な方向を指定するのに inbound や outbound 限定子を用いる事ができます。

プロトコル

限定子は、特定のプロトコルに一致するパケットのみに制限します。 プロトコルとして指定可能なものは、 ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, iso, esis, isis, icmp, icmp6, tcp , udp です。 例えば `ether src foo', `arp net 128.3', `tcp port 21' のように使用 します。もしプロトコル限定子が指定されない場合には、上記のプロトコルの うち、型に矛盾しないすべてのものが指定されたものとみなします。 例えば `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 ヘッダは他のフィールドも含みますが、フィルタ表現の中で 明示的にそれらを指定することはできません。

同様に、`tr' と `wlan' は `ether' の別名です。 直前の段落における FDDI ヘッダに関する記述は、 Token Ring ヘッダや 802.11 無線 LAN ヘッダにも適用されます。 802.11 ヘッダでは、終点アドレスが DA フィールドで、始点アドレスが SA フィールドです。 BSSID, RA, TA フィールドは検査されません。]

上記に追加して、いくつかの特別な「プリミティブ」キーワードがあります。 これらのキーワードは 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

IPv4/v6 パケットの終点フィールドが host で指定したものの場合に、 真となります。 host は、ホスト名もしくは IP アドレスです。

src host host

IPv4/v6 パケットの始点フィールドが host で指定したものの場合に、 真となります。

host host

IPv4/v6 パケットの始点フィールドもしくは終点フィールドが host で指定したものの場合に、 真となります。 上記の host プリミティブの表現には、 ip, arp, rarp, ip6 を 以下のように付加することが可能です。

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 マシンの host-name-to-IP-address (名前解決) 制御機構 (hosts ファイル、DNS、NIS など) とマシンの host-name-to-Ethernet-address (イーサネット アドレス解決) 制御機構 (/etc/ethers など) から見つけられる名前である必要があります。 (同様な記述は、

ether host ehost and not host host

です。この場合 host / ehost のどちらにも名前もしくは値を用いることが 可能になります。) この構文は、現在のところ、IPv6 が有効な構成では動作しません。

dst net net

パケットの終点 IPv4/v6 アドレスが、 net で指定されたネットワークに属するものである場合に、 真となります。 net は、アドレス値もしくは /etc/networks で 定義されたネットワーク名のいずれかを指定可能です (詳しくは、networks(4) を参照)。

src net net

パケットの始点 IPv4/v6 アドレスが、 net で指定されたネットワークに属するものである場合に、真となります。

net net

始点 IPv4/v6 アドレスもしくは終点 IPv4/v6 アドレスが net で指定された ネットワークに属するものである場合に、真となります。

net net mask netmask

IP アドレスが、指定された net および netmask の値で決まる ネットワークに属するものである場合に、真となります。 src や dst を指定する事も可能です。 この構文は IPv6 net では正当でないことに注意してください。

net net/len

IPv4/v6 アドレスが、指定された len のビット長のネットマスクで net に属するネットワーク の場合に、真となります。 src や dst を指定する事も可能です。

dst port port

パケットが ip/tcp, ip/udp, ip6/tcp, ip6/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

と指定した場合には、tcp パケットのみが条件一致の評価対象となります。

less length

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

len <= length

の指定と等価です。

greater length

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

len >= length

と等価です。

ip proto protocol

パケットが protocol で指定したプロトコル型の IP パケット ( 詳細は ip(4P) を参照) の場合に、真となります。 protocol は、数字もしくは icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, tcp のいずれかの名前が指定可能です。tcp, udp, icmp の 各識別子はキーワードでもであり、バックスラッシュ (\)(C-shell では \\) を用 いてエスケープしなければならないことに注意してください。 このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。

ip6 proto protocol

パケットがプロトコル型 protocol の IPv6 パケットである場合に、 真となります。 このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。

ip6 protochain protocol

パケットが IPv6 パケットであり、 プロトコルヘッダチェーン中にタイプ protocol のプロトコルヘッダが 含まれるばあい に、真となります。 例えば

ip6 protochain 6

は、TCP プロトコルヘッダがプロトコルヘッダチェーン中に含まれる 任意のパケットにマッチします。 パケット中には、IPv6 ヘッダと TCP ヘッダの間に、 例えば、認証ヘッダ、ルーティングヘッダ、ホップ毎のオプションヘッダが 含まれ得ます。 このプリミティブが出力する BPF コードは、 複雑であり tcpdump 中の BPF 最適化コードでは最適化できません。 よって、この動作はいくぶん遅いです。

ip protochain protocol

ip6 protochain protocol と同様で、 IPv4 のものです。

ether broadcast

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

ip broadcast

パケットが IPv4 ブロードキャストパケットの場合に、真となります。 オール 1 とオール 0 の 2 つの形式のブロードキャストアドレスを検査し、 そして捕捉が行われているインタフェースのサブネットマスクを調べます。

もし、そのネットマスクが無効だった場合、この検査は正しく動作しません。 これは、捕捉を行っているインタフェースにネットマスクが 設定されていなかったり、または 2 つ以上のインタフェース上で捕捉を行える Linux の "any" インタフェースを使用している場合に起こります。

ether multicast

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

ip multicast

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

ip6 multicast

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

ether proto protocol

パケットの ether 型が protocol の場合に、真になります。 protocol は、数字もしくは ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, netbeui のいずれかの名前を指定可能です。 これらの識別子はキーワードでもあり、バックスラッシュ (\) でエスケープし なければならないことに注意してください。

[FDDI (例えば `fddi protocol arp') や Token Ring (例えば`tr protocol arp')、IEEE 802.11 無線 LAN (例えば `wlan protocol arp') の場合、これらのほとんどのプロトコルに対して、 プロトコルの識別は IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。 通常これは FDDI ヘッダや Token Ring ヘッダ、802.11 ヘッダの上位層にあります。

FDDI, Token Ring, 802.11 のほとんどのプロトコル識別子に対して フィルタリングをかける場合、tcpdump は、カプセル化イーサネットに対しては、 管理組織識別子 (OUI) 0x000000 を持つ、いわゆる SNAP フォーマットの LLC ヘッダのプロトコル ID のみをチェックします。 そのパケットが、0x000000 の OUI を持つ SNAP フォーマットであるかどうかは チェックしません。 例外は以下の通りです:

iso

tcpdump は、LLC ヘッダの DSAP (Destination Service Access Point) フィールドと SSAP (Source Service Access Point) フィールドもチェックします。

stp および netbeui

tcpdump は、LLC ヘッダの DSAP をチェックします。

atalk

tcpdump は、0x080007 の OUI と Appletalk の etype を持つ SNAP フォーマットのパケットをチェックします。

イーサネットの場合、tcpdump は、これらのプロトコルのほとんどに対して イーサネットタイプフィールドをチェックします。 例外は以下の通りです:

iso, sap, netbeui

tcpdump は、FDDI, Token Ring, 802.11 の場合と同様に、 802.3 フレームをチェックし、次に LLC ヘッダをチェックします。

atalk

tcpdump は、FDDI, Token Ring, 802.11 の場合と同様に、 イーサネットフレーム内 の Appletalk etype および SNAP フォーマットパケットの両方に対してチェックします。

aarp

tcpdump は、イーサネットフレームまたは 0x000000 の OUI を持つ 802.3 SNAP フレームに対し、Appletalk ARP etype をチェックします。

ipx

イーサネットフレーム内の IPX etype、LLC ヘッダ内の IPX DSAP、 IPX の LLC ヘッダを持たない 802.3 カプセル化、 および SNAP フレーム内の IPX etype をチェックします。

decnet src host

DECNET パケットの始点アドレスが host の場合に、真となります。これは ``10.123'' という形式のアドレスでも DECNET の ホスト名でも構いません。[DECNET のホスト名は DECNET を動かすように設定され た ULTRIXシステムのみでサポートされます。]

decnet dst host

DECNET パケットの終点アドレスが host の場合に、真となります。

decnet host host

DECNET パケットの始点あるいは終点アドレスが host の場合に、真となります。

ifname interface

パケットが、指定されたインタフェースから来たとログに記録されると、真となります (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

on interface

ifname 修飾子と同義です。

rnr num

パケットが、指定された PF のルール番号にマッチしたとログに記録されると、 真となります。 (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

rulenum num

rnr 修飾子と同義です。

reason code

パケットが、指定された PF の原因コードによってログに記録されると、真となります。 コードは次のようなものです: match, bad-offset, fragment, short, normalize, memory (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

rset name

パケットが、指定された PF のアンカルールセットのルールセット名に マッチしたとログに記録されると、真となります。 (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

ruleset name

rset 修飾子と同義です。

srnr num

パケットが、指定された PF のアンカルールセットのルール番号に マッチしたとログに記録されると、真となります。 (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

subrulenum num

srnr 修飾子と同義です。

action act

パケットが記録された時に、PF が指定された動作を行った場合、真となります。 動作とは、次のものです: pass , block (OpenBSD の pf(4) によってログに記録されたパケットのみに適用されます)。

ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui

これらは

ether proto p

の短縮形です。p の部分には、上記のいずれかのプロトコル名が入ります。

lat, moprc, mopdl

これらは

ether proto p

の短縮形です。p の部分には、上記のいずれかのプロトコル名が入ります。 tcpdump は今のところこれらのプロトコルを解釈できない事に注意して ください。

vlan [vlan_id]

パケットが IEEE 802.1Q VLAN パケットの場合、真になります。 [vlan_id] が指定された場合、 パケットが指定された vlan_id を持つ場合のみ、真になります。 expression 中の最初の vlan キーワードが、 パケットが VLAN パケットであることを仮定して、 残りの expression のデコード用オフセットを変更してしまうことに 注意してください。

tcp, udp, icmp

これらは

ip proto p or ip6 proto p

の短縮形です。p の部分には、上記のいずれかのプロトコル名が入ります。

iso proto protocol

パケットがプロトコル型 protocol の OSI パケットの場合、真になります。 protocol は数値もしくは clnp, esis, isis という名前のいずれかです。

clnp, esis, isis

これらは

iso proto p

の短縮形です。p の部分には、上記のいずれかのプロトコル名が入ります。

l1, l2, iih, lsp, snp, csnp, psnp

IS-IS PDU タイプの短縮形です。

vpi n

パケットが Solaris 上の SunATM にとって、仮想パス識別子が n の ATM パケットの場合、真となります。

vci n

パケットが Solaris 上の SunATM にとって、仮想チャネル識別子が n の ATM パケットの場合、真となります。

lane

パケットが Solaris 上の SunATM にとって、ATM パケットであり、 ATM LANE パケットであった場合、真となります。 expression に lane キーワードがあると、 パケットが、イーサネットをエミュレートした LANE パケットか、 もしくは LANE LE 制御パケットであると仮定して、 残りの expression に対して行われる検査が変更されることに 注意してください。 lane が指定されなければ、パケットが LLC カプセル化パケットであると 仮定して、検査が行われます。

llc

パケットが Solaris 上の SunATM にとって ATM パケットであり、 LLC カプセル化パケットの場合、真となります。

oamf4s

パケットが Solaris 上の SunATM にとって ATM パケットであり、 セグメント OAM F4 フローセル (VPI=0 & VCI=3) の場合、真となります。

oamf4e

パケットが Solaris 上の SunATM にとって ATM パケットであり、 エンド・トゥ・エンド OAM F4 フローセル (VPI=0 & VCI=4) の場合、真となります。

oamf4

パケットが Solaris 上の SunATM にとって ATM パケットであり、 セグメント もしくは エンド・トゥ・エンド OAM F4 フローセル (VPI=0 & (VCI=3 | VCI=4)) の場合、真となります。

oam

パケットが Solaris 上の SunATM にとって ATM パケットであり、 セグメント もしくは エンド・トゥ・エンド OAM F4 フローセル
 (VPI=0 & (VCI=3 | VCI=4)) の場合、真となります。

metac

パケットが Solaris 上の SunATM にとって ATM パケットであり、 メタ・シグナリング・サーキット (VPI=0 & VCI=1) 上であった場合、真となります。

bcc

パケットが Solaris 上の SunATM にとって ATM パケットであり、 ブロードキャスト・シグナリング・サーキット (VPI=0 & VCI=2) 上であった場合、 真となります。

sc

パケットが Solaris 上の SunATM にとって ATM パケットであり、 シグナリング・サーキット (VPI=0 & VCI=5) 上であった場合、 真となります。

ilmic

パケットが Solaris 上の SunATM にとって ATM パケットであり、 ILMI サーキット (VPI=0 & VCI=16) 上であった場合、 真となります。

connectmsg

パケットが Solaris 上の SunATM にとって ATM パケットで、 シグナリング・サーキット上にあり、Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, Release Done メッセージであった場合に、真となります。

metaconnect

パケットが Solaris 上の SunATM にとって ATM パケットで、 メタ・シグナリング・サーキット上にあり、Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, Release Done メッセージであった場合に、真となります。

expr relop expr

relopは、>, <, >=, <=, =, != のいずれかであり、expr の部分に は、(標準 C 言語の構文で表現された) 整数定数や通常の二項演算子 [+, -, *, /, &, |, <<, >>]、length 演算子、そして特殊なパケットデータへのアクセス演算子などか らなる算術表現が入って、その関係が成立する場合に、真となります。 パケット内部のデータにアクセスするためには、以下の構文を用います。

proto [ expr : size ]

protoは、ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 のいずれかであり、 インデックス操作を行うプロトコル層を指示します (ether, fddi, wlan, tr, ppp, slip, link はすべて リンク層を指します)。 tcp, udp および他の上位層プロトコル型は、 IPv4 のみに適用され、IPv6 には適用されないことに注意してください (これは将来修正されます)。 指示したプロトコル層からの相対バイトオフセットは、expr で指定します。 size は省略可能で、取得するフィールドのデータ長を表します。 データ長としては、1,2,4 のいずれかを指定することが可能であり、デフォルトでは 1 が指定されたものとみなされます。 キーワード len で示されるデータ長演算子は、パケット長を与えます。

例えば、`ether[0] & 1 != 0' は、全てのマルチキャストパケットを捕捉します。 `ip[0] & 0xf != 5' という表現は、すべてのオプション付きIPパケットを捕捉す ることを意味します。`ip[6:2] & 0x1fff = 0' という表現は、フラグメントのな いデータグラムパケット、もしくはフラグメント化されたデータグラムのうち 最初のフラグメントを捕捉します。 この検査は、tcp および udp のインデックス操作においては、暗黙のうち に適用されます。 例えば、tcp[0] は常に TCP ヘッダの先頭バイトを指し、 決して各フラグメントの先頭バイトを指すものではありません。

いくつかのオフセットとフィールド値は、数値ではなく 定数として表記できます。 次のプロトコルヘッダフィールドオフセットが利用可能です。 icmptype (ICMP タイプフィールド)、icmpcode (ICMP コードフィールド) および tcpflags (TCP フラグフィールド)

次の ICMP タイプフィールド値が利用可能です。 icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply

次の TCP フラグフィールド値が利用可能です。 tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg

プリミティブは、以下のように組み合わせることが可能です。

括弧で括られた一連のプリミティブや演算子 (括弧はシェルの特殊文字なのでエスケープする必要があります)。

否定 (`!' 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[tcpflags] & (tcp-syn|tcp-fin) != 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[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

索引

出力形式

tcpdump の出力は、プロトコル依存です。以下の説明では、簡単な パラメータの記述と、おおよそのフォーマットの説明を行ないます。

リンクレベルヘッダ

もし '-e' オプションが指定されると、リンクレベルヘッダが出力されます。 イーサネットにおいては、始点と終点のアドレス、プロトコル、そして パケット長が出力されます。

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

Token Ring ネットワークでは、'-e' オプションを指定すると、tcpdump は、 アクセス制御」と「フレーム制御」のフィールド、 始点と終点のアドレス、パケット長を表示します。 FDDI ネットワークでは、パケットは LLC パケットを含むと仮定されます。 オプション '-e' の指定の有無にかかわらず、 始点経路制御されたパケットに対しては、始点経路制御情報が表示されます。

802.11 ネットワークでは、'-e' オプションが指定されると、 「フレーム制御」フィールド、802.11 ヘッダに含まれるすべてのアドレス、 そしてパケット長を出力します。 FDDI ネットワークと同様に、パケットには 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 or -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

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

TCP パケット

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

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

src > dst: flags data-seqno ack window urgent options

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

csam は、rtsg から送られたパケットと類似したパケットを送り返しますが、 rtsg の送った SYN に対する ack が含まれるところが異なり ます。続いて、rtsg は csam の SYN に対する ack を返します。 `.' は、S (SYN), F (FIN), P (PUSH), R (RST) のいずれのフラグも 立っていないことを意味します。 パケットはデータを含まないため、データシーケンス番号は入りません。 ack シーケンス番号が小さい整数 (1) であることに注意して下さい。 tcpdump は、初めて TCP の「通信」を検出すると、パケットから取得した シーケンス番号を表示します。通信のその後のパケットについては、現在の パケットシーケンス番号と、この最初のシーケンス番号の間の差を表示します。 このことは、最初に取得した以降のシーケンス番号は、通信データストリーム の相対位置として解釈できることを意味します (最初の各方向のデータバイト は 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 バイトデータを送信しています。

スナップショットが小さ過ぎて tcpdump が TCP ヘッダ全体を捕えなかった場合、 可能な限りのヘッダを解釈し、``[|tcp]'' を表示して 残りを解釈できなかったことを示します。 (短か過ぎるまたはヘッダを越えてしまうといった) 不正なオプションを ヘッダが持つ場合には、tcpdump は ``[bad opt]'' を表示して 残りのオプションを解釈しません (どこから開始したら良いのか分からないからです)。 ヘッダ長によりオプションが存在することが分かるが、 IP データグラム長がオプションがそこにあるために十分な長さではない場合に、 tcpdump は ``[bad hdr length]'' を表示します。

特定フラグの組み合わせ (SYN-ACK, URG-ACK 等) による TCP パケットの捕捉

TCP ヘッダの制御ビットセクションには、次の 8 ビットがあります:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

TCP 接続の確立に使用されるパケットを見たいものとしましょう。 新規接続を初期化する時、 TCP は 3 ウェイハンドシェークプロトコルを使用することを思い出してください。 TCP 制御ビットに関する接続の順番は次のようになります。

1) 呼び出し側が SYN を送信

2) 受信者が SYN, ACK で応答

3) 呼び出し側が ACK を送信

ここで、SYN ビットを持つパケットを捕捉したいとします (第 1 ステップ)。 ステップ 2 のパケット (SYN-ACK) は不要で、 最初の SYN だけが欲しいことに注意してください。 必要なのは、tcpdump の正しいフィルタ式です。

オプション無しの TCP ヘッダの構造を思い出してください:

 0                            15                              31
-----------------------------------------------------------------
|          始点ポート           |       終点ポート              |
-----------------------------------------------------------------
|                        シーケンス番号                         |
-----------------------------------------------------------------
|                         確認応答番号                          |
-----------------------------------------------------------------
|  HL   | 予約  |C|E|U|A|P|R|S|F|        ウィンドウサイズ       |
-----------------------------------------------------------------
|         TCP チェックサム      |          緊急ポインタ         |
-----------------------------------------------------------------

TCP ヘッダは、オプションが無ければ通常、20 オクテットのデータを持ちます。 図の最初の行はオクテット 0 から 3 を示し、 次の行はオクテット 4 から 7 を示す等となります。

0 から数え始めると、必要な TCP 制御ビットはオクテット 13 にあります:

 0             7|             15|             23|             31
----------------|---------------|---------------|----------------
|  HL   | 予約  |C|E|U|A|P|R|S|F|        ウィンドウサイズ       |
----------------|---------------|---------------|----------------
|               |13 オクテット目|               |               |

第 13 オクテットをもっとよく見てみましょう:

                |               |
                |---------------|
                |C|E|U|A|P|R|S|F|
                |---------------|
                |7   5   3     0|

これらは我々が興味がある TCP 制御ビットです。 このオクテットのビットを、右から左へ、0 から 7 と番号付けします。 PSH ビットは第 3 ビットであり、URG ビットは第 5 ビットです。

最初の SYN だけを持つパケットが欲しいことに注意してください。 SYN ビットがセットされた TCP データグラムが到着すると、 第 13 オクテットになにが起きるか見てみましょう:

                |C|E|U|A|P|R|S|F|
                |---------------|
                |0 0 0 0 0 0 1 0|
                |---------------|
                |7 6 5 4 3 2 1 0|

制御ビットセクションを見ると、ビット番号 1 (SYN) のみがセットされています。

オクテット番号 13 が、ネットワークバイト順で、 8 ビット符号無し整数と仮定します。 このオクテットの 2 進数値は

00000010

となり、10 進数での表現は次のようになります:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2

SYN のみセットされている場合について理解したので、これでほとんど終りです。 TCP ヘッダの第 13 オクテットの値は、 ネットワークバイト順の 8 ビット符号無し整数として解釈すると、 正確に 2 となります。

この関係は次のように表現可能です:

tcp[13] == 2

この式を tcpdump のフィルタとして使用し、 SYN パケットのみを持つパケットを捕捉可能です:

tcpdump -i xl0 tcp[13] == 2

この式は「TCP データグラムの第 13 オクテットは 10 進数 2 を持つ」 と言っており、まさに我々が望むものです。

次に、SYN パケットが必要であるが、ACK や他の TCP 制御ビットについては どうでも良い場合を考えます。 SYN-ACK が設定された TCP データグラムが到着した時に オクテット 13 がどうなっているかを見てみましょう:

     |C|E|U|A|P|R|S|F|
     |---------------|
     |0 0 0 1 0 0 1 0|
     |---------------|
     |7 6 5 4 3 2 1 0|

今度は、第 13 オクテットの第 1 ビットと第 4 ビットがセットされています。 第 13 オクテットの 2 進数値は

     00010010

となり、10 進数では次のようになります:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18

今度は、tcpdump フィルタ式に 'tcp[13] == 18' を使用できません。 この式は、SYN-ACK がセットされているパケットのみを選択し、 SYN のみセットされているパケットを選択しないからです。 ACK や他の制御ビットがセットされていようといまいと構わないことを 思い出してください。

この目的を達成するために、第 13 オクテットと他の値との論理 AND を取り、 SYN ビットを得ることが必要です。 我々が欲しいのはどんな場合でも SYN がセットされていれば良いので、 第 13 オクテットと SYN の 2 進数値との論理 AND を取ります:

          00010010 SYN-ACK              00000010 SYN
     AND  00000010 (SYN が欲しい)  AND  00000010 (SYN が欲しい)
          --------                      --------
     =    00000010                 =    00000010

この AND 操作は、ACK や他の TCP プロトコルビットが セットされていようといまいと、結果は同じです。 AND 用の値の 10 進数表現と、この操作の結果の 10 進数値は、 共に 2 (2 進数値 00000010) であり、 SYN がセットされているパケットには次の関係が成立します:

( ( 第 13 オクテットの値 ) AND ( 2 ) ) == ( 2 )

ここで、tcpdump フィルタ式は次のようになることが分かります:

     tcpdump -i xl0 'tcp[13] & 2 == 2'

シングルクォートもしくはバックスラッシュを使用して、AND (&') 特殊文字を シェルから隠す必要があることに注意してください。

UDP パケット

UDP フォーマットは、以下の rwho パケットで例示します。

actinide.who > broadcast.who: udp 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)

少数の変則的なパケットは検査され、カギカッコで囲まれた付加 フィールドにその結果が表示されます。問い合わせに返答が あったとき、オーソリティレコードもしくは追加レコードのセクション 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)

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

出力される可能性のある他のフラグキャラクタは、`-' (再帰利用,RA,が 設定されていない)および `|' (メッセージ切捨て, TC, が設定されている) です。 `question' セクションに含まれるエントリがちょうど 1 つでない場合には、 `[nq]' が出力されます。

ネームサーバ要求および応答は、大きくなる傾向にあり、デフォルトの snaplen の値である 68 バイトの長さは、パケットを捕捉してその内容を 表示するには十分でないかも知れないことに注意して下さい。 もしネームサーバトラフィックの調査を真剣に 行なおうとするならば、-s オプションを用いて、snaplen を増やし て下さい。自分の経験上、`-s 128' で十分使い物になります。

SMB/CIFS のデコード

現在の tcpdump は、UDP/137, UDP/138, TCP/139 上のデータ用に、 非常に多くの SMB/CIFS/NBT デコードを含みます。 IPX および NetBEUI SMB データの原始的なデコードも、 いくらかは実装されています。

デフォルトでは、最小限のデコードが行われ、 より詳細なデコードは -v を指定すると行われます。 -v を使用すると、単一の SMB パケットが 1 ページ以上を占めてしまいますので、 血まみれの詳細すべてが本当に欲しい場合のみに -v を使用すべきことを 注意してください。

UNICODE 文字列を含む SMB セッションをデコードする場合、 環境変数 USE_UNICODE を 1 に設定するとよいかもしれません。 UNICODE 文字列を自動検出するパッチを歓迎します。

SMB パケット書式の情報とすべてのフィールドの意味については、 www.cifs.org または好きな samba.org ミラーサイトの pub/samba/specs/ ディレクトリを見てください。 SMB パッチは Andrew Tridgell (tridge@samba.org) が書きました。

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

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 フラグが 2 回以上指定されると、さらに詳しい情報が出力されます。

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

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

AFS の要求と応答

Transarc AFS (Andrew File System) の要求と応答は次のように表示されます:

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args


elvis.7001 > pike.afsfs:
        rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
        new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename

一般的には、AFS RPC の RPC 呼び出し名だけは最低限デコードされます。 ほとんどの AFS RPC は、少なくともいくらかの引数がデコードされます (一般的には「興味のある」引数のみであり、興味についてはある定義によります)。

書式は、自明となることを意図していますが、 AFS および RX の動作に親しみのない方々にとっては有用ではないかもしれません。

-v (冗長) フラグを 2 度指定すると、 確認応答パケットと追加のヘッダ情報を表示します。 これは、RX 呼び出し ID、呼び出し番号、シーケンス番号、 シリアル番号、RX パケットフラグといったものです。

-v フラグを 2 度指定すると、追加情報が表示されます。 これは、RX 呼び出し ID、呼び出し番号、RX パケットフラグといったものです。 MTU ネゴシエーション情報も、RX 確認応答パケットから表示されます。

-v フラグを 3 度指定すると、 セキュリティインデックスとサービス ID を表示します。

アボートパケットに対しては、エラーコードが表示されます。 ただし、Ubik ビーコンパケットは例外です (Ubik プロトコルでは、アボートパケットは、肯定投票に使用されるからです)。

AFS 要求は非常に大きく、 snaplen を増やさなければ多くの引数が表示されないことに注意してください。 AFS トラフィックを見るには `-s 256' を試してみてください。

AFS 応答パケットは、明示的には RPC 操作を識別しません。 代りに tcpdump が「最近の」要求の追跡を行い、 応答に対応する要求のマッチングを、 呼び出し番号とサービス ID を使用して行います。 応答パケットが対応する要求パケットに近くないと、 パーズできないかもしれません。

KIP AppleTalk (DDP in UDP)

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

number  name

1.254           ether
16.1            icsd-net
1.254.110       ace

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

net.host.port

144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

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

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

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)

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

フラグメント不可フラグが設定されたパケットは、最後の部分に (DF) と 印が付けられます。

タイムスタンプ

デフォルトでは、すべての出力行は最初にタイムスタンプが出力されます。 タイムスタンプは、以下の形式で、現在のクロックタイムを表示します

hh:mm:ss.frac

索引

関連項目

索引

作者

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

現在は tcpdump.org で管理されています。

現在のバージョンは http で次のところから取得可能です:

http://www.tcpdump.org/

元々の配布は匿名 ftp で次のところから取得可能です:

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

IPv6/IPsec サポートは WIDE/KAME プロジェクトが追加しました。 本プログラムは、特定の構成においては、 Eric Young の SSLeay ライブラリを使用します。  

索引

バグ

tcpdump-workers@tcpdump.org

ソースコードの寄贈等については次のところに送ってください:

patches@tcpdump.org

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

2.0[.x] カーネルの Linux システムにおいて:

ループバックデバイス上のパケットは 2 度観測されます。

カーネル内でのパケットフィルタリングは不可能であり、 全パケットがカーネルからコピーされてユーザモードでフィルタされます。

スナップショットの長さ部分ではなく、パケット全体が、 カーネルからコピーされます (2.0[.x] のパケット捕捉機構は、 パケットの一部をユーザランドへコピーするように依頼されると、 パケットの正しい長さを報告しません。 このため、ほとんどの IP パケットが tcpdump でエラーとなってしまいます)。

いくつかの PPP デバイス上での捕捉は、正しく動作しません。

2.2 以降のカーネルにアップグレードすることをお勧めします。

IP フラグメントを再構成するか、もしくは少なくとも上位プロトコルの正し いデータサイズを計算するように設計しなおす必要があります。

ネームサーバについての逆引きについては、正しくダンプされません。 実際の要求ではなく、(empty) クエスチョンセクションが、 アンサーセクションに出力されます。 逆引きについてはそれ自体がバグであると信じ、 tcpdump ではなく逆引きを要求する プログラムを修正するべきと考える人達もいます。

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

Token Ring ヘッダ以外のフィールドに対するフィルタ式は、 始点経路制御された Token Ring パケットを正しく扱いません。

802.11 ヘッダ以外のフィールドに対するフィルタ式は、'To DS' と 'From DS' の 両方をもつ 802.11 データパケットを正しく扱いません。

ip6 proto はヘッダチェーンを追跡すべきですが、現在のところはそうなっていません。 このために ip6 protochain が提供されています。

例えば tcp[0] といったトランスポート層ヘッダに対する演算は、 IPv6 パケットに対しては動作しません。 IPv4 パケットだけを見ます。

索引

Index

名称

書式

解説

オプション

使用例

出力形式

関連項目

作者

バグ