日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.2-RELEASE-K, 8.0-RELEASE-K は、プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.2-RELEASE-K, 8.0-RELEASE-K は、全翻訳済み)
6.4-STABLE-K, 7.2-STABLE-K, 8.0-STABLE-K は現在、 作成中で日々更新されています。 最新の snapshots を元に作成しています。
TCPDUMP(1) TCPDUMP(1)
名称
tcpdump - ネットワーク上のトラフィックデータのダンプ
書式
tcpdump [ -adeflLnNOpqRStuvxX ] [ -c count ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ]
[ -E algo:secret ] [ -y datalinktype ]
[ expression ]
解説
tcpdump は、オプションで指定されたネットワークインタフェース上で取得可
能なパケットのヘッダのうち expression にマッチするものを出力します。 パ
ケッ トデータを後で分析するためファイルに保存するよう、 -w フラグで実行
することもできます。また、 -r フラグで、ネットワークインタフェースか ら
の パケットではなく、ファイルに保存されたパケットから読み込むことができ
ます。すべての場合に、 expression にマッチするパケットだけ、 tcpdump に
よって処理されます。
tcpdump は、 -c フラグで実行しない場合、SIGINT シグナル ( 例えば、一般
的な手法として割り込み文字列である control-C の入力) か SIGTERM シグ ナ
ル (一般的な手法として kill(1) コマンド) によって割り込みがあるまで、パ
ケットを捕捉し続けます。 -c フラグで実行する場合は、 SIGINT シグナル や
SIGTERM シ グナルで割り込みされるか、指定されたパケット数まで処理しま
す。
tcpdump がパケットの捕捉を終了したとき、以下の合計を表示します。
packets ``received by filter'' (この意味は、 tcpdump を実行し て
いる OS に依存しますし、おそらく OS のコンフィギュレーション方法
にも依存するでしょう。 filter がコマンドラインで指定された場合、
あ る OS ではそれが filter expression によって一致したかどうかに
関わらず、パケットを数えます。また別の OS で は、filter expres
sion によって一致した場合のみ tcpdump によって処理されたパケット
だけを数えます。)
packets ``dropped by kernel'' (OS がアプリケーションにその情報を
報 告する場合には、バッファスペースの不足により、 tcpdump が走っ
ている OS のパケットキャプチャ制御機構から、落ちてしまったパケッ
トの数です。それ以外の場合には、0 が表示されます。)
大 抵の BSD のような SIGINFO シグナルがサポートされているプラットホーム
では、SIGINFO シグナル (例えば、一般的な手法として ``状態'' 文字列で あ
る control-T の入力) を受信したとき、それらの合計を表示して、パケットの
捕捉を引き続き行います。
ネットワークインタフェースからパケットを読むには、権限を必要とします。
SunOS 3.x、4.x 上の NIT ないし BPF の場合:
/dev/nit ないし /dev/bpf* への読み込みアクセス権が必要です。
Solaris 上の DLPI の場合:
/dev/le 等のネットワーク仮想デバイスへの読み書きアクセス権が必要
で す。少なくとも Solaris のいくつかのバージョン上では、 tcpdump
が promiscuous-mode で捕捉するには、この条件だけでは不十分です。
それらの Solaris のバージョンでは、root になる必要があります。も
しくは promiscuous-mode で捕捉するには root に setuid されてイン
ストールされている場合のみ tcpdump の実行が可能になります。
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 で指定した数のパケットを受信した後に終了します。
-C 保 存 ファ イ ルに raw パケットを書き込む前に、現在のファイルが
file_size より大きいかどうかをチェックします。もし大きいなら、現
在の保存ファイルを閉じて新しいものを開きます。付けられるファイル
名は、最初の保存ファイルを除く 2 番目以降の保存ファイルか ら -w
フラグで指定されたファイル名の後にそれぞれ番号がつきます。その番
号は、2 から始まり順に大きくなります。 file_size の単位は 100 万
バイト (1,000,000 バイト。1,048,576 バイトのことではない) です。
-d 解釈されたパケットマッチングコードを読みやすい形に整形した後、標
準出力にダンプして停止します。
-dd C プログラムの断片の形でパケットマッチングコードをダンプします。
-ddd (先頭に個数を付加した) 十進数の形でパケットマッチングコードを ダ
ンプします。
-e 各ダンプ行ごとに、リンクレベルのヘッダを出力します。
-E algo:secret を、IPsec ESP パケットの解読に使用します。アルゴリズ
ムは des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, none
の いずれかです。デフォルトは des-cbc です。パケット解読能力は、
tcpdump が暗号機能付きでコンパイルされた場合のみ存 在 し ま す。
secret は、ESP 秘密鍵の ASCII テキストです。現状、任意の 2 進数
値を使用できません。本 オ プ ショ ン は、RFC1827 ESP で は な
く、RFC2406 ESP を仮定します。本オプションは、デバッグ専用であ
り、本当の「秘密」鍵に対する使用は勧められません。 IPset 秘密 鍵
を コマンドラインに置くと、 ps(1) 等によって他者に見えてしまいま
す。
-f 外部ホストの IPv4 アドレスについては、シンボルでなく数値で表示し
ま す。 (本オプションは、Sun の NIS サーバに重大な障害が発生する
のを回避することを意図しています。-- 通常は、Sun の yp サー バ
は、ローカルに存在しない IP アドレスを永久に変換しつづけてハング
します。)
-F フィルタの表現として、file に記述してある内容を用います。コマ ン
ドラインで指定された追加表現は、無視されます。
-i interface で指定されたインタフェースを監視します。指定されない場
合には、tcpdump はシステムインタフェースリストの中で最も小さい番
号の稼働中のものを検索し、監視するインタフェースとして設定します
(ループバックインタフェースは検索しません)。この動作は、最初にイ
ンタフェースが選択された時点で終了します。
2.2 以降のカーネルの Linux システムでは、 interface 引数 ``any''
を指定して全インタフェースからのパケットを捕捉可能です。 ``any''
デ バイスでの捕捉は、promiscuous-mode ではないことに注意してくだ
さい。
-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 で指定され
たタイプと解釈します。有効なタイプは、 cnfp (Cisco NetFlow プ ロ
ト コル), rpc (リモートプロシージャコール) rtp (リアルタイムアプ
リケーションプロトコル) rtcp (リアルタイムアプリケーション制御プ
ロ ト コ ル) snmp (シンプルネットワークマネージメントプロトコル)
vat (ビジュアルオーディオツール) wb (ディストリビューテッドホ ワ
イトボード) です。
-t 各ダンプ行のタイムスタンプを出力しません。
-tt 各ダンプ行毎にタイムスタンプを人間が読みやすい形に変換せずに出力
します。
-ttt 直前のダンプ行と現在のダンプ行の差分 (マイクロ秒単位) を表示しま
す。
-tttt 各ダンプ行で、デフォルト書式でタイムスタンプを表示し、その前に日
付を付けます。
-u デコードされてない NFS 操作を出力します。
-v (少しではありますが) 出力情報を増やします。例えば、IP パケット中
の TTL、識別、全長、IP パケット中のオプションが表示されます。追
加のパケットの完全性確認が有効になります。これは例えば IP および
ICMP のヘッダのチェックサムです。
-vv さ らに多くの情報を出力します。例えば、NFS の返答パケットの追加
フィールドや完全にデコードされた SMB パケットを出力します。
-vvv もっと多くの情報を出力します。例えば、telnet SB ... SE オプ ショ
ン が完全に表示されます。 -X 付きでは、telnet オプションが 16 進
数で表示されます。
-w 受信した生パケットを、解析したり画面に出力したりせずに file で指
定したファイルに出力します。本オプションを用いて取得したパケット
は -r オプションを用いることで情報を見ることができます。file で
指定するファイル名が ``-'' の場合には、標準出力を用います。
-x リンクレベルヘッダを除いた各パケットの内容を 16 進出力します。パ
ケットサイズが snaplen バイトより小さい場合にはパケットの全部 の
内 容を、それ以外の場合には、 snaplen バイト分のデータをパケット
ごとに出力します。
-X 16 進出力時に、ASCII もまた表示します。 -x もまた指定される と、
パ ケットが 16 進数と ASCII の組み合わせで表示されます。新規プロ
トコルを解析するのに非常に便利です。 -x が指定されないと、一部の
パケットの一部が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 が指定されたものとみなし
ます。 `null' リンクレイヤ (つまり、slip などポイ ン ト・
トゥ・ ポイント・プロトコル) では、必要な方向を指定するの
に inbound や outbound 限定子を用いる事ができます。
プロトコル
限定子は、特定のプロトコルに一致するパケットのみに制限 し
ます。プロトコルとして指定可能なものは、 ether, fddi, tr,
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' は `ether' の別名です。直前の段落における FDDI ヘッ
ダに関する記述は、 Token Ring ヘッダにも適用されます。]
上記に追加して、いくつかの特別な「プリミティブ」キーワードがあり
ま す。これらのキーワードは 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-Ether
net-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
パ ケットが IP ブロードキャストパケットの場合に、真となり
ます。オール 1 とオール 0 の二つの形式のブロードキャス ト
ア ドレスを検査し、そしてローカルサブネットマスクを調べま
す。
ether multicast
パケットがイーサネットマルチキャストパケットの場合に、 真
となります。 ether キーワードは、省略可能です。なお、この
指定は、`ether[0] & 1 != 0' の短縮系です。
ip multicast
パケットが IP マルチキャストパケットの場合に、真となり ま
す。
ip6 multicast
パ ケットが IPv6 マルチキャストパケットの場合に、真となり
ます。
ether proto protocol
パケットが protocol で指定した ether 型の場合に、真になり
ま す。 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') 、これらのほとんどのプロトコル の 場
合、 プ ロトコルの識別は IEEE802.2 の論理リンク制御 (LLC)
ヘッダによって行われます。通常これは FDDI ヘッダや Token
Ring ヘッダの上の層にあります。
FDDI または Token Ring のほとんどのプロトコル識別をフィル
タリングするとき、tcpdump は Ethernet をカプセル化する た
め に LLC ヘッダのプロトコル ID 範囲のみ、いわゆる SNAP
フォーマットである管理組織識別子 (OUI) の 0x000000 の範囲
の みをチェックします。パケットが SNAP フォーマットである
OUI の 0x000000 にあるかどうかはチェックしません。
例外は以下の通りです。 iso は LLC ヘッダの DSAP (Destina
tion Service Access Point) と SSAP (Source Service Access
Point) の範囲もチェックしま す。 stp お よ び netbeui
は、LLC ヘッダの DSAP をチェックします。 atalk は、 SNAP
フォーマットである OUI の 0x080007 と、Appletalk etype に
対してチェックします。
Ethernet の場合、tcpdump は、これらのプロトコルのほとんど
に対して Ethernet 型の範囲をチェックします。例外は以下 の
通りです。 iso、sap および netbeui では FDDI および Token
Ring の場合と同様に 802.3 フレームをチェックし、次に LLC
ヘッ ダ を チェッ クします。 atalk では FDDI および Token
Ring の場合と同様に Ethernet フレー ム 内 の Appletalk
etype お よ び SNAP フォーマットパケットの両方に対して
チェックします。 aarp では Ethernet フレームまたは 802.3
SNAP フ レームである OUI の 0x000000 と、 Appletalk ARP
etype に対してチェックします。そして、ipx で は、Ethernet
フ レー ム 内 の IPX etype、 LCC ヘッダ内の IPX DSAP、LCC
ヘッダが IPX でカプセル化されていない 802.2 およ び SNAP
フレーム内の IPX etype をチェックします。 ]
decnet src host
DECNET パケットの始点アドレスが host の場合に、真となりま
す。これは ``10.123'' という形式のアドレスでも DECNET の
ホ スト名でも構いません。[DECNET のホスト名は DECNET を動
かすように設定された Ultrix システムのみでサポートされ ま
す。]
decnet dst host
DECNET パケットの終点アドレスが host の場合に、真となりま
す。
decnet host host
DECNET パケットの始点あるいは終点アドレスが host の 場 合
に、真となります。
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 の部分には、上記のいずれかのプロトコル 名
が入ります。 tcpdump はこれらのプロトコルを完全には解釈で
きない事に注意してください。
expr relop expr
relopは、>, <, >=, <=, =, != のいずれかであり、expr の 部
分 には、(標準 C 言語の構文で表現された) 整数定数や通常の
二項演算子 [+, -, *, /, &, |]、length 演算子、そして特 殊
な パケットデータへのアクセス演算子などからなる算術表現が
入って、その関係が成立する場合に、真となります。パケッ ト
内 部 の データにアクセスするためには、以下の構文を用いま
す。
proto [ expr : size ]
protoは、ether, fddi, tr, ip, arp, rarp, tcp, udp, icmp,
ip6 のいずれかであり、インデックス操作を行うプロトコル層
を指示します。 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 タイプフィールド)、icm-
pcode (ICMP コードフィールド) および tcpflags (TCP フラグ
フィールド)
次の ICMP タイプフィールド値が利用可能です。 icmp-echore-
ply, 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-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' の指定の有無にかかわらず、始点経 路
制御されたパケットに対しては、始点経路制御情報が表示されます。
(注意: 以下の記述は、利用者が 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
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 プロトコルについての知
識があることを前提に記述されています。この知識がない場合、本記述と tcp-
dump のいずれもあなたには役に立たないでしょう。)
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 は、例えば <mss 1024> の よ う
に、アングルブラケット (大小記号) で括られた tcp オプションです。
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 バイトであり、1024 バイ
トの最大セグメントサイズ要求を行なうオプションが付加されています。
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 デー
タグラム長がオプションがそこにあるために十分な長さではない場合に、 tcp-
dump は ``[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
これは、ホスト 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.berke-
ley.edu のホスト名に対応するアドレスレコード (qtype=A) を問い合わせてい
ます。問い合わせの ID は `3' であり、`+' は再帰要求フラグが設定されてい
ることを意味します。問い合わせの長さは 37 バイトであり、この中に UDP お
よび IP のプロトコルヘッダの長さは含みません。質問操作は 普 通 の 操 作
(Query) であり、op フィールドは省略されます。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 バイトです。 A レコード
のクラス (C_IN) と同様に, op (Query) および応答コード (NoError) は、 省
略されます。
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
最 初の行では、ホスト sushi が ID6709 のトランザクションを wrl に送信し
ます (始点ホストに続く数字はトランザクション ID であり、始点ポート番 号
でないことに注意して下さい)。要求サイズは、UDP および IP ヘッダのサイズ
を除いて 112 バ イ ト で す。 操 作 は、 ファ イ ル ハ ン ド ル (fh)
21,24/10.731657119 に 対する readlink (シンボリックリンク読み込み) で
す。 (この例のように運が良ければ、ファイルハンドル は デ バ イ ス の メ
ジャー、マイナー番号のペアと、それに続く inode 番号と世代番号と解釈する
ことができます。) 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 フラグが 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
最初の行では、ホスト elvis が RX パケットを pike に送っています。 こ れ
は、fs (ファイルサーバ) サービスへの RX データパケットであり、 RPC 呼び
出しの開始です。この RPC 呼び出しはリネーム (改名) であり、古いディレク
ト リ ファ イル ID 536876964/1/1 と古いファイル名 `.newsrc.new'、新しい
ディレクトリファイル ID 536876964/1/1 と新しいファイル名 `.newsrc' で呼
び 出しています。ホスト pike は、RPC 応答をリネーム呼び出しに対して返し
ます (データパケットであり、アボートパケットではないため、これは成功 し
ました)。
一般的には、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
最初の 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 を開 い
て いる何者かにデータを送信しています。次の行は、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
最初の行は、レーザライタの名前検索要求であり、ネットワーク icsd のホ ス
ト 112 から送られ、ネットワーク jssmag へとブロードキャストされていま
す。検索のための nbp の ID は 190 です。次の行は jssmag.209 からの、 こ
の 要求の応答 (同じ ID を持つことに注意して下さい) で、 ポート 250 に登
録された RM1140 という名前のレーザライタがあると答えています。 3 行 め
は、 同 じ要求に対する他のホストからの応答で、ホスト techpit が、ポート
186 に登録されたレーザライタ "techpit" を持っていると答えています。
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 進
数は、要求の中の「ユーザデータ」のフィールドの値です。
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 行目はポート番号を含 み
ま せん。これは、TCP プロトコル情報は、最初のフラグメントに全て入ってお
り、後のフラグメントを出力する時にはポート番号やシーケンス番号を知る 術
が な いからです。次に、最初の行の TCP シーケンス情報は、パケットが 308
バイトのユーザデータを持ってるかのように表示されますが、実際には 512 バ
イ トのユーザデータを持っています (308 バイトが最初のフラグ分で、204 バ
イトが 2 番目のフラグ分です)。シーケンススペースの穴をさがし た り、 パ
ケットの ack の対応が正しいかをこのデータで見ようとしてはいけません。
フ ラグメント不可フラグが設定されたパケットは、最後の部分に (DF) と印が
付けられます。
タイムスタンプ
デフォルトでは、すべての出力行は最初にタイムスタンプが出力されます。 タ
イムスタンプは、以下の形式で、現在のクロックタイムを表示します
hh:mm:ss.frac
そ して、クロックの精度は、カーネルクロックの精度に依存します。タイムス
タンプは、カーネルが最初にパケットを見つけた時間を反映しま す。 イー サ
ネッ トインタフェースがケーブルからパケットを取り出してカーネルが「新規
パケット」割り込みを受け付けるまでのタイムラグなどは補正されません
関連項目
bpf(4), pcap(3)
作者
元々の作者は次の通りです:
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 で エ
ラーとなってしまいます)。
2.2 以降のカーネルにアップグレードすることをお勧めします。
IP フラグメントを再構成するか、もしくは少なくとも上位プロトコルの正しい
データサイズを計算するように設計しなおす必要があります。
ネームサーバについての逆引きについては、正しくダンプされません。実際 の
要 求ではなく、(empty) クエスチョンセクションが、アンサーセクションに出
力されます。逆引きについてはそれ自体がバグであると信じ、 tcpdump ではな
く逆引きを要求するプログラムを修正するべきと考える人達もいます。
夏 時間との変更の時にパケットトレースを行うと、タイムスタンプは変更後の
時刻とはずれてしまいます (時間変化は無視されます)。
FDDI ヘッダおよび Token Ring ヘッダを操作するようなフィルタの表現におい
て は、全ての FDDI パケットおよび Token Ring パケットは SNAP でカプセル
化された Ethernet パケットであると仮定します。これは、IP, ARP, DECNET
フェーズ 4 については正しいですが、ISO の CLNS 等のプロトコルについては
正しくありません。したがって、フィルタ表現に正しくマッチしないような パ
ケットを偶然に受け入れてしまうことがあります。
Token Ring ヘッダ以外のフィールドに対するフィルタ式は、始点経路制御され
た Token Ring パケットを正しく扱わないことがあります。
ip6 proto はヘッダチェーンを追跡すべきですが、現在のところはそうなっ て
いません。このために ip6 protochain が提供されています。
例 え ば tcp[0] といったトランスポート層ヘッダに対する演算は、 IPv6 パ
ケットに対しては動作しません。 IPv4 パケットだけを見ます。
3 January 2001 TCPDUMP(1)