1938 lines
65 KiB
Groff
1938 lines
65 KiB
Groff
.\" @(#) $Header: /home/ncvs/doc/ja_JP.eucJP/man/man1/tcpdump.1,v 1.18 2002-08-26 00:59:14 horikawa Exp $ (LBL)
|
||
.\"
|
||
.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
|
||
.\" The Regents of the University of California. All rights reserved.
|
||
.\" All rights reserved.
|
||
.\"
|
||
.\" Redistribution and use in source and binary forms, with or without
|
||
.\" modification, are permitted provided that: (1) source code distributions
|
||
.\" retain the above copyright notice and this paragraph in its entirety, (2)
|
||
.\" distributions including binary code include the above copyright notice and
|
||
.\" this paragraph in its entirety in the documentation or other materials
|
||
.\" provided with the distribution, and (3) all advertising materials mentioning
|
||
.\" features or use of this software display the following acknowledgement:
|
||
.\" ``This product includes software developed by the University of California,
|
||
.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
|
||
.\" the University nor the names of its contributors may be used to endorse
|
||
.\" or promote products derived from this software without specific prior
|
||
.\" written permission.
|
||
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
||
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
||
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
||
.\"
|
||
.\" %FreeBSD: src/contrib/tcpdump/tcpdump.1,v 1.8.2.2 2002/07/05 11:29:59 fenner Exp %
|
||
.\"
|
||
.\" $FreeBSD$
|
||
.\"
|
||
.\"
|
||
.TH TCPDUMP 1 "3 January 2001"
|
||
.SH 名称
|
||
tcpdump \- ネットワーク上のトラフィックデータのダンプ
|
||
.SH 書式
|
||
.na
|
||
.B tcpdump
|
||
[
|
||
.B \-adeflnNOpqRStuvxX
|
||
] [
|
||
.B \-c
|
||
.I count
|
||
]
|
||
.br
|
||
.ti +8
|
||
[
|
||
.B \-C
|
||
.I file_size
|
||
] [
|
||
.B \-F
|
||
.I file
|
||
]
|
||
.br
|
||
.ti +8
|
||
[
|
||
.B \-i
|
||
.I interface
|
||
]
|
||
[
|
||
.B \-m
|
||
.I module
|
||
]
|
||
[
|
||
.B \-r
|
||
.I file
|
||
]
|
||
.br
|
||
.ti +8
|
||
[
|
||
.B \-s
|
||
.I snaplen
|
||
]
|
||
[
|
||
.B \-T
|
||
.I type
|
||
]
|
||
[
|
||
.B \-w
|
||
.I file
|
||
]
|
||
.br
|
||
.ti +8
|
||
[
|
||
.B \-E
|
||
.I algo:secret
|
||
]
|
||
[
|
||
.I expression
|
||
]
|
||
.br
|
||
.ad
|
||
.SH 解説
|
||
.LP
|
||
\fItcpdump\fP は、オプションで指定されたネットワークインタフェース上で
|
||
取得可能なパケットのヘッダのうち \fIexpression\fP にマッチするものを出力
|
||
します。
|
||
パケットデータを後で分析するためファイルに保存するよう、
|
||
.B \-w
|
||
フラグで実行することもできます。
|
||
また、
|
||
.B \-r
|
||
フラグで、ネットワークインタフェースからのパケットではなく、
|
||
ファイルに保存されたパケットから読み込むことができます。
|
||
すべての場合に、
|
||
.I expression
|
||
にマッチするパケットだけ、
|
||
.IR tcpdump
|
||
によって処理されます。
|
||
.LP
|
||
.I tcpdump
|
||
は、
|
||
.B \-c
|
||
フラグで実行しない場合、SIGINT シグナル (
|
||
例えば、一般的な手法として
|
||
割り込み文字列である control-C
|
||
の入力) か
|
||
SIGTERM シグナル (一般的な手法として
|
||
.BR kill (1)
|
||
コマンド)
|
||
によって割り込みがあるまで、パケットを捕捉し続けます。
|
||
.B \-c
|
||
フラグで実行する場合は、
|
||
SIGINT シグナル や SIGTERM シグナルで割り込みされるか、
|
||
指定されたパケット数まで処理します。
|
||
.LP
|
||
.I tcpdump
|
||
がパケットの捕捉を終了したとき、以下の合計を
|
||
表示します。
|
||
.IP
|
||
packets ``received by filter''
|
||
(この意味は、
|
||
.IR tcpdump
|
||
を実行している OS に依存しますし、
|
||
おそらく OS のコンフィギュレーション方法にも依存するでしょう。
|
||
filter がコマンドラインで指定された場合、ある OS では
|
||
それが filter expression によって一致したかどうかに関わらず、
|
||
パケットを数えます。
|
||
また別の OS では、filter expression によって一致した場合のみ
|
||
.IR tcpdump
|
||
によって処理されたパケットだけを数えます。)
|
||
.IP
|
||
packets ``dropped by kernel''
|
||
(OS がアプリケーションにその情報を報告する場合には、
|
||
バッファスペースの不足により、
|
||
.I tcpdump
|
||
が走っている OS の
|
||
パケットキャプチャ制御機構から、落ちてしまったパケット
|
||
の数です。
|
||
それ以外の場合には、0 が表示されます。)
|
||
.LP
|
||
大抵の BSD のような SIGINFO シグナルがサポートされている
|
||
プラットホームでは、SIGINFO シグナル
|
||
(例えば、一般的な手法として
|
||
``状態'' 文字列である control-T
|
||
の入力)
|
||
を受信したとき、それらの合計を表示して、パケットの捕捉を
|
||
引き続き行います。
|
||
.LP
|
||
ネットワークインタフェースからパケットを読むには、
|
||
権限を必要とします。
|
||
.TP
|
||
.B SunOS 3.x、4.x 上の NIT ないし BPF の場合:
|
||
.I /dev/nit
|
||
ないし
|
||
.IR /dev/bpf*
|
||
への読み込みアクセス権が必要です。
|
||
.TP
|
||
.B Solaris 上の DLPI の場合:
|
||
.IR /dev/le
|
||
等のネットワーク仮想デバイスへの読み書きアクセス権が必要です。
|
||
少なくとも Solaris のいくつかのバージョン上では、
|
||
.I tcpdump
|
||
が promiscuous-mode で捕捉するには、
|
||
この条件だけでは不十分です。
|
||
それらの Solaris のバージョンでは、root になる必要があります。
|
||
もしくは promiscuous-mode で捕捉するには root に
|
||
setuid されてインストールされている場合のみ
|
||
.I tcpdump
|
||
の実行が可能になります。
|
||
.TP
|
||
.B HP-UX 上の DLPI の場合:
|
||
使用者が root であるか、
|
||
.I tcpdump
|
||
が root に setuid されてインストールされている場合のみ実行可能です。
|
||
.TP
|
||
.B IRIX 上の snoop の場合:
|
||
使用者が root であるか、
|
||
.I tcpdump
|
||
が root に setuid されてインストールされている場合のみ実行可能です。
|
||
.TP
|
||
.B Linux の場合:
|
||
使用者が root であるか、
|
||
.I tcpdump
|
||
が root に setuid されてインストールされている場合のみ実行可能です。
|
||
.TP
|
||
.B Ultrix および Digital UNIX の場合:
|
||
スーパユーザが、
|
||
.IR pfconfig (8)
|
||
を用いて promiscuous-mode での操作を許可していれば、どのユーザも
|
||
.IR tcpdump .
|
||
を使って、ネットワークトラフィックを捕捉できてしまいます。
|
||
.TP
|
||
.B BSD の場合:
|
||
.IR /dev/bpf*
|
||
への読み込みアクセス権が必要です。
|
||
.LP
|
||
保存されたパケットファイルを読むには、権限を必要としません。
|
||
.SH オプション
|
||
.TP
|
||
.B \-a
|
||
ネットワークアドレスとブロードキャストアドレスを名前に変換しようとします。
|
||
.TP
|
||
.B \-c
|
||
\fIcount\fP で指定した数のパケットを受信した後に終了します。
|
||
.TP
|
||
.B \-C
|
||
保存ファイルに raw パケットを書き込む前に、
|
||
現在のファイルが \fIfile_size\fP より大きいかどうか
|
||
をチェックします。
|
||
もし大きいなら、現在の保存ファイルを閉じて新しいものを開きます。
|
||
付けられるファイル名は、最初の保存ファイルを除く
|
||
2 番目以降の保存ファイルから
|
||
.B \-w
|
||
フラグで指定されたファイル名の
|
||
後にそれぞれ番号がつきます。
|
||
その番号は、2 から始まり順に大きくなります。
|
||
\fIfile_size\fP の単位は 100 万バイト
|
||
(1,000,000 バイト。1,048,576 バイトの
|
||
ことではない) です。
|
||
.TP
|
||
.B \-d
|
||
解釈されたパケットマッチングコードを読みやすい形に整形した後、
|
||
標準出力にダンプして停止します。
|
||
.TP
|
||
.B \-dd
|
||
.B C
|
||
プログラムの断片の形でパケットマッチングコードをダンプします。
|
||
.TP
|
||
.B \-ddd
|
||
(先頭に個数を付加した) 十進数の形でパケットマッチングコードをダンプします。
|
||
.TP
|
||
.B \-e
|
||
各ダンプ行ごとに、リンクレベルのヘッダを出力します。
|
||
.TP
|
||
.B \-E
|
||
\fIalgo:secret\fP を、IPsec ESP パケットの解読に使用します。
|
||
アルゴリズムは
|
||
\fBdes-cbc\fP,
|
||
\fB3des-cbc\fP,
|
||
\fBblowfish-cbc\fP,
|
||
\fBrc3-cbc\fP,
|
||
\fBcast128-cbc\fP,
|
||
\fBnone\fP
|
||
のいずれかです。
|
||
デフォルトは \fBdes-cbc\fP です。
|
||
パケット解読能力は、
|
||
\fItcpdump\fP が暗号機能付きでコンパイルされた場合のみ存在します。
|
||
\fIsecret\fP は、ESP 秘密鍵の ASCII テキストです。
|
||
現状、任意の 2 進数値を使用できません。
|
||
本オプションは、RFC1827 ESP ではなく、RFC2406 ESP を仮定します。
|
||
本オプションは、デバッグ専用であり、
|
||
本当の「秘密」鍵に対する使用は勧められません。
|
||
IPset 秘密鍵をコマンドラインに置くと、
|
||
.IR ps (1)
|
||
等によって他者に見えてしまいます。
|
||
.TP
|
||
.B \-f
|
||
外部ホストの IP アドレスについては、シンボルでなく数値で表示します。
|
||
(本オプションは、Sun の yp サーバに重大な障害が発生するのを回避するこ
|
||
とを意図しています。\(em 通常は、Sun の yp サーバは、ローカルに存在しない
|
||
IP アドレスを永久に変換しつづけてハングします。)
|
||
.TP
|
||
.B \-F
|
||
フィルタの表現として、\fIfile\fP に記述してある内容を用います。
|
||
コマンドラインで指定された追加表現は、無視されます。
|
||
.TP
|
||
.B \-i
|
||
\fIinterface\fP で指定されたインタフェースを監視します。
|
||
指定されない場合には、\fItcpdump\fP はシステムインタフェースリストの中で
|
||
最も小さい番号の稼働中のものを検索し、監視するインタフェースとして設定
|
||
します (ループバックインタフェースは検索しません)。
|
||
この動作は、最初にインタフェースが選択された時点で終了します。
|
||
.IP
|
||
2.2 以降のカーネルの Linux システムでは、
|
||
.I interface
|
||
引数 ``any'' を指定して全インタフェースからのパケットを捕捉可能です。
|
||
``any'' デバイスでの捕捉は、promiscuous-mode ではないことに注意してください。
|
||
.TP
|
||
.B \-l
|
||
標準出力を行バッファリングにします。データを捕捉しつつ、
|
||
そのデータを見たい場合には、本オプションは有効です。例えば
|
||
.br
|
||
``tcpdump\ \ \-l\ \ |\ \ tee dat'' や
|
||
``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''
|
||
のように使用します。
|
||
.TP
|
||
.B \-m
|
||
SMI MIB モジュールの定義を、ファイル \fImodule\fR からロードします。
|
||
複数の MIB モジュールを \fItcpdump\fP にロードするために、
|
||
複数回このオプションを使用することができます。
|
||
.TP
|
||
.B \-n
|
||
アドレス (IP アドレスやポート番号など) を名前に変換しません。
|
||
.TP
|
||
.B \-N
|
||
ホスト名のうち、ドメイン名の表示をしません。例えば、本オプションを
|
||
指定すると、``nic.ddn.mil'' とは表示されず、かわりに ``nic'' とだけ表示し
|
||
ます。
|
||
.TP
|
||
.B \-O
|
||
パケットマッチングコードのオプティマイザを動かしません。本オプションは、
|
||
オプティマイザ中のバグを疑う場合にのみ有効なものです。
|
||
.TP
|
||
.B \-p
|
||
ネットワークインタフェースを、promiscuous mode に設定しません。
|
||
ネットワークインタフェースは、何らかの理由により promiscuous mode に設定
|
||
されることもあり得るということに注意してください。ゆえに `-p'
|
||
オプションは、`ether host {local-hw-addr} or ether broadcast'
|
||
の短縮形として使うことは出来ません。
|
||
.TP
|
||
.B \-q
|
||
素早い (静かな?) 出力を行ないます。出力する行を短くするために、通常出力
|
||
されるプロトコル情報の一部は出力されません。
|
||
.TP
|
||
.B \-R
|
||
ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に基いているものと仮定します。
|
||
指定すると、\fItcpdump\fP はリレー防止フィールドを表示しません。
|
||
ESP/AH 仕様にはプロトコルバージョンフィールドがありませんので、
|
||
\fItcpdump\fP は ESP/AH プロトコルのバージョンを推定できません。
|
||
.TP
|
||
.B \-r
|
||
パケットを、\fIfile\fR で指定したファイル (-w オプションで作成されます) か
|
||
ら読み込みます。\fIfile\fR として``-''が指定された場合は標準入力が用いら
|
||
れます。
|
||
.TP
|
||
.B \-S
|
||
TCP シーケンス番号を相対番号ではなく、絶対番号で出力します。
|
||
.TP
|
||
.B \-s
|
||
デフォルトの 68 バイト (SunOS の NIT では最小値は実際には 96) ではなくて、
|
||
\fIsnaplen\fP だけのデータを各パケットから取得します。68 バイトという
|
||
データ長は、IP, ICMP, TCP, UDP のパケットを取得する分には十分ですが、
|
||
ネームサーバや NFS のパケットについてはプロトコル情報が切り詰められるこ
|
||
とがあります (これについては、以後の説明を参照して下さい)。
|
||
スナップショットが限られた量しかとれずに切り
|
||
詰められたパケットは、出力に ``[|\fIproto\fP]'' という文字列がいっしょ
|
||
に表示されます。 \fIproto\fP は、切り詰めが行われたプロトコルレベルの名
|
||
前です。大きなスナップショットをとる場合には、それだけパケット処理の時
|
||
間がかかるということと、パケットバッファリング用のバッファの量が減ると
|
||
いうことに注意してください。これにより、パケットが消失するかもしれませ
|
||
ん。\fIsnaplen\fP の大きさを、必要なプロトコル情報を取得できる最小の値に
|
||
とどめるようにしてください。
|
||
\fIsnaplen\fP を 0 に設定すると、
|
||
パケット全体の捕捉に必要な長さを使用することを意味します。
|
||
.TP
|
||
.B \-T
|
||
"\fIexpression\fP" により選択されたパケットを強制的に \fItype\fR で
|
||
指定されたタイプと解釈します。有効なタイプは、
|
||
\fBcnfp\fR (Cisco NetFlow プロトコル),
|
||
\fBrpc\fR (リモートプロシージャコール)
|
||
\fBrtp\fR (リアルタイムアプリケーションプロトコル)
|
||
\fBrtcp\fR (リアルタイムアプリケーション制御プロトコル)
|
||
\fBsnmp\fR (シンプルネットワークマネージメントプロトコル)
|
||
\fBvat\fR (ビジュアルオーディオツール)
|
||
\fBwb\fR (ディストリビューテッドホワイトボード)
|
||
です。
|
||
.TP
|
||
.B \-t
|
||
各ダンプ行のタイムスタンプを出力しません。
|
||
.TP
|
||
.B \-tt
|
||
各ダンプ行毎にタイムスタンプを人間が読みやすい形に変換せずに出力します。
|
||
.TP
|
||
.B \-ttt
|
||
直前のダンプ行と現在のダンプ行の差分 (マイクロ秒単位) を表示します。
|
||
.TP
|
||
.B \-tttt
|
||
各ダンプ行で、デフォルト書式でタイムスタンプを表示し、その前に日付を付けます。
|
||
.\"" (.TPが抜けてる） **********/
|
||
.TP
|
||
.B \-u
|
||
デコードされてない NFS 操作を出力します。
|
||
.TP
|
||
.B \-v
|
||
(少しではありますが) 出力情報を増やします。例えば、IP パケット中の
|
||
TTL、識別、全長、IP パケット中のオプションが表示されます。
|
||
追加のパケットの完全性確認が有効になります。
|
||
これは例えば IP および ICMP のヘッダのチェックサムです。
|
||
.TP
|
||
.B \-vv
|
||
さらに多くの情報を出力します。例えば、NFS の返答パケットの追加
|
||
フィールドや完全にデコードされた SMB パケット
|
||
を出力します。
|
||
.TP
|
||
.B \-vvv
|
||
もっと多くの情報を出力します。例えば、telnet \fBSB\fP ... \fBSE\fP
|
||
オプションが完全に表示されます。
|
||
.B \-X
|
||
付きでは、telnet オプションが 16 進数で表示されます。
|
||
.TP
|
||
.B \-w
|
||
受信した生パケットを、解析したり画面に出力したりせずに \fIfile\fR で指定
|
||
したファイルに出力します。本オプションを用いて取得したパケットは \-r
|
||
オプションを用いることで情報を見ることができます。\fIfile\fR で指定す
|
||
るファイル名が ``-'' の場合には、標準出力を用います。
|
||
.TP
|
||
.B \-x
|
||
リンクレベルヘッダを除いた各パケットの内容を 16 進出力します。
|
||
パケットサイズが
|
||
.I snaplen
|
||
バイトより小さい場合にはパケットの全部の内容を、それ以外の場合には、
|
||
.I snaplen
|
||
バイト分のデータをパケットごとに出力します。
|
||
.TP
|
||
.B \-X
|
||
16 進出力時に、ASCII もまた表示します。
|
||
.B \-x
|
||
もまた指定されると、パケットが 16 進数と ASCII の組み合わせで表示されます。
|
||
新規プロトコルを解析するのに非常に便利です。
|
||
.B \-x
|
||
が指定されないと、
|
||
一部のパケットの一部が16 進数と ASCII の組み合わせで表示されます。
|
||
.IP "\fI expression\fP"
|
||
.RS
|
||
ダンプするパケットを選択します。\fIexpression\ が指定されない場合には、
|
||
ネットワーク上のすべてのパケットがダンプ対象になります。それ以外の場
|
||
合には、\fIexpression\fP の条件が真になるパケットのみダンプします。
|
||
.LP
|
||
\fIexpression\fP は、1 つ以上の
|
||
.I プリミティブ
|
||
から成り立ちます。
|
||
プリミティブは通常 1 つ以上の限定子のついた
|
||
.I id
|
||
(名前もしくは番号) から成り立ちます。限定子は、3 種類あります。
|
||
.IP \fI型\fP
|
||
限定子は id 名や番号が参照するものの種類を指します。型には
|
||
.BR host ,
|
||
.BR net ,
|
||
.B port
|
||
があります。例えば、`host foo', `net 128.3', `port 20' のように用います。
|
||
型限定子が指定されない場合には、
|
||
.B host
|
||
が指定されたものとみなされます。
|
||
.IP \fI方向\fP
|
||
限定子は、
|
||
パケットが
|
||
.I id
|
||
へ出ていく方向か、
|
||
.I id
|
||
から来る方向か、
|
||
もしくはその両方かという、特定の転送方向を指定します。
|
||
指定可能な方向は、
|
||
.BR src ,
|
||
.BR dst ,
|
||
.BR "src or dst" ,
|
||
.BR "src and dst"
|
||
の 4 つです。
|
||
例えば、`src foo', `dst net 128.3', `src or dst port ftp-data' のように
|
||
指定します。もし方向限定子が指定されない場合には、
|
||
.B "src or dst"
|
||
が指定されたものとみなします。
|
||
`null' リンクレイヤ
|
||
(つまり、slip などポイント・トゥ・ポイント・プロトコル)
|
||
では、
|
||
必要な方向を指定するのに
|
||
.B inbound
|
||
や
|
||
.B outbound
|
||
限定子を用いる事ができます。
|
||
.IP \fIプロトコル\fP
|
||
限定子は、特定のプロトコルに一致するパケットのみに制限します。
|
||
プロトコルとして指定可能なものは、
|
||
.BR ether ,
|
||
.BR fddi ,
|
||
.BR tr ,
|
||
.BR ip ,
|
||
.BR ip6 ,
|
||
.BR arp ,
|
||
.BR rarp ,
|
||
.BR decnet ,
|
||
.BR lat ,
|
||
.BR sca ,
|
||
.BR moprc ,
|
||
.BR mopdl ,
|
||
.BR iso ,
|
||
.BR esis ,
|
||
.BR isis ,
|
||
.BR icmp ,
|
||
.BR icmp6 ,
|
||
.B tcp ,
|
||
.BR 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' と同義です。
|
||
.LP
|
||
[`fddi' は実際には `ether' の別名になっています。解析ではこれらを「特定の
|
||
ネットワークインタフェースで使われるデータリンクレベル」を意味するもの
|
||
として同様に扱います。FDDI ヘッダはイーサネットに似た始点と終点
|
||
アドレスを含み、そしてしばしばイーサネットに似たパケット型を含むので、
|
||
イーサネットのフィールドと同じように FDDI のフィールドをフィルタリング
|
||
できます。FDDI ヘッダは他のフィールドも含みますが、フィルタ表現の中で
|
||
明示的にそれらを指定することはできません。
|
||
.LP
|
||
同様に、`tr' は `ether' の別名です。
|
||
直前の段落における FDDI ヘッダに関する記述は、
|
||
Token Ring ヘッダにも適用されます。]
|
||
.LP
|
||
上記に追加して、いくつかの特別な「プリミティブ」キーワードがあります。
|
||
これらのキーワードは
|
||
.BR gateway ,
|
||
.BR broadcast ,
|
||
.BR less ,
|
||
.B greater
|
||
と算術演算表現
|
||
です。これらの後ろにパターンが続く事はありません。
|
||
プリミティブキーワードについては後述します。
|
||
.LP
|
||
より複雑なフィルタの表現は、プリミティブの結合に
|
||
.BR and ,
|
||
.BR or ,
|
||
.B 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'
|
||
と同じ意味です。
|
||
.LP
|
||
許されるプリミティブは、以下の通りです。
|
||
.IP "\fBdst host \fIhost\fR"
|
||
IPv4/v6 パケットの終点フィールドが \fIhost\fP で指定したものの場合に、
|
||
真となります。
|
||
\fIhost\fP は、ホスト名もしくは IP アドレスです。
|
||
.IP "\fBsrc host \fIhost\fR"
|
||
IPv4/v6 パケットの始点フィールドが \fIhost\fP で指定したものの場合に、
|
||
真となります。
|
||
.IP "\fBhost \fIhost\fP
|
||
IPv4/v6 パケットの始点フィールドもしくは終点フィールドが
|
||
\fIhost\fP で指定したものの場合に、
|
||
真となります。
|
||
上記の host プリミティブの表現には、
|
||
\fBip\fP, \fBarp\fP, \fBrarp\fP, \fBip6\fP を
|
||
以下のように付加することが可能です。
|
||
.in +.5i
|
||
.nf
|
||
\fBip host \fIhost\fR
|
||
.fi
|
||
.in -.5i
|
||
という表記は、
|
||
.in +.5i
|
||
.nf
|
||
\fBether proto \fI\\ip\fB and host \fIhost\fR
|
||
.fi
|
||
.in -.5i
|
||
と同じ意味です。
|
||
\fIhost\fR が複数の IP アドレスを持つホスト名であった場合、それぞれのアドレス
|
||
について照合を検査します。
|
||
.IP "\fBether dst \fIehost\fP
|
||
イーサネットパケットの終点アドレスが \fIehost\fP だった場合に、真となります。
|
||
\fIehost\fP
|
||
は、/etc/ethers に記述された名前もしくはイーサネットアドレスの値が用いられます
|
||
(イーサネットアドレスの形式については、
|
||
.IR ethers (3N)
|
||
を参照)。
|
||
.IP "\fBether src \fIehost\fP
|
||
イーサネットパケットの始点アドレスが \fIehost\fP だった場合に、真となります。
|
||
.IP "\fBether host \fIehost\fP
|
||
イーサネットパケットの始点アドレスもしくは終点アドレスが \fIehost\fP だった
|
||
場合に、真となります。
|
||
.IP "\fBgateway\fP \fIhost\fP
|
||
パケットが \fIhost\fP で指定したアドレスのマシンをゲートウェイとしている場合に
|
||
真となります。言い替えると、始点もしくは終点のイーサネットアドレスが
|
||
\fIhost\fP であり、始点と終点のどちらの IP アドレスも \fIhost\fP でない
|
||
ということです。
|
||
\fIhost\fP
|
||
マシンの host-name-to-IP-address (名前解決) 制御機構
|
||
(hosts ファイル、DNS、NIS など)
|
||
とマシンの host-name-to-Ethernet-address (イーサネット
|
||
アドレス解決) 制御機構
|
||
(/etc/ethers など)
|
||
から見つけられる名前である必要があります。
|
||
(同様な記述は、
|
||
.in +.5i
|
||
.nf
|
||
\fBether host \fIehost \fBand not host \fIhost\fR
|
||
.fi
|
||
.in -.5i
|
||
です。この場合 \fIhost / ehost\fP のどちらにも名前もしくは値を用いることが
|
||
可能になります。)
|
||
この構文は、現在のところ、IPv6 が有効な構成では動作しません。
|
||
.IP "\fBdst net \fInet\fR"
|
||
パケットの終点 IPv4/v6 アドレスが、
|
||
\fInet\fP で指定されたネットワークに属するものである場合に、
|
||
真となります。
|
||
\fInet\fP は、アドレス値もしくは /etc/networks で
|
||
定義されたネットワーク名のいずれかを指定可能です (詳しくは、\fInetworks(4)\fP
|
||
を参照)。
|
||
.IP "\fBsrc net \fInet\fR"
|
||
パケットの始点 IPv4/v6 アドレスが、
|
||
\fInet\fP で指定されたネットワークに属するものである場合に、真となります。
|
||
.IP "\fBnet \fInet\fR"
|
||
始点 IPv4/v6 アドレスもしくは終点 IPv4/v6 アドレスが \fInet\fP で指定された
|
||
ネットワークに属するものである場合に、真となります。
|
||
.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
|
||
IP アドレスが、指定された \fInet\fR および \fInetmask\fR の値で決まる
|
||
ネットワークに属するものである場合に、真となります。
|
||
\fBsrc\fR や \fBdst\fR を指定する事も可能です。
|
||
この構文は IPv6 \fInet\fR では正当でないことに注意してください。
|
||
.IP "\fBnet \fInet\fR/\fIlen\fR"
|
||
IPv4/v6 アドレスが、指定された \fIlen\fR
|
||
のビット長のネットマスクで \fInet\fR に属するネットワーク
|
||
の場合に、真となります。
|
||
\fBsrc\fR や \fBdst\fR を指定する事も可能です。
|
||
.IP "\fBdst port \fIport\fR"
|
||
パケットが ip/tcp, ip/udp, ip6/tcp, ip6/udp のいずれかであり、終点
|
||
ポート番号が \fIport\fP の場合に、真となります。
|
||
\fIport\fP で指定されるポート番号は、値もしくは /etc/services で定義
|
||
されているサービス名で指定可能です (
|
||
.IR tcp (4P)
|
||
や
|
||
.IR udp (4P)
|
||
を参照)。
|
||
ポート番号がサービス名にて指定された場合、
|
||
ポート番号とプロトコルの両方がチェック
|
||
対象になります。ポート番号や、あいまいなサービス名が指定された場合には、
|
||
ポート番号のみがチェック対象となります(例えば、\fBdst port 513\fR は、
|
||
tcp/login と udp/who の両方を出力し、\fBport domain\fR は、tcp/domain
|
||
と udp/domain の両方を出力します)。
|
||
.IP "\fBsrc port \fIport\fR"
|
||
パケットが \fIport\fP で指定した始点ポート番号を保持している場合に
|
||
真となります。
|
||
.IP "\fBport \fIport\fR"
|
||
パケットの始点ポート番号もしくは終点ポート番号が \fIport\fP の場合に、
|
||
真となります。
|
||
上記のポート番号の指定については、すべてキーワード \fBtcp\fP もし
|
||
くは \fBudp\fP を用いて、ある程度候補を絞り込むことが可能です。例えば、
|
||
.in +.5i
|
||
.nf
|
||
\fBtcp src port \fIport\fR
|
||
.fi
|
||
.in -.5i
|
||
と指定した場合には、tcp パケットのみが条件一致の評価対象となります。
|
||
.IP "\fBless \fIlength\fR"
|
||
パケットが \fIlength\fP で指定した長さ以下の場合、真となります。
|
||
これは、
|
||
.in +.5i
|
||
.nf
|
||
\fBlen <= \fIlength\fR
|
||
.fi
|
||
.in -.5i
|
||
の指定と等価です。
|
||
.IP "\fBgreater \fIlength\fR"
|
||
パケットが \fIlength\fP で指定した長さ以上の場合、真となります。
|
||
これは、
|
||
.in +.5i
|
||
.nf
|
||
\fBlen >= \fIlength\fR
|
||
.fi
|
||
.in -.5i
|
||
と等価です。
|
||
.IP "\fBip proto \fIprotocol\fR"
|
||
パケットが \fIprotocol\fP で指定したプロトコル型の IP パケット (
|
||
詳細は
|
||
.IR ip (4P)
|
||
を参照) の場合に、真となります。
|
||
\fIprotocol\fP は、数字もしくは
|
||
\fIicmp\fP, \fIicmp6\fP, \fIigmp\fP, \fIigrp\fP, \fIpim\fP, \fIah\fP,
|
||
\fIesp\fP, \fIvrrp\fP, \fIudp\fP, \fItcp\fP
|
||
のいずれかの名前が指定可能です。\fItcp\fP, \fIudp\fP, \fIicmp\fP の
|
||
各識別子はキーワードでもであり、バックスラッシュ (\\)(C-shell では \\\\) を用
|
||
いてエスケープしなければならないことに注意してください。
|
||
このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。
|
||
.IP "\fBip6 proto \fIprotocol\fR"
|
||
パケットがプロトコル型 \fIprotocol\fP の IPv6 パケットである場合に、
|
||
真となります。
|
||
このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。
|
||
.IP "\fBip6 protochain \fIprotocol\fR"
|
||
パケットが IPv6 パケットであり、
|
||
プロトコルヘッダチェーン中にタイプ \fIprotocol\fR のプロトコルヘッダが
|
||
含まれるばあい に、真となります。
|
||
例えば
|
||
.in +.5i
|
||
.nf
|
||
\fBip6 protochain 6\fR
|
||
.fi
|
||
.in -.5i
|
||
は、TCP プロトコルヘッダがプロトコルヘッダチェーン中に含まれる
|
||
任意のパケットにマッチします。
|
||
パケット中には、IPv6 ヘッダと TCP ヘッダの間に、
|
||
例えば、認証ヘッダ、ルーティングヘッダ、ホップ毎のオプションヘッダが
|
||
含まれ得ます。
|
||
このプリミティブが出力する BPF コードは、
|
||
複雑であり \fItcpdump\fP 中の BPF 最適化コードでは最適化できません。
|
||
よって、この動作はいくぶん遅いです。
|
||
.IP "\fBip protochain \fIprotocol\fR"
|
||
\fBip6 protochain \fIprotocol\fR と同様で、
|
||
IPv4 のものです。
|
||
.IP "\fBether broadcast\fR"
|
||
パケットがイーサネットブロードキャストパケットの場合に、真となります。
|
||
\fIether\fP キーワードは、省略可能です。
|
||
.IP "\fBip broadcast\fR"
|
||
パケットが IP ブロードキャストパケットの場合に、真となります。オール 1 と
|
||
オール 0 の二つの形式のブロードキャストアドレスを検査し、そして
|
||
ローカルサブネットマスクを調べます。
|
||
.IP "\fBether multicast\fR"
|
||
パケットがイーサネットマルチキャストパケットの場合に、真となります。
|
||
\fIether\fP キーワードは、省略可能です。
|
||
なお、この指定は、`\fBether[0] & 1 != 0\fP' の短縮系です。
|
||
.IP "\fBip multicast\fR"
|
||
パケットが IP マルチキャストパケットの場合に、真となります。
|
||
.IP "\fBip6 multicast\fR"
|
||
パケットが IPv6 マルチキャストパケットの場合に、真となります。
|
||
.IP "\fBether proto \fIprotocol\fR"
|
||
パケットが \fIprotocol\fR で指定した ether 型の場合に、真になります。
|
||
\fIprotocol\fP は、数字もしくは
|
||
\fIip\fP, \fIip6\fP, \fIarp\fP, \fIrarp\fP, \fIatalk\fP, \fIaarp\fP,
|
||
\fIdecnet\fP, \fIsca\fP, \fIlat\fP, \fImopdl\fP, \fImoprc\fP,
|
||
\fIiso\fP, \fIstp\fP, \fIipx\fP, \fInetbeui\fP
|
||
のいずれかの名前を指定可能です。
|
||
これらの識別子はキーワードでもあり、バックスラッシュ (\\) でエスケープし
|
||
なければならないことに注意してください。
|
||
.IP
|
||
[FDDI (例えば `\fBfddi protocol arp\fR') や Token Ring (
|
||
例えば`\fBtr protocol arp\fR') 、
|
||
これらのほとんどのプロトコルの場合、プロトコルの識別は
|
||
IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。
|
||
通常これは FDDI ヘッダや Token Ring ヘッダの上の層にあります。
|
||
.IP
|
||
FDDI または Token Ring のほとんどのプロトコル識別
|
||
をフィルタリングするとき、\fItcpdump\fR は
|
||
Ethernet をカプセル化するために
|
||
LLC ヘッダのプロトコル ID 範囲のみ、
|
||
いわゆる SNAP フォーマットである
|
||
管理組織識別子 (OUI) の 0x000000
|
||
の範囲のみをチェックします。
|
||
パケットが
|
||
SNAP フォーマットである
|
||
OUI の 0x000000 にあるか
|
||
どうかはチェックしません。
|
||
.IP
|
||
例外は以下の通りです。
|
||
\fIiso\fP は LLC ヘッダの
|
||
DSAP (Destination Service Access Point)
|
||
と SSAP (Source Service Access Point) の
|
||
範囲もチェックします。
|
||
\fIstp\fP および \fInetbeui\fP は、LLC ヘッダの
|
||
DSAP をチェックします。
|
||
\fIatalk\fP は、
|
||
SNAP フォーマットである OUI の 0x080007
|
||
と、Appletalk etype に対してチェックします。
|
||
.IP
|
||
Ethernet の場合、\fItcpdump\fR は、
|
||
これらのプロトコルのほとんどに対して Ethernet 型の
|
||
範囲をチェックします。
|
||
例外は以下の通りです。
|
||
\fIiso\fP、\fIsap\fP および \fInetbeui\fP では
|
||
FDDI および Token Ring の場合と同様に
|
||
802.3 フレームをチェックし、次に
|
||
LLC ヘッダをチェックします。
|
||
\fIatalk\fP では
|
||
FDDI および Token Ring の場合と同様に
|
||
Ethernet フレーム内 の Appletalk etype および
|
||
SNAP フォーマットパケットの両方に対してチェックします。
|
||
\fIaarp\fP では
|
||
Ethernet フレームまたは
|
||
802.3 SNAP フレームである
|
||
OUI の 0x000000 と、
|
||
Appletalk ARP etype に対してチェックします。
|
||
そして、\fIipx\fP では、Ethernet フレーム内の IPX etype、
|
||
LCC ヘッダ内の IPX DSAP、LCC ヘッダが IPX でカプセル化
|
||
されていない 802.2 および SNAP フレーム内の IPX etype を
|
||
チェックします。
|
||
]
|
||
.IP "\fBdecnet src \fIhost\fR"
|
||
DECNET パケットの始点アドレスが
|
||
.IR host
|
||
の場合に、真となります。これは ``10.123'' という形式のアドレスでも DECNET の
|
||
ホスト名でも構いません。[DECNET のホスト名は DECNET を動かすように設定され
|
||
た Ultrix システムのみでサポートされます。]
|
||
.IP "\fBdecnet dst \fIhost\fR"
|
||
DECNET パケットの終点アドレスが
|
||
.IR host
|
||
の場合に、真となります。
|
||
.IP "\fBdecnet host \fIhost\fR"
|
||
DECNET パケットの始点あるいは終点アドレスが
|
||
.IR host
|
||
の場合に、真となります。
|
||
.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
|
||
.in +.5i
|
||
.nf
|
||
\fBether proto \fIp\fR
|
||
.fi
|
||
.in -.5i
|
||
の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
|
||
.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
|
||
.in +.5i
|
||
.nf
|
||
\fBether proto \fIp\fR
|
||
.fi
|
||
.in -.5i
|
||
の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
|
||
\fItcpdump\fP は今のところこれらのプロトコルを解釈できない事に注意して
|
||
ください。
|
||
.IP "\fBvlan \fI[vlan_id]\fR"
|
||
パケットが IEEE 802.1Q VLAN パケットの場合、真になります。
|
||
\fI[vlan_id]\fR が指定された場合、
|
||
パケットが指定された \fIvlan_id\fR を持つ場合のみ、真になります。
|
||
\fIexpression\fR 中の最初の \fBvlan\fR キーワードが、
|
||
パケットが VLAN パケットであることを仮定して、
|
||
残りの \fIexpression\fR のデコード用オフセットを変更してしまうことに
|
||
注意してください。
|
||
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
|
||
.in +.5i
|
||
.nf
|
||
\fBip proto \fIp\fR\fB or ip6 proto \fIp\fR
|
||
.fi
|
||
.in -.5i
|
||
の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
|
||
.IP "\fBiso proto \fIprotocol\fR"
|
||
パケットがプロトコル型 \fIprotocol\fP の OSI パケットの場合、真になります。
|
||
\fIprotocol\fP は数値もしくは
|
||
\fIclnp\fP, \fIesis\fP, \fIisis\fP
|
||
という名前のいずれかです。
|
||
.IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR"
|
||
.in +.5i
|
||
.nf
|
||
\fBiso proto \fIp\fR
|
||
.fi
|
||
.in -.5i
|
||
の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
|
||
\fItcpdump\fR はこれらのプロトコルを完全には解釈できない事に注意して
|
||
ください。
|
||
.IP "\fIexpr relop expr\fR"
|
||
\fIrelop\fRは、>, <, >=, <=, =, != のいずれかであり、\fIexpr\fR の部分に
|
||
は、(標準 C 言語の構文で表現された) 整数定数や通常の二項演算子 [+, -, *, /,
|
||
&, |]、length 演算子、そして特殊なパケットデータへのアクセス演算子などか
|
||
らなる算術表現が入って、その関係が成立する場合に、真となります。
|
||
パケット内部のデータにアクセスするためには、以下の構文を用います。
|
||
.in +.5i
|
||
.nf
|
||
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
|
||
.fi
|
||
.in -.5i
|
||
\fIproto\fRは、\fBether, fddi, tr, ip, arp, rarp, tcp, udp, icmp, ip6\fR
|
||
のいずれかであり、インデックス操作を行うプロトコル層を指示
|
||
します。
|
||
\fItcp, udp\fR および他の上位層プロトコル型は、
|
||
IPv4 のみに適用され、IPv6 には適用されないことに注意してください
|
||
(これは将来修正されます)。
|
||
指示したプロトコル層からの相対バイトオフセットは、\fIexpr\fR で指定します。
|
||
\fIsize\fR は省略可能で、取得するフィールドのデータ長を表します。
|
||
データ長としては、1,2,4 のいずれかを指定することが可能であり、デフォルトでは
|
||
1 が指定されたものとみなされます。
|
||
キーワード \fBlen\fP で示されるデータ長演算子は、パケット長を与えます。
|
||
|
||
例えば、`\fBether[0] & 1 != 0\fP' は、全てのマルチキャストパケットを捕捉します。
|
||
`\fBip[0] & 0xf != 5\fP' という表現は、すべてのオプション付きIPパケットを捕捉す
|
||
ることを意味します。`\fBip[6:2] & 0x1fff = 0\fP' という表現は、フラグメントのな
|
||
いデータグラムパケット、もしくはフラグメント化されたデータグラムのうち
|
||
最初のフラグメントを捕捉します。
|
||
この検査は、\fBtcp\fP および \fBudp\fP のインデックス操作においては、暗黙のうち
|
||
に適用されます。
|
||
例えば、\fBtcp[0]\fP は常に TCP \fIヘッダ\fPの先頭バイトを指し、
|
||
決して各フラグメントの先頭バイトを指すものではありません。
|
||
|
||
いくつかのオフセットとフィールド値は、数値ではなく
|
||
定数として表記できます。
|
||
次のプロトコルヘッダフィールドオフセットが利用可能です。
|
||
\fBicmptype\fP (ICMP タイプフィールド)、\fBicmpcode\fP (ICMP
|
||
コードフィールド) および \fBtcpflags\fP (TCP フラグフィールド)
|
||
|
||
次の ICMP タイプフィールド値が利用可能です。
|
||
\fBicmp-echoreply\fP,
|
||
\fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
|
||
\fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
|
||
\fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
|
||
\fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
|
||
\fBicmp-maskreq\fP, \fBicmp-maskreply\fP
|
||
|
||
次の TCP フラグフィールド値が利用可能です。
|
||
\fBtcp-fin\fP,
|
||
\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP, \fBtcp-push\fP,
|
||
\fBtcp-ack\fP, \fBtcp-urg\fP
|
||
.LP
|
||
プリミティブは、以下のように組み合わせることが可能です。
|
||
.IP
|
||
括弧で括られた一連のプリミティブや演算子
|
||
(括弧はシェルの特殊文字なのでエスケープする必要があります)。
|
||
.IP
|
||
否定 (`\fB!\fP' or `\fBnot\fP').
|
||
.IP
|
||
論理積 (`\fB&&\fP' or `\fBand\fP').
|
||
.IP
|
||
論理和 (`\fB||\fP' or `\fBor\fP').
|
||
.LP
|
||
否定は、最も高い演算優先度を持ちます。論理和と論理積は、同じ演算優先度を持ち、
|
||
左から右へ評価されます。論理積の場合には、単に識別子を並べるのではなく、
|
||
明示的に \fBand\fR を使用しなければならないことに注意して下さい。
|
||
.LP
|
||
キーワードなしで識別子が与えられている場合には、最も最近用いられたキーワードが
|
||
付加されているものと仮定されます。
|
||
例えば、
|
||
.in +.5i
|
||
.nf
|
||
\fBnot host vs and ace\fR
|
||
.fi
|
||
.in -.5i
|
||
は、
|
||
.in +.5i
|
||
.nf
|
||
\fBnot host vs and host ace\fR
|
||
.fi
|
||
.in -.5i
|
||
の短縮形ですが、
|
||
.in +.5i
|
||
.nf
|
||
\fBnot ( host vs or ace )\fR
|
||
.fi
|
||
.in -.5i
|
||
と混同してしまいがちなので気をつけましょう。
|
||
.LP
|
||
引数 expression は、単一の引数としても複数の引数としても、どちらか便利な
|
||
方で、\fItcpdump\fP に渡すことができます。
|
||
一般的に、引数がシェルのメタキャラクタを含む場合、その引数をクォート
|
||
された単一の引数としてプログラムに渡す方が容易です。
|
||
複数の引数は、解析される前にスペースで連結されます。
|
||
.SH 使用例
|
||
.LP
|
||
\fIsundown\fP に到達する、もしくはそこから送信されるパケットのすべてを
|
||
表示する場合には、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
\fBtcpdump host sundown\fP
|
||
.fi
|
||
.RE
|
||
.LP
|
||
\fIhelios\fR と、\fIhot\fR もしくは \fIace\fR の間のトラフィックを表示する
|
||
場合には、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
\fBtcpdump host helios and \\( hot or ace \\)\fP
|
||
.fi
|
||
.RE
|
||
.LP
|
||
\fIace\fR と、\fIhelios\fR 以外のホストとの間でやりとりされるすべての
|
||
IP パケットを表示する場合には、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
\fBtcpdump ip host ace and not helios\fP
|
||
.fi
|
||
.RE
|
||
.LP
|
||
ローカルなホストと Berkeley のホストとの間でやりとりされるすべての
|
||
トラフィックを表示する場合には、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump net ucb-ether
|
||
.fi
|
||
.RE
|
||
.LP
|
||
インターネットゲートウェイ \fIsnup\fP を通過するすべての ftp
|
||
トラフィックを表示する場合には、以下のように実行します
|
||
(シェルが括弧を誤って解釈しないよう、フィルタを表現する引数がクォートさ
|
||
れていることに注意して下さい)。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump 'gateway snup and (port ftp or ftp-data)'
|
||
.fi
|
||
.RE
|
||
.LP
|
||
始点アドレスと終点アドレスの両方がローカルネットワーク内のホスト
|
||
のものでないトラフィックについて表示する場合には、以下のように実行しま
|
||
す
|
||
(実行するホストが他のネットワークに対するゲートウェイの場合、そのホスト
|
||
が属すローカルネットワークでは、このコマンドは成功しないでしょう)。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump ip and not net \fIlocalnet\fP
|
||
.fi
|
||
.RE
|
||
.LP
|
||
ローカルネットワーク外のホストとの通信において、TCP による各通信単位
|
||
のスタートパケットとエンドパケット (SYN と FIN パケット) を表示するには、以
|
||
下のように実行します。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
|
||
.fi
|
||
.RE
|
||
.LP
|
||
ゲートウェイ \fIsnup\fP を中継される IP パケットのうち、576 バイトより大きいもの
|
||
を表示するには、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump 'gateway snup and ip[2:2] > 576'
|
||
.fi
|
||
.RE
|
||
.LP
|
||
イーサネット上でブロードキャストもしくはマルチキャストを経由して送られる
|
||
もの以外の IP ブロードキャストもしくはマルチキャストパケットを表示するには、
|
||
以下のように実行します。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
|
||
.fi
|
||
.RE
|
||
.LP
|
||
echo 要求/応答以外 (つまり ping パケット以外) の全ての ICMP パケットを
|
||
表示するには、以下のように実行します。
|
||
.RS
|
||
.nf
|
||
.B
|
||
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
|
||
.fi
|
||
.RE
|
||
.SH 出力形式
|
||
.LP
|
||
\fItcpdump\fP の出力は、プロトコル依存です。以下の説明では、簡単な
|
||
パラメータの記述と、おおよそのフォーマットの説明を行ないます。
|
||
.de HD
|
||
.sp 1.5
|
||
.B
|
||
..
|
||
.HD
|
||
リンクレベルヘッダ
|
||
.LP
|
||
もし '-e' オプションが指定されると、リンクレベルヘッダが出力されます。
|
||
イーサネットにおいては、始点と終点のアドレス、プロトコル、そして
|
||
パケット長が出力されます。
|
||
.LP
|
||
FDDI ネットワークにおいては、'-e' オプションが指定されると \fItcpdump\fP
|
||
は、「フレーム制御」フィールド、発信元と終点アドレス、そしてパケット長を
|
||
出力します。「フレーム制御」フィールドはパケットの残りの部分の解釈を決定
|
||
します。(IP データグラムを含むような) 通常のパケットは `async' パケットで、
|
||
0 から 7 の間の優先順位を持ちます。例えば、`\fBasync4\fR' です。こうした
|
||
パケットは IEEE802.2 の論理リンク制御 (LLC) パケットを含むと仮定されます。
|
||
LLC ヘッダは、それが ISO データグラムでない場合やいわゆる SNAP パケットのと
|
||
きには出力されます。
|
||
.LP
|
||
Token Ring ネットワークでは、'-e' オプションを指定すると、\fItcpdump\fP は、
|
||
アクセス制御」と「フレーム制御」のフィールド、
|
||
始点と終点のアドレス、パケット長を表示します。
|
||
FDDI ネットワークでは、パケットは LLC パケットを含むと仮定されます。
|
||
オプション '-e' の指定の有無にかかわらず、
|
||
始点経路制御されたパケットに対しては、始点経路制御情報が表示されます。
|
||
.LP
|
||
\fI (注意: 以下の記述は、利用者が RFC1144 に記述されている SLIP 圧縮
|
||
アルゴリズムについての知識がある前提で書いています。)\fP
|
||
.LP
|
||
SLIP によるリンクにおいては、方向指示子 (``I'' が入力方向、``O''
|
||
が出力方向)、パケット型、そして圧縮情報が出力されます。
|
||
パケット型は、最初に出力されます。パケット型には \fIip\fP、\fIutcp\fP、そして
|
||
\fIctcp\fP の 3 つがあります。
|
||
\fIip\fR 型パケットの場合、上記以上のリンク情報は表示されません。
|
||
TCP パケットの場合には、コネクション識別子がパケット型に続いて出力されます。
|
||
パケットが圧縮されている場合、符号化されたヘッダが出力されます。
|
||
特殊な場合は \fB*S+\fIn\fR や \fB*SA+\fIn\fR のように出力されます。ここ
|
||
で \fIn\fR は、シーケンス番号 (もしくはシーケンス番号および ack) が変更された回
|
||
数です。特殊な場合でなければ、0 回以上の変更について出力されます。
|
||
変更は、U (緊急 (urgent) ポインタ)、W (ウィンドウ)、A (ack)、S (シーケンス番号)、
|
||
そして I (パケット ID) で示され、変動量 (+n or -n)
|
||
もしくは新しい値 (=n) が続きます。
|
||
最後に、パケット内のデータの総量および圧縮ヘッダ長が出力されます。
|
||
.LP
|
||
例えば、以下の行は、出力方向の圧縮 TCP パケットを、暗黙のコネクション識別子
|
||
とともに表示しています。ack は 6 変わり、シーケンス番号は 49 変わり、パケット
|
||
ID は 6 変わっています。3 バイトのデータと6 バイトの圧縮ヘッダが存在します。
|
||
.RS
|
||
.nf
|
||
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
|
||
.fi
|
||
.RE
|
||
.HD
|
||
ARP/RARP パケット
|
||
.LP
|
||
arp/rarp パケットの出力は、要求型とその引数を示してい
|
||
ます。出力形式は、その出力のみで理解可能なように作られています。
|
||
以下に、ホスト \fIrtsg\fP からホスト \fIcsam\fP への `rlogin' 開始時の
|
||
パケットの実例を示します。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\f(CWarp who-has csam tell rtsg
|
||
arp reply csam is-at CSAM\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
1行目は、ホスト rtsg が、ホスト csam のイーサネットアドレスを問い合わせる
|
||
目的で arp パケットを送信していることを意味します。ホスト csam は、自分自身
|
||
のイーサネットアドレスを返答しています (この例では、イーサネットアドレス
|
||
は大文字で、インターネットアドレス部は小文字で表記しています)。
|
||
.LP
|
||
\fItcpdump \-n\fP として起動した場合には、少し冗長になります。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\f(CWarp 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\fR
|
||
.fi
|
||
.RE
|
||
.LP
|
||
\fItcpdump \-e\fP として起動した場合には、最初のパケットはブロードキャスト
|
||
パケットであり、次のパケットはポイントツーポイントのパケットであることが
|
||
わかります。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
|
||
CSAM RTSG 0806 64: arp reply csam is-at CSAM\fP
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初のパケットについては、始点のイーサネットアドレスは RTSG であり、
|
||
終点はイーサネットブロードキャストアドレス、型フィールドには 16 進数の値
|
||
0806 (ETHER_ARP を意味します) が格納されており、総パケット長は 64 バイトである
|
||
と表示しています。
|
||
.HD
|
||
TCP パケット
|
||
.LP
|
||
\fI(注意:以下の記述は、RFC793 に記述されている TCP プロトコルについての知識
|
||
があることを前提に記述されています。この知識がない場合、本記述と
|
||
\fItcpdump\fP のいずれもあなたには役に立たないでしょう。)\fP
|
||
.LP
|
||
TCP プロトコル行の一般的な形式は、以下の通りです。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fIsrc > dst: flags data-seqno ack window urgent options\fP
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
\fIsrc\fP と \fIdst\fP は、それぞれ始点と終点の IP アドレスと
|
||
ポート番号です。\fIflags\fP の部分には、S (SYN), F (FIN), P (PUSH), R (RST)
|
||
の組み合わせ、もしくは単なる `.' (フラグなし) が入ります。
|
||
\fIdata-seqno\fP は、このパケット内のデータがシーケンス空間のどの部分に
|
||
あたるかを示します (以下の例を参照して下さい)。
|
||
\fIack\fP は、本コネクション上を逆方向に次に流れるデータパケットの
|
||
シーケンス番号です。
|
||
\fIwindow\fP は、本コネクションの逆方向のパケットを格納するバッファサイズ
|
||
です。
|
||
\fIurg\fP は、パケット中に `urgent' (緊急) データが格納されていることを示しま
|
||
す。
|
||
\fIoptions\fP は、例えば <mss 1024> のように、アングルブラケット (大小記号) で
|
||
括られた tcp オプションです。
|
||
.LP
|
||
\fIsrc、dst\fP、そして \fIflags\fP は、常に表示されます。他のフィールドは、
|
||
パケットの TCP ヘッダに依存し、表示できる場合だけ表示されます。
|
||
.LP
|
||
以下の例は、ホスト \fIrtsg\fP からホスト \fIcsam\fP への rlogin
|
||
開設時のシーケンスの一部です。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\s-2\f(CWrtsg.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\fR\s+2
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の行は、ホスト rtsg の TCP ポート 1023 番からホスト csam の \fIlogin\fP
|
||
ポートに対してパケットを送信していることを意味します。\fBS\fP は、
|
||
パケットの \fISYN\fP フラグが設定されていることを意味します。
|
||
パケットのシーケンス番号は 768512 番であり、データは含みません。
|
||
(表記は `first:last(nbytes)' であり、これは「シーケンス番号 \fIfirst\fP か
|
||
ら \fIlast\fP までの \fIlast\fP を含まない \fInbytes\fP のユーザデータという
|
||
こと」を意味しています。)
|
||
このパケット中に ack はなく、有効な受信ウィンドウの大きさは 4096 バイトで
|
||
あり、1024 バイトの最大セグメントサイズ要求を行なうオプションが付加され
|
||
ています。
|
||
.LP
|
||
csam は、rtsg から送られたパケットと類似したパケットを送り返しますが、
|
||
rtsg の送った SYN に対する ack が含まれるところが異なり
|
||
ます。続いて、rtsg は csam の SYN に対する ack を返します。
|
||
`.' は、S (SYN), F (FIN), P (PUSH), R (RST) のいずれのフラグも
|
||
立っていないことを意味します。
|
||
パケットはデータを含まないため、データシーケンス番号は入りません。
|
||
ack シーケンス番号が小さい整数 (1) であることに注意して下さい。
|
||
\fItcpdump\fP は、初めて TCP の「通信」を検出すると、パケットから取得した
|
||
シーケンス番号を表示します。通信のその後のパケットについては、現在の
|
||
パケットシーケンス番号と、この最初のシーケンス番号の間の差を表示します。
|
||
このことは、最初に取得した以降のシーケンス番号は、通信データストリーム
|
||
の相対位置として解釈できることを意味します (最初の各方向のデータバイト
|
||
は 1 です)。`-S' は、本機能を無効にし、元のシーケンス番号を表示します。
|
||
.LP
|
||
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 バイトデータを送信しています。
|
||
.LP
|
||
スナップショットが小さ過ぎて \fItcpdump\fP が
|
||
TCP ヘッダ全体を捕えなかった場合、
|
||
可能な限りのヘッダを解釈し、``[|\fItcp\fP]'' を表示して
|
||
残りを解釈できなかったことを示します。
|
||
(短か過ぎるまたはヘッダを越えてしまうといった) 不正なオプションを
|
||
ヘッダが持つ場合には、tcpdump は ``[\fIbad opt\fP]'' を表示して
|
||
残りのオプションを解釈しません (どこから開始したら良いのか分からないからです)。
|
||
ヘッダ長によりオプションが存在することが分かるが、
|
||
IP データグラム長がオプションがそこにあるために十分な長さではない場合に、
|
||
\fItcpdump\fP は ``[\fIbad hdr length\fP]'' を表示します。
|
||
.HD
|
||
.B 特定フラグの組み合わせ (SYN-ACK, URG-ACK 等) による TCP パケットの捕捉
|
||
.PP
|
||
TCP ヘッダの制御ビットセクションには、次の 8 ビットがあります:
|
||
.IP
|
||
.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
|
||
.PP
|
||
TCP 接続の確立に使用されるパケットを見たいものとしましょう。
|
||
新規接続を初期化する時、
|
||
TCP は 3 ウェイハンドシェークプロトコルを使用することを思い出してください。
|
||
TCP 制御ビットに関する接続の順番は次のようになります。
|
||
.PP
|
||
.RS
|
||
1) 呼び出し側が SYN を送信
|
||
.RE
|
||
.RS
|
||
2) 受信者が SYN, ACK で応答
|
||
.RE
|
||
.RS
|
||
3) 呼び出し側が ACK を送信
|
||
.RE
|
||
.PP
|
||
ここで、SYN ビットを持つパケットを捕捉したいとします (第 1 ステップ)。
|
||
ステップ 2 のパケット (SYN-ACK) は不要で、
|
||
最初の SYN だけが欲しいことに注意してください。
|
||
必要なのは、\fItcpdump\fP の正しいフィルタ式です。
|
||
.PP
|
||
オプション無しの TCP ヘッダの構造を思い出してください:
|
||
.PP
|
||
.nf
|
||
0 15 31
|
||
-----------------------------------------------------------------
|
||
| 始点ポート | 終点ポート |
|
||
-----------------------------------------------------------------
|
||
| シーケンス番号 |
|
||
-----------------------------------------------------------------
|
||
| 確認応答番号 |
|
||
-----------------------------------------------------------------
|
||
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
|
||
-----------------------------------------------------------------
|
||
| TCP チェックサム | 緊急ポインタ |
|
||
-----------------------------------------------------------------
|
||
.fi
|
||
.PP
|
||
TCP ヘッダは、オプションが無ければ通常、20 オクテットのデータを持ちます。
|
||
図の最初の行はオクテット 0 から 3 を示し、
|
||
次の行はオクテット 4 から 7 を示す等となります。
|
||
.PP
|
||
0 から数え始めると、必要な TCP 制御ビットはオクテット 13 にあります:
|
||
.PP
|
||
.nf
|
||
0 7| 15| 23| 31
|
||
----------------|---------------|---------------|----------------
|
||
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
|
||
----------------|---------------|---------------|----------------
|
||
| |13 オクテット目| | |
|
||
.fi
|
||
.PP
|
||
第 13 オクテットをもっとよく見てみましょう:
|
||
.PP
|
||
.nf
|
||
| |
|
||
|---------------|
|
||
|C|E|U|A|P|R|S|F|
|
||
|---------------|
|
||
|7 5 3 0|
|
||
.fi
|
||
.PP
|
||
これらは我々が興味がある TCP 制御ビットです。
|
||
このオクテットのビットを、右から左へ、0 から 7 と番号付けします。
|
||
PSH ビットは第 3 ビットであり、URG ビットは第 5 ビットです。
|
||
.PP
|
||
最初の SYN だけを持つパケットが欲しいことに注意してください。
|
||
SYN ビットがセットされた TCP データグラムが到着すると、
|
||
第 13 オクテットになにが起きるか見てみましょう:
|
||
.PP
|
||
.nf
|
||
|C|E|U|A|P|R|S|F|
|
||
|---------------|
|
||
|0 0 0 0 0 0 1 0|
|
||
|---------------|
|
||
|7 6 5 4 3 2 1 0|
|
||
.fi
|
||
.PP
|
||
制御ビットセクションを見ると、ビット番号 1 (SYN) のみがセットされています。
|
||
.PP
|
||
オクテット番号 13 が、ネットワークバイト順で、
|
||
8 ビット符号無し整数と仮定します。
|
||
このオクテットの 2 進数値は
|
||
.IP
|
||
00000010
|
||
.PP
|
||
となり、10 進数での表現は次のようになります:
|
||
.PP
|
||
.nf
|
||
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
|
||
.fi
|
||
.PP
|
||
SYN のみセットされている場合について理解したので、これでほとんど終りです。
|
||
TCP ヘッダの第 13 オクテットの値は、
|
||
ネットワークバイト順の 8 ビット符号無し整数として解釈すると、
|
||
正確に 2 となります。
|
||
.PP
|
||
この関係は次のように表現可能です:
|
||
.RS
|
||
.B
|
||
tcp[13] == 2
|
||
.RE
|
||
.PP
|
||
この式を \fItcpdump\fP のフィルタとして使用し、
|
||
SYN パケットのみを持つパケットを捕捉可能です:
|
||
.RS
|
||
.B
|
||
tcpdump -i xl0 tcp[13] == 2
|
||
.RE
|
||
.PP
|
||
この式は「TCP データグラムの第 13 オクテットは 10 進数 2 を持つ」
|
||
と言っており、まさに我々が望むものです。
|
||
.PP
|
||
次に、SYN パケットが必要であるが、ACK や他の TCP 制御ビットについては
|
||
どうでも良い場合を考えます。
|
||
SYN-ACK が設定された TCP データグラムが到着した時に
|
||
オクテット 13 がどうなっているかを見てみましょう:
|
||
.PP
|
||
.nf
|
||
|C|E|U|A|P|R|S|F|
|
||
|---------------|
|
||
|0 0 0 1 0 0 1 0|
|
||
|---------------|
|
||
|7 6 5 4 3 2 1 0|
|
||
.fi
|
||
.PP
|
||
今度は、第 13 オクテットの第 1 ビットと第 4 ビットがセットされています。
|
||
第 13 オクテットの 2 進数値は
|
||
.IP
|
||
00010010
|
||
.PP
|
||
となり、10 進数では次のようになります:
|
||
.PP
|
||
.nf
|
||
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
|
||
.fi
|
||
.PP
|
||
今度は、\fItcpdump\fP フィルタ式に 'tcp[13] == 18' を使用できません。
|
||
この式は、SYN-ACK がセットされているパケットのみを選択し、
|
||
SYN のみセットされているパケットを選択しないからです。
|
||
ACK や他の制御ビットがセットされていようといまいと構わないことを
|
||
思い出してください。
|
||
.PP
|
||
この目的を達成するために、第 13 オクテットと他の値との論理 AND を取り、
|
||
SYN ビットを得ることが必要です。
|
||
我々が欲しいのはどんな場合でも SYN がセットされていれば良いので、
|
||
第 13 オクテットと SYN の 2 進数値との論理 AND を取ります:
|
||
.PP
|
||
.nf
|
||
|
||
00010010 SYN-ACK 00000010 SYN
|
||
AND 00000010 (SYN が欲しい) AND 00000010 (SYN が欲しい)
|
||
-------- --------
|
||
= 00000010 = 00000010
|
||
.fi
|
||
.PP
|
||
この AND 操作は、ACK や他の TCP プロトコルビットが
|
||
セットされていようといまいと、結果は同じです。
|
||
AND 用の値の 10 進数表現と、この操作の結果の 10 進数値は、
|
||
共に 2 (2 進数値 00000010) であり、
|
||
SYN がセットされているパケットには次の関係が成立します:
|
||
.IP
|
||
( ( 第 13 オクテットの値 ) AND ( 2 ) ) == ( 2 )
|
||
.PP
|
||
ここで、\fItcpdump\fP フィルタ式は次のようになることが分かります:
|
||
.RS
|
||
.B
|
||
tcpdump -i xl0 'tcp[13] & 2 == 2'
|
||
.RE
|
||
.PP
|
||
シングルクォートもしくはバックスラッシュを使用して、AND (&') 特殊文字を
|
||
シェルから隠す必要があることに注意してください。
|
||
.HD
|
||
.B
|
||
UDP パケット
|
||
.LP
|
||
UDP フォーマットは、以下の rwho パケットで例示します。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\f(CWactinide.who > broadcast.who: udp 84\fP
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
これは、ホスト \fIactinide\fP の \fIwho\fP ポートが UDP データグラムを
|
||
インターネットブロードキャストアドレスであるホスト \fIbroadcast\fP の
|
||
\fIwho\fP ポートに対して送信していることを意味します。本パケットは、
|
||
84 バイトのユーザデータを含みます。
|
||
.LP
|
||
いくつかの UDP サービスは(始点もしくは終点のポート番号から)種
|
||
類の判断が可能で、さらに上位レベルのプロトコル情報が出力されます。
|
||
ドメインネームサービス要求 (RFC1034/1035)、そして、Sun RPC 呼びだし
|
||
(RFC1050) を用いた NFS サービスなどがこの条件に該当します。
|
||
.HD
|
||
UDP ネームサーバ要求
|
||
.LP
|
||
\fI(注意:以下の記述は、RFC1035 に記述されている
|
||
ドメインサービスプロトコルの知識があることを前提に書かれています。もしこ
|
||
れらの知識がない場合には、以下の記述は未知の言語で書かれているかのよう
|
||
に見えるでしょう。)\fP
|
||
.LP
|
||
ネームサーバ要求は、以下のような表示になります。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fIsrc > dst: id op? flags qtype qclass name (len)\fP
|
||
.sp .5
|
||
\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
ホスト \fIh2opolo\fP は、\fIhelios\fP 上のドメインサーバに対して
|
||
\fIucbvax.berkeley.edu\fP のホスト名に対応するアドレスレコード (qtype=A)
|
||
を問い合わせています。
|
||
問い合わせの ID は `3' であり、`+' は\fI再帰要求\fPフラグが設定されて
|
||
いることを意味します。問い合わせの長さは 37 バイトであり、この中に UDP および
|
||
IP のプロトコルヘッダの長さは含みません。質問操作は普通の操作 (\fIQuery\fP)
|
||
であり、op フィールドは省略されます。op が他のいずれかであった場合、
|
||
その op は `3' と `+' の間に表示されます。
|
||
これと同様に、qclass は普通のもの (\fIC_IN\fP) であり、省略されます。
|
||
他の qclass が入った場合、`A' の直後に表示されます。
|
||
.LP
|
||
少数の変則的なパケットは検査され、カギカッコで囲まれた付加
|
||
フィールドにその結果が表示されます。問い合わせに返答が
|
||
あったとき、オーソリティレコードもしくは追加レコードのセクション
|
||
.IR ancount ,
|
||
.IR nscount ,
|
||
.I arcount
|
||
のいずれかが、`[\fIn\fPa]', `[\fIn\fPn]', `[\fIn\fPau]' のような形式で
|
||
表示されます。\fIn\fP は、それぞれの個数です。
|
||
応答ビットのいずれかが設定されている (AA, RA, rcode のいずれか) 場合、
|
||
もしくは「0 でなければならない」ビットが 2 バイト目と 3 バイト目に設定されてい
|
||
る場合には、`[b2&3=\fIx\fP]' が出力されます。\fIx\fP は、ヘッダの 2 バイト
|
||
目および 3 バイト目の値を 16 進で表したものです。
|
||
.HD
|
||
UDP ネームサーバ応答
|
||
.LP
|
||
ネームサーバ応答の形式は、以下の通りです。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
|
||
.sp .5
|
||
\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
|
||
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の例は、\fIh2opolo\fP からの質問 ID 3 の要求に対し、\fIhelios\fP が
|
||
3 つのアンサーレコード、3 つのネームサーバレコード、そして 7 つの
|
||
追加レコードを持っているパケットで返答しているというものです。
|
||
最初のアンサーレコードは、タイプ A (アドレス) であり、そのデータは
|
||
IP アドレス 128.32.137.3 です。UDP と IP のヘッダを除いた総サイズは
|
||
273 バイトです。
|
||
A レコードのクラス (C_IN) と同様に, op (Query) および応答コード
|
||
(NoError) は、省略されます。
|
||
.LP
|
||
2 つめの例は、\fIhelios\fP が質問 ID 2 の要求に対し、存在しない
|
||
ドメイン (NXDomain) という返答コードとともに、0 個のアンサーレコード、1 つ
|
||
のネームサーバレコード、そして 0 個のオーソリティレコードを含んだ
|
||
レスポンスを返しています。`*' は、\fIauthoritative answer\fP ビットが設定され
|
||
ていることを示します。
|
||
アンサーレコードがないため、型、クラス、データは出力されません。
|
||
.LP
|
||
出力される可能性のある他のフラグキャラクタは、`\-' (再帰利用,RA,が
|
||
設定されていない)および `|' (メッセージ切捨て, TC, が設定されている) です。
|
||
`question' セクションに含まれるエントリがちょうど 1 つでない場合には、
|
||
`[\fIn\fPq]' が出力されます。
|
||
.LP
|
||
ネームサーバ要求および応答は、大きくなる傾向にあり、デフォルトの
|
||
\fIsnaplen\fP の値である 68 バイトの長さは、パケットを捕捉してその内容を
|
||
表示するには十分でないかも知れないことに注意して下さい。
|
||
もしネームサーバトラフィックの調査を真剣に
|
||
行なおうとするならば、\fB\-s\fP オプションを用いて、\fIsnaplen\fP を増やし
|
||
て下さい。自分の経験上、`\fB\-s 128\fP' で十分使い物になります。
|
||
|
||
.HD
|
||
SMB/CIFS のデコード
|
||
.LP
|
||
現在の \fItcpdump\fP は、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) が書きました。
|
||
|
||
.HD
|
||
NFS 要求と応答
|
||
.LP
|
||
Sun NFS (Network File System) 要求および応答は、以下のように
|
||
表示されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fIsrc.xid > dst.nfs: len op args\fP
|
||
\fIsrc.nfs > dst.xid: reply stat len op results\fP
|
||
.sp .5
|
||
\f(CW
|
||
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
|
||
\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の行では、ホスト \fIsushi\fP が ID\fI6709\fP のトランザクションを
|
||
\fIwrl\fP に送信します (始点ホストに続く数字はトランザクション ID
|
||
であり、始点ポート番号で\fIない\fPことに注意して下さい)。要求
|
||
サイズは、UDP および IP ヘッダのサイズを除いて 112 バイトです。操作は、
|
||
ファイルハンドル (\fIfh\fP) 21,24/10.731657119 に対する \fIreadlink\fP
|
||
(シンボリックリンク読み込み) です。
|
||
(この例のように運が良ければ、ファイルハンドルはデバイスのメジャー、
|
||
マイナー番号のペアと、それに続く inode 番号と世代番号と解釈することがで
|
||
きます。)
|
||
\fIwrl\fP はリンクの内容とともに `ok' と返答しています。
|
||
.LP
|
||
3 行めでは、\fIsushi\fP は \fIwrl\fP に対し、ファイルハンドル
|
||
9,74/4096.6878 のディレクトリ中の `xcolors' ファイルの検索を要求していま
|
||
す。出力されたデータは、操作の型に依存することに注意して下さい。本形式
|
||
は、NFS のプロトコル仕様とともに読めば、それ自身を見れば分かるよう
|
||
に意図して作成されています。
|
||
.LP
|
||
\-v (verbose, 冗長) フラグがある場合、追加情報が出力されます。
|
||
例えば
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\f(CW
|
||
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
|
||
\fP
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
(\-v は IP ヘッダの TTL と ID と長さとフラグメンテーションフィールドも出力し
|
||
ますが、この例では省略しています。) 最初の行では、\fIsushi\fP は
|
||
\fIwrl\fP に対してファイル 21,11/12.195 のオフセット 24576 バイト目か
|
||
ら 8192 バイトを読むように要求しています。\fIwrl\fP は `ok' と返答してい
|
||
ます。2 行めに示したパケットは応答の最初のフラグメントなので、1472
|
||
バイトしかありません (その他のデータは継続するフラグメント中に続きます
|
||
が、これらのフラグメントは NFS ヘッダも UDP ヘッダさえも持たないので、使わ
|
||
れるフィルタリングの表現によっては出力されないでしょう)。\-v フラグがあ
|
||
るのでいくつかのファイル属性 (ファイルデータに追加されて返されてくる) が
|
||
出力されます。それらはファイルの型 (普通のファイルなら ``REG'')、(8 進数
|
||
表現の) ファイルモード、uid と gid、そしてファイルの大きさです。
|
||
.LP
|
||
\-v フラグが 2 回以上指定されると、さらに詳しい情報が出力されます。
|
||
.LP
|
||
NFS 要求は非常に大きなデータになるため、\fIsnaplen\fP を大きくし
|
||
ないと詳しい出力は得られません。NFS トラフィックを監視するには、
|
||
`\fB\-s 192\fP' と指定してみて下さい。
|
||
.LP
|
||
NFS 応答パケットは RPC 操作であることを明示的には示しません。その代わ
|
||
り、\fItcpdump\fP は「最近の」要求を追跡して、トランザクション ID を用い
|
||
て応答と照合します。応答が対応する要求のすぐ後に続かないと、解
|
||
析することはできません。
|
||
.HD
|
||
AFS の要求と応答
|
||
.LP
|
||
Transarc AFS (Andrew File System) の要求と応答は次のように表示されます:
|
||
.HD
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fIsrc.sport > dst.dport: rx packet-type\fP
|
||
\fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
|
||
\fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
|
||
.sp .5
|
||
\f(CW
|
||
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
|
||
\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の行では、ホスト elvis が RX パケットを pike に送っています。
|
||
これは、fs (ファイルサーバ) サービスへの RX データパケットであり、
|
||
RPC 呼び出しの開始です。
|
||
この RPC 呼び出しはリネーム (改名) であり、
|
||
古いディレクトリファイル ID 536876964/1/1 と古いファイル名 `.newsrc.new'、
|
||
新しいディレクトリファイル ID 536876964/1/1 と新しいファイル名 `.newsrc' で
|
||
呼び出しています。
|
||
ホスト pike は、RPC 応答をリネーム呼び出しに対して返します
|
||
(データパケットであり、アボートパケットではないため、これは成功しました)。
|
||
.LP
|
||
一般的には、AFS RPC の RPC 呼び出し名だけは最低限デコードされます。
|
||
ほとんどの AFS RPC は、少ななくともいくらかの引数がデコードされます
|
||
(一般的には「興味のある」引数のみであり、興味についてはある定義によります)。
|
||
.LP
|
||
書式は、自明となることを意図していますが、
|
||
AFS および RX の動作に親しみのない方々にとっては有用ではないかもしれません。
|
||
.LP
|
||
-v (冗長) フラグを 2 度指定すると、
|
||
確認応答パケットと追加のヘッダ情報を表示します。
|
||
これは、RX 呼び出し ID、呼び出し番号、シーケンス番号、
|
||
シリアル番号、RX パケットフラグといったものです。
|
||
.LP
|
||
-v フラグを 2 度指定すると、追加情報が表示されます。
|
||
これは、RX 呼び出し ID、呼び出し番号、RX パケットフラグといったものです。
|
||
MTU ネゴシエーション情報も、RX 確認応答パケットから表示されます。
|
||
.LP
|
||
-v フラグを 3 度指定すると、
|
||
セキュリティインデックスとサービス ID を表示します。
|
||
.LP
|
||
アボートパケットに対しては、エラーコードが表示されます。
|
||
ただし、Ubik ビーコンパケットは例外です
|
||
(Ubik プロトコルでは、アボートパケットは、肯定投票に使用されるからです)。
|
||
.LP
|
||
AFS 要求は非常に大きく、
|
||
\fIsnaplen\fP を増やさなければ多くの引数が表示されないことに注意してください。
|
||
AFS トラフィックを見るには `\fB-s 256\fP' を試してみてください。
|
||
.LP
|
||
AFS 応答パケットは、明示的には RPC 操作を識別しません。
|
||
代りに \fItcpdump\fP が「最近の」要求の追跡を行い、
|
||
応答に対応する要求のマッチングを、
|
||
呼び出し番号とサービス ID を使用して行います。
|
||
応答パケットが対応する要求パケットに近くないと、
|
||
パーズできないかもしれません。
|
||
|
||
.HD
|
||
KIP Appletalk (DDP in UDP)
|
||
.LP
|
||
UDP データグラムでカプセル化された Appletalk DDP パケットは、カプセル化
|
||
を解かれ、DDP パケットとしてダンプされます (全ての UDP ヘッダ情報は破棄
|
||
されます)。
|
||
ファイル
|
||
.I /etc/atalk.names
|
||
が、Appletalk ネットワークおよびノード番号を名前に変換するのに用い
|
||
られます。
|
||
本ファイルの内容は、以下のように記述されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fInumber name\fP
|
||
|
||
\f(CW1.254 ether
|
||
16.1 icsd-net
|
||
1.254.110 ace\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の 2 行は、Appletalk ネットワーク名を決めています。3 行めは、
|
||
特定のホストの名前を決めています (ホストは、3 オクテット目の有無で
|
||
ネットワークと区別されます。ネットワーク番号は、2 オクテットの数字
|
||
から、ホスト番号は 3 オクテットの数字から構成される必要があります。)
|
||
数字と名前は、空白文字もしくはタブ文字で区切られます。この
|
||
.I /etc/atalk.names
|
||
ファイルは、空行もしくは、`#' 文字で始まるコメント行を含んでもかま
|
||
いません。
|
||
.LP
|
||
Appletalk アドレスは、以下のように表示されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fInet.host.port\fP
|
||
|
||
\f(CW144.1.209.2 > icsd-net.112.220
|
||
office.2 > icsd-net.112.220
|
||
jssmag.149.235 > icsd-net.2\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
(もし、この
|
||
.I /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 では
|
||
ノード名とネットワーク名を区別する方がよいことが分かります)。
|
||
.LP
|
||
NBP (name binding protocol) および ATP (Appletalk transaction protocol)
|
||
パケットでは、その内容は解釈されます。
|
||
他のプロトコルは、プロトコル名 (もしくは、プロトコルが登録されていない場
|
||
合には、プロトコル番号) およびパケットサイズをダンプします。
|
||
|
||
\fBNBP パケット\fP は、以下のような形式で表示されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\s-2\f(CWicsd-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\fR\s+2
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
最初の行は、レーザライタの名前検索要求であり、ネットワーク icsd のホスト
|
||
112 から送られ、ネットワーク jssmag へとブロードキャストされています。
|
||
検索のための nbp の ID は 190 です。
|
||
次の行は jssmag.209 からの、この要求の応答 (同じ ID を持つことに注意して下さ
|
||
い) で、 ポート 250 に登録された RM1140 という名前のレーザライタがあると答
|
||
えています。
|
||
3 行めは、同じ要求に対する他のホストからの応答で、
|
||
ホスト techpit が、ポート 186 に登録されたレーザライタ "techpit" を持ってい
|
||
ると答えています。
|
||
|
||
\fBATP パケット\fP の形式は、以下のように表示されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\s-2\f(CWjssmag.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\fR\s+2
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
jssmag.209 は、ホスト helios に対し最大8個 ('<0-7>') までのパケットを
|
||
要求することで、トランザクション ID 12266 を開始します。行の最後の 16 進数は、
|
||
要求の中の「ユーザデータ」のフィールドの値です。
|
||
.LP
|
||
helios は、8 つの 512 バイトのパケットで応答しています。トランザクション ID
|
||
の後につづく「:数」は、パケットシーケンス番号を、括弧中の数値は ATP ヘッダ
|
||
を除いたパケット中のデータ量を示しています。パケットシーケンス 7 のところ
|
||
の `*' は、EOM ビットが設定されていることを示しています。
|
||
.LP
|
||
jssmag.209 は、パケットシーケンス番号 3 と 5 のパケットの再送要求をしています。
|
||
helios はそれらを再送し、その後 jssmag.209 はトランザクションを解放します。
|
||
最後の行で、jssmag.209 は次の要求を開始します。この要求の表示
|
||
で付加されている `*' は、XO (`exactly once') が設定されていないことを示します。
|
||
|
||
.HD
|
||
IP フラグメンテーション
|
||
.LP
|
||
フラグメントのあるインターネットデータグラムは、以下のように表示されます。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
|
||
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
(最初の形式では、まだフラグメントがあることを示し、2 番めの形式は、
|
||
これが最後のフラグメントであることを示しています。)
|
||
.LP
|
||
\fIid\fP は、フラグメント ID です。\fIsize\fP は、フラグメントサイズを
|
||
バイト単位であらわしたものです。ただし IP ヘッダサイズは含みません。
|
||
\fIoffset\fP は、元のデータグラムでの本フラグメントのオフセットをバイト
|
||
単位であらわしたものです。
|
||
.LP
|
||
フラグメント情報は、各フラグメントごとに表示されます。最初の
|
||
フラグメントには、上位レベルのプロトコルヘッダが含まれるので、フラグ情
|
||
報がプロトコル情報の後に表示されます。2 つ目以降のフラグメントについて
|
||
は、上位レベルのプロトコルヘッダを含まないので、フラグ情報は始点およ
|
||
び終点アドレスの後ろに表示されます。
|
||
例えば、これは arizona.edu から lbl-rtsg.arpa への CSNET 接続での ftp
|
||
の様子の一部分ですが、どうやら 576 バイト以上のデータグラムを扱えないよ
|
||
うです。
|
||
.RS
|
||
.nf
|
||
.sp .5
|
||
\s-2\f(CWarizona.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\fP\s+2
|
||
.sp .5
|
||
.fi
|
||
.RE
|
||
注意すべきことがいくつかあります。まず最初に、2 行目は
|
||
ポート番号を含みません。これは、TCP プロトコル情報は、最初のフラグメント
|
||
に全て入っており、後のフラグメントを出力する時にはポート番号やシーケンス
|
||
番号を知る術がないからです。
|
||
次に、最初の行の TCP シーケンス情報は、パケットが 308 バイトのユーザデータ
|
||
を持ってるかのように表示されますが、実際には 512 バイトのユーザデータを
|
||
持っています (308 バイトが最初のフラグ分で、204 バイトが 2 番目のフラグ分で
|
||
す)。シーケンススペースの穴をさがしたり、パケットの ack の対応が正しい
|
||
かをこのデータで見ようとしてはいけません。
|
||
.LP
|
||
フラグメント不可フラグが設定されたパケットは、最後の部分に \fB(DF)\fP と
|
||
印が付けられます。
|
||
.HD
|
||
タイムスタンプ
|
||
.LP
|
||
デフォルトでは、すべての出力行は最初にタイムスタンプが出力されます。
|
||
タイムスタンプは、以下の形式で、現在のクロックタイムを表示します
|
||
.RS
|
||
.nf
|
||
\fIhh:mm:ss.frac\fP
|
||
.fi
|
||
.RE
|
||
そして、クロックの精度は、カーネルクロックの精度に依存します。
|
||
タイムスタンプは、カーネルが最初にパケットを見つけた時間を反映します。
|
||
イーサネットインタフェースがケーブルからパケットを取り出してカーネルが
|
||
「新規パケット」割り込みを受け付けるまでのタイムラグなどは補正されません
|
||
.SH 関連項目
|
||
bpf(4), pcap(3)
|
||
.SH 作者
|
||
元々の作者は次の通りです:
|
||
.LP
|
||
Van Jacobson,
|
||
Craig Leres and
|
||
Steven McCanne, all of the
|
||
Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
|
||
.LP
|
||
現在は tcpdump.org で管理されています。
|
||
.LP
|
||
現在のバージョンは http で次のところから取得可能です:
|
||
.LP
|
||
.RS
|
||
.I http://www.tcpdump.org/
|
||
.RE
|
||
.LP
|
||
元々の配布は匿名 ftp で次のところから取得可能です:
|
||
.RS
|
||
.I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
|
||
.RE
|
||
.LP
|
||
IPv6/IPsec サポートは WIDE/KAME プロジェクトが追加しました。
|
||
本プログラムは、特定の構成においては、
|
||
Eric Young の SSLeay ライブラリを使用します。
|
||
.SH バグ
|
||
問題、バグ、希望の機能拡張等については次のところに送ってください:
|
||
.LP
|
||
.RS
|
||
tcpdump-workers@tcpdump.org
|
||
.RE
|
||
.LP
|
||
ソースコードの寄贈等については次のところに送ってください:
|
||
.LP
|
||
.RS
|
||
patches@tcpdump.org
|
||
.RE
|
||
.LP
|
||
NIT では、外に出ていくトラフィックを観察できません。BPF ならできます。
|
||
後者を用いることを推奨します。
|
||
.LP
|
||
2.0[.x] カーネルの Linux システムにおいて:
|
||
.IP
|
||
ループバックデバイス上のパケットは 2 度観測されます。
|
||
.IP
|
||
カーネル内でのパケットフィルタリングは不可能であり、
|
||
全パケットがカーネルからコピーされてユーザモードでフィルタされます。
|
||
.IP
|
||
スナップショットの長さ部分ではなく、パケット全体が、
|
||
カーネルからコピーされます
|
||
(2.0[.x] のパケット捕捉機構は、
|
||
パケットの一部をユーザランドへコピーするように依頼されると、
|
||
パケットの正しい長さを報告しません。
|
||
このため、ほとんどの IP パケットが
|
||
.BR tcpdump
|
||
でエラーとなってしまいます)。
|
||
.LP
|
||
2.2 以降のカーネルにアップグレードすることをお勧めします。
|
||
.LP
|
||
IP フラグメントを再構成するか、もしくは少なくとも上位プロトコルの正し
|
||
いデータサイズを計算するように設計しなおす必要があります。
|
||
.LP
|
||
ネームサーバについての逆引きについては、正しくダンプされません。
|
||
実際の要求ではなく、(empty) クエスチョンセクションが、
|
||
アンサーセクションに出力されます。
|
||
逆引きについてはそれ自体がバグであると信じ、
|
||
\fItcpdump\fP ではなく逆引きを要求する
|
||
プログラムを修正するべきと考える人達もいます。
|
||
.LP
|
||
夏時間との変更の時にパケットトレースを行うと、タイムスタンプは変更後の
|
||
時刻とはずれてしまいます (時間変化は無視されます)。
|
||
.LP
|
||
FDDI ヘッダおよび Token Ring ヘッダを操作するようなフィルタの表現においては、
|
||
全ての FDDI パケットおよび Token Ring パケットは
|
||
SNAP でカプセル化された Ethernet パケットであると仮定します。
|
||
これは、IP, ARP, DECNET フェーズ 4 については正しいですが、ISO の CLNS 等の
|
||
プロトコルについては正しくありません。したがって、フィルタ表現に正しく
|
||
マッチしないようなパケットを偶然に受け入れてしまうことがあります。
|
||
.LP
|
||
Token Ring ヘッダ以外のフィールドに対するフィルタ式は、
|
||
始点経路制御された Token Ring パケットを正しく扱わないことがあります。
|
||
.LP
|
||
.BR "ip6 proto"
|
||
はヘッダチェーンを追跡すべきですが、現在のところはそうなっていません。
|
||
このために
|
||
.BR "ip6 protochain"
|
||
が提供されています。
|
||
.LP
|
||
例えば \fBtcp[0]\fP といったトランスポート層ヘッダに対する演算は、
|
||
IPv6 パケットに対しては動作しません。
|
||
IPv4 パケットだけを見ます。
|