|
tcpdump − ネットワーク上のトラフィックデータのダンプ |
|
tcpdump [ −AdDeflLnNOpqRStuUvxX ] [ −c count ] |
|
[ −C file_size ] [ −F file ] |
|
[ −i interface ] [ −m module ] [ −r file ] |
|
[ −s snaplen ] [ −T type ] [ −w file ] |
|
[ −E spi@ipaddr algo:secret,... ] |
|
[ −y datalinktype ] [ −y datalinktype ] [ expression ] |
|
tcpdump は、オプションで指定されたネットワークインタフェース上で取得可 能なパケットのヘッダのうち expression にマッチするものを出力します。 パ ケッ トデータを後で分析するためファイルに保存するよう、 −w フラグで実行 することもできます。また、 −r フラグで、ネットワークインタフェースか ら の パケットではなく、ファイルに保存されたパケットから読み込むことができ ます。すべての場合に、 expression にマッチするパケットだけ、 tcpdump に よって処理されます。 tcpdump は、 −c フラグで実行しない場合、SIGINT シグナル ( 例えば、一般 的な手法として割り込み文字列である control-C の入力) か SIGTERM シグ ナ ル (一般的な手法として kill(1) コマンド) によって割り込みがあるまで、パ ケットを捕捉し続けます。 −c フラグで実行する場合は、 SIGINT シグナル や SIGTERM シ グナルで割り込みされるか、指定されたパケット数まで処理しま す。 tcpdump がパケットの捕捉を終了したとき、以下の合計を表示します。 |
|
packets ‘‘captured’’ (これは tcpdump が受信し処理したパケット 数 です); packets ‘‘received by filter’’ (この意味は、 tcpdump を実行して いる OS に依存しますし、おそらく OS のコンフィギュレーション方法 にも依存するでしょう。 filter がコマンドラインで指定された場合、 ある OS では filter expression に一致したかどうかに関わらず、 ま た filter expression に一致したものであっても、 tcpdump が読み込 み、処理したものであるかどうかに関わらずパケットを数えます。別の OS で は、filter expression に一致したパケットのみ数えますが、 tcpdump が読み込み、処理したものであるかどうかには関わりません。 ま た別の OS では、filter expression によって一致し、 tcpdump に よって処理されたパケットのみを数えます); packets ‘‘dropped by kernel’’ (OS がアプリケーションにその情報を 報 告する場合には、バッファスペースの不足により、 tcpdump が走っ ている OS のパケット捕捉制御機構から、落ちてしまったパケットの数 です。それ以外の場合には、0 が表示されます。) |
|
(Mac OS X を含む) 大抵の BSD や Digital/True64 UNIX のような SIGINFO シ グナルがサポートされているプラットホームでは、SIGINFO シグナルを受信 し た と き、 そ れ ら の 合計を表示して、パケットの捕捉を引き続き行います (SIGINFO シグナルは、例えば典型的には ‘‘status’’ 文字であ る control-T の 入 力 に よっ て生成されます。しかし Mac OS X などいくつかのプラット フォームでは、‘‘status’’ 文字はデフォルトでは設定されていませんので、こ れを使用するには stty(1) によって設定する必要があります)。 ネットワークインタフェースからパケットを読むには、権限を必要とします。 |
|
SunOS 3.x、4.x 上の NIT ないし BPF の場合: |
|
/dev/nit ないし /dev/bpf* への読み込みアクセス権が必要です。 |
|
Solaris 上の DLPI の場合: |
|
/dev/le 等のネットワーク仮想デバイスへの読み書きアクセス権が必 要です。少なくとも Solaris のいくつかの バー ジョ ン 上 で は、 tcpdump が promiscuous モードで捕捉するには、この条件だけでは不 十分です。それらの Solaris のバージョンでは、root になる必要 が あ り ま す。 もしくは promiscuous モードで捕捉するには root に setuid されてインストールされている場合のみ tcpdump の実行が 可 能 に な ります。多くの (おそらくすべての) インタフェースにおい て、promiscuous モードで捕捉しないと、送出されるパケットは見 る こ とができないでしょう。そのため、promiscuous モードで捕捉が行 われない場合は、あまり役に立たないであろうことに注意してくだ さ い。 |
|
HP-UX 上の DLPI の場合: |
|
使用者が root であるか、 tcpdump が root に setuid されてインス トールされている場合のみ実行可能です。 |
|
IRIX 上の snoop の場合: |
|
使用者が root であるか、 tcpdump が root に setuid されてインス トールされている場合のみ実行可能です。 |
|
Linux の場合: |
|
使用者が root であるか、 tcpdump が root に setuid されてインス トールされている場合のみ実行可能です (ただし、使用している ディ ストリビューションが、 CAP_NET_RAW などのケーパビリティビットを サポートするカーネルを持ち、これらのケーパビリティビットを特 定 の アカウントに与えることができ、そのユーザがログインした時の最 初のプロセスにそのビットがセットされるようなコードを持ってい る 場 合は、この限りではありません。その際には、パケットを捕捉する ためには CAP_NET_RAW が、そして例えば −D フラグによって ネッ ト ワークデバイスを列挙するためには CAP_NET_ADMIN が必要です)。 |
|
ULTRIX および Digital UNIX/Tru64 UNIX の場合: |
|
どのユーザも tcpdump を使用して、ネットワークトラフィックを捕捉 できます。しかしながら、捕捉を行うインタフェースに対して、 スー パ ユーザが pfconfig(8) を用いて promiscuous モードの操作を許可 しない限り、どのユーザも (スーパユーザでさえも)、そ の イ ン タ フェー ス において promiscuous モードで捕捉を行うことはできませ ん。また、捕捉を行うインタフェースに対して、 スー パ ユー ザ が pfconfig を用いて copy-all モードの操作を許可しない限り、どの ユーザも (スーパユーザでさえも)、そのインタフェースにおいてマシ ン が送受信するユニキャストトラフィックを捕捉することはできませ ん。したがって、あるインタフェースにおいて 有用なパケットの捕捉 を 行うには、promiscuous モードか copy-all モードの操作、もしく は両モードの操作が、そのインタフェースにおいて有効になってい る 必要があります。 |
|
BSD の場合 (Mac OS X を含む): |
|
/dev/bpf* への読み込みアクセス権が必要です。ただし devfs を使用 する BSD (Mac OS X も含まれる) では、単にスーパユーザ権限を持つ ユーザが BPF デバイスの所有者やパーミッションを設定するだけでは 十分でないかも知れません。なぜなら、システムが起動する 度 に 毎 回、 所有者やパーミッションを設定しなければならないからです。起 動時に設定する機能を備えた devfs を使っているシステムでは、その た めの設定も必要になるかも知れませんし、その機能がないシステム では、何らかの方法を使って、起動時にその設定が行われるように す る必要があるでしょう。 |
|
保存されたパケットファイルを読むには、権限を必要としません。 |
|
−A |
各々のパケット (からリンクレベルのヘッダを除いたもの) を ASCII で表示します。 Web ページを捕捉する場合に便利です。 |
||
|
−c |
count で指定した数のパケットを受信した後に終了します。 |
||
|
−C |
保存ファイルに raw パケットを書き込む前に、現在のファイルが file_size より大きいかどうかをチェックします。もし大きいなら、 現在の保存ファイルを閉じて新しいものを開きます。付けられる ファ イル名は、最初の保存ファイルを除く 2 番目以降の保存ファイルから −w フラグで指定されたファイル名の後にそれぞれ番号がつきます。そ の 番 号は、2 から始まり順に大きくなります。 file_size の単位は 100 万バイト (1,000,000 バイト。1,048,576 バイトのことではない) です。 |
||
|
−d |
解釈されたパケットマッチングコードを読みやすい形に整形した 後、標準出力にダンプして停止します。 |
||
|
−dd |
C プログラムの断片の形でパケットマッチングコードをダンプし ます。 |
||
|
−ddd |
( 先頭に個数を付加した) 10 進数の形でパケットマッチング コードをダンプします。 |
||
|
−D |
そのシステム上で利用可能で、 tcpdump がパケットを捕捉できる ネッ トワークインタフェースのリストを出力します。それぞれのネッ トワークインタフェースに対して、番号とインタフェース名、そし て 可 能であればそのインタフェースの説明を表示します。ネットワーク インタフェース名、および番号は、捕捉を行うインタフェース を −i フラグで指定する際に使用できます。 |
|
これは、インタフェースをリストするコマンドを持たないシステムにお いて有用です (例えば、Windows システムや ifconfig −a を持たな い UNIX シ ステム)。また番号は、Windows 2000 以降のシステムのよう に、インタフェース名が何か複雑な文字列の場合に便利です。 tcpdump が pcap_findalldevs() 関数を持たない古い バー ジョ ン の libpcap を使って構築された場合、 −D フラグはサポートされません。 |
|
−e |
各ダンプ行ごとに、リンクレベルのヘッダを出力します。 |
||
|
−E |
spi@ipaddr algo:secret を、addr 宛でセキュリティパラメー タ イ ンデックスの値 spi を含む IPsec ESP パケットの解読に使用しま す。この組み合わせを、コンマか改行で区切って繰り返し指定する こ とができます。 |
|
今 では IPv4 の ESP パケットに対する secret が設定できるようにな りました。 アルゴ リ ズ ム は des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, none のいずれかです。デフォルトは des-cbc です。パ ケット解読能力は、 tcpdump が暗号機能付きでコンパイルされた場 合 のみ存在します。 secret は、ESP 秘密鍵の ASCII テキストです。 0x で始まっている場 合、16 進数値として読み込まれます。 本オプションは、RFC1827 ESP ではなく、RFC2406 ESP を仮定します。 本オプションは、デバッグ専用であり、本当の「秘密」鍵に対する使用 は勧められません。 IPsec 秘密鍵をコマンドラインに置くと、 ps(1) 等によって他者に見えてしまいます。 上 記 の構文に加えて、tcpdump が指定されたファイルを読み込むのに file name という構文が使用できます。ファイルは、最初の ESP パ ケットを受信した際にオープンされます。そのため、tcpdump に与えら れているであろうすべての特別なパーミッションは、それまでに破棄し ておくべきでしょう。 |
|
−f |
外部ホストの IPv4 アドレスについては、シンボルでなく数値で 表示します (本オプションは、Sun の NIS サーバに重大な障害が発生 す るのを回避することを意図しています。— 通常は、Sun の yp サー バは、ローカルに存在しない IP アドレスを永久に変換しつづけて ハ ングします)。 |
|
外部ホストの IPv4 アドレスに対する検査は、捕捉を行っているインタ フェースの IPv4 アドレスとネットマスクを用いて行われます。もし、 そのアドレス、またはネットマスクが無効だった場合、このオプション は正しく動作しません。これは、捕捉を行っているインタフェースにア ド レ ス、もしくはネットマスクが設定されていなかったり、または 2 つ以上のインタフェース上で捕捉を行える Linux の "any" イ ン タ フェースを使用している場合に起こります。 |
|
−F |
フィルタの表現として、file に記述してある内容を用います。コ マンドラインで指定された追加表現は、無視されます。 |
||
|
−i |
interface で指定されたインタフェースを監視します。指定さ れ な い場合には、tcpdump はシステムインタフェースリストの中で最も 小さい番号の稼働中のものを検索し、監視するインタフェースとし て 設定します (ループバックインタフェースは検索しません)。この動作 は、最初にインタフェースが選択された時点で終了します。 |
|
2.2 以降のカーネルの Linux システムでは、 interface 引数 ‘‘any’’ を指定して全インタフェースからのパケットを捕捉可能です。 ‘‘any’’ デバイスでの捕捉は、promiscuous モードではないことに注意してくだ さい。 −D フラグがサポートされている場合、このフラグで表示されるインタ フェース番号は interface 引数に使用できます。 |
|
−l |
標準出力を行バッファリングにします。データを捕捉しつつ、 そ のデータを見たい場合には、本オプションは有効です。例えば |
|
‘‘tcpdump −l | tee dat’’ や ‘‘tcpdump −l > dat & tail −f dat’’ のように使用します。 |
|
−L |
インタフェースの既知のデータリンクタイプを列挙し、終了し ま す。 |
||
|
−m |
SMI MIB モジュールの定義を、ファイル module からロードしま す。複数の MIB モジュールを tcpdump にロードするために、複数 回 このオプションを使用することができます。 |
||
|
−n |
アドレス (IP アドレスやポート番号など) を名前に変換しませ ん。 |
||
|
−N |
ホスト名のうち、ドメイン名の表示をしません。例えば、本オ プ ショ ン を 指定すると、‘‘nic.ddn.mil’’ とは表示されず、かわりに ‘‘nic’’ とだけ表示します。 |
||
|
−O |
パケットマッチングコードのオプティマイザを動かしません。 本 オ プションは、オプティマイザ中のバグを疑う場合にのみ有効なもの です。 |
||
|
−p |
ネットワークインタフェースを、promiscuous mode に設定しませ ん。 ネッ ト ワー ク イ ン タ フェー ス は、 何らかの理由により promiscuous mode に設定されることもあり得るということに注意して ください。ゆえに ‘-p’ オプションは、‘ether host {local-hw-addr} or ether broadcast’ の短縮形として使うことは出来ません。 |
||
|
−q |
素早い (静かな?) 出力を行ないます。出力する行を短くするため に、通常出力されるプロトコル情報の一部は出力されません。 |
||
|
−R |
ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に基いてい るものと仮定します。指定すると、tcpdump はリレー防止フィール ド を 表示しません。 ESP/AH 仕様にはプロトコルバージョンフィールド がありませんので、 tcpdump は ESP/AH プロトコルのバージョンを推 定できません。 |
||
|
−r |
パケットを、file で指定したファイル ( −w オプションで作成 されます) から読み込みます。file として‘‘-’’が指定された場合 は 標準入力が用いられます。 |
||
|
−S |
TCP シーケンス番号を相対番号ではなく、絶対番号で出力しま す。 |
||
|
−s |
デフォルトの 68 バイト (SunOS の NIT では最小値は実際 に は 96) ではなくて、 snaplen だけのデータを各パケットから取得しま す。68 バイトというデータ長は、IP, ICMP, TCP, UDP のパケット を 取得する分には十分ですが、ネームサーバや NFS のパケットについて はプロトコル情報が切り詰められることがあります (これに つ い て は、以後の説明を参照して下さい)。スナップショットが限られた量し かとれずに切り詰められたパケットは、出力に ‘‘[|proto]’’ とい う 文字列がいっしょに表示されます。 proto は、切り詰めが行われたプ ロトコルレベルの名前です。大きなスナップショットをとる 場 合 に は、 そ れ だけパケット処理の時間がかかるということと、パケット バッファリング用のバッファの量が減るということに注意してくだ さ い。 これにより、パケットが消失するかもしれません。snaplen の大 きさを、必要なプロトコル情報を取得できる最小の値にとどめるよ う に してください。 snaplen を 0 に設定すると、パケット全体の捕捉 に必要な長さを使用することを意味します。 |
||
|
−T |
"expression" により選択されたパケットを強制的に type で指定 されたタイプと解釈します。有効なタイプは、 aodv (アドホックオン デマンドディスタンスベクタープロトコル) cnfp (Cisco NetFlow プ ロトコル), rpc (リモートプロシージャコール) rtp (リアルタイムア プリケーションプロトコル) rtcp (リアルタイムアプリケーション 制 御 プロトコル) snmp (シンプルネットワークマネージメントプロトコ ル) tftp (トリビアルファイル転送プロトコル) vat (ビジュアルオー ディオツール) wb (ディストリビューテッドホワイトボード) です。 |
||
|
−t |
各ダンプ行のタイムスタンプを出力しません。 |
||
|
−tt |
各ダンプ行毎にタイムスタンプを人間が読みやすい形に変換せず に出力します。 |
||
|
−ttt |
直前のダンプ行と現在のダンプ行の差分 (マイクロ秒単位) を 表示します。 |
||
|
−tttt |
各ダンプ行で、デフォルト書式でタイムスタンプを表示し、そ の前に日付を付けます。 |
||
|
−u |
デコードされてない NFS 操作を出力します。 |
||
|
−U |
−w オプションで保存される出力を、「パケットバッファ」モード に します。つまり、出力バッファがいっぱいになった時のみ書き出す のではなく、各パケットが保存される度に出力ファイルに書き出し ま す。 |
|
tcpdump が pcap_dump_flush() 関数を持たない古いバージョンの libpcap を使って構築された場合、 −U フラグはサポートされません。 |
|
−v |
( 少しではありますが) 出力情報を増やします。例えば、IP パ ケット中の TTL、識別、全長、IP パケット中のオプションが表示され ま す。追加のパケットの完全性確認が有効になります。これは例えば IP および ICMP のヘッダのチェックサムです。 |
||
|
−vv |
さらに多くの情報を出力します。例えば、NFS の返答パケットの 追加フィールドや完全にデコードされた SMB パケットを出力します。 |
||
|
−vvv |
もっと多くの情報を出力します。例えば、telnet SB ... SE オ プションが完全に表示されます。 −X 付きでは、telnet オプションが 16 進数で表示されます。 |
||
|
−w |
受信した生パケットを、解析したり画面に出力したりせずに file で 指定したファイルに出力します。本オプションを用いて取得したパ ケットは −r オプションを用いることで情報を見るこ と が で き ま す。file で指定するファイル名が ‘‘-’’ の場合には、標準出力を用 います。 |
||
|
−x |
リンクレベルヘッダを除いた各パケットの内容を 16 進数で出 力 します。パケットサイズが snaplen バイトより小さい場合にはパケッ トの全部の内容を、それ以外の場合には、 snaplen バイト分のデータ を パ ケッ トごとに出力します。ここで出力されるのはリンク層のパ ケット全体であるため、パディングするようなリンク層 (例えば イー サ ネット) の場合、上位層のパケットが必要な長さよりも短かった時 にはパディングされたバイトも表示されることに注意してください。 |
||
|
−xx |
各々のパケットを、リンクレベルのヘッダも 含めて、16 進数で 表示します。 |
||
|
−X |
各々のパケット (からリンクレベルのヘッダを除いたもの) を、 16 進数と ASCII で表示します。新規プロトコルを解析するのに非 常 に便利です。 |
||
|
−XX |
各々のパケットを、リンクレベルのヘッダも 含めて、16 進数と ASCII で表示します。 |
||
|
−y |
パケット捕捉中に使用するデータリンクタイプ を datalinktype に設定します。 |
|
expression |
|
ダ ンプするパケットを選択します。expression が指定されない場合に は、ネットワーク上のすべてのパケットがダンプ対象になります。それ 以 外の場合には、expression の条件が真になるパケットのみダンプし ます。 expression は、1 つ以上の プリミティブから成り立ちます。プ リ ミ ティブは通常 1 つ以上の限定子のついた id (名前もしくは番号) から 成り立ちます。限定子は、3 種類あります。 |
|
型 |
限定子は id 名や番号が参照するものの種類を指します。 型 に は host, net, port があります。例えば、‘host foo’, ‘net 128.3’, ‘port 20’ のように用います。型限定子が指 定 されない場合には、 host が指定されたものとみなされます。 |
||
|
方向 |
限定子は、パケットが id へ出ていく方向か、 id から 来る方向か、もしくはその両方かという、特定の転送方向を指 定します。指定可能な方向は、 src, dst, src or dst, src and dst の 4 つです。例えば、‘src foo’, ‘dst net 128.3’, ‘src or dst port ftp-data’ のように指定します。もし方 向 限定子が指定されない場合には、 src or dst が指定されたも のとみなします。 SLIP や、‘‘any’’ や他のデバイスタイプを 用 いた Linux の ‘‘cooked’’ 捕捉モードのようなリンク層で は、必要な方向を指定するのに inbound や outbound 限定 子 を用いる事ができます。 |
|
プロトコル |
|
限定子は、特定のプロトコルに一致するパケットのみに制限し ます。プロトコルとして指定可能なもの は、 ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, iso, esis, isis, icmp, icmp6, tcp , udp です。 例 え ば ‘ether src foo’, ‘arp net 128.3’, ‘tcp port 21’ の ように使用します。もしプロトコル限定子が指定されない場合 には、上記のプロトコルのうち、型に矛盾しないすべてのもの が指定されたものとみなします。例えば ‘src foo’ は、‘(ip or arp or rarp) src foo’ (これが正しい形式でない事を除い て) と、‘net bar’ は ‘(ip or arp or rarp) net bar’ と 同 義 であり、また ‘port 53’ は ‘(tcp or udp) port 53’ と同 義です。 |
|
[‘fddi’ は実際には ‘ether’ の別名になっています。解析ではこれ ら を 「特 定のネットワークインタフェースで使われるデータリンクレベ ル」を意味するものとして同様に扱います。FDDI ヘッダはイーサ ネッ トに似た始点と終点アドレスを含み、そしてしばしばイーサネットに似 たパケット型を含むので、イーサネットのフィールドと同 じ よ う に FDDI の フィー ルドをフィルタリングできます。FDDI ヘッダは他の フィールドも含みますが、フィルタ表現の中で明示的にそれらを指定す ることはできません。 同様に、‘tr’ と ‘wlan’ は ‘ether’ の別名です。直前の段落における FDDI ヘッダに関する記述は、 Token Ring ヘッダや 802.11 無線 LAN ヘッ ダ に も適用されます。 802.11 ヘッダでは、終点アドレスが DA フィールドで、始点アドレスが SA フィールドです。 BSSID, RA, TA フィールドは検査されません。] 上記に追加して、いくつかの特別な「プリミティブ」キーワードがあり ます。これらのキーワードは gateway, broadcast, less, greater と 算術演算表現です。これらの後ろにパターンが続く事はありません。プ リミティブキーワードについては後述します。 より複雑なフィルタの表現は、プリミティブの結合に and, or, not を 用 い る ことで実現されます。例えば、 ‘host foo and not port ftp and not port ftp-data’ です。タイプ量を少なくするために、同一 の 限 定 子 リストは、省略することが可能です。例えば、‘tcp dst port ftp or ftp-data or domain’ は、 ‘tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain’ と同じ意味です。 許されるプリミティブは、以下の通りです。 |
|
dst host host |
|
IPv4/v6 パケットの終点フィールドが host で指定したものの 場合に、真となります。 host は、ホスト名もしくは IP アド レスです。 |
|
src host host |
|
IPv4/v6 パケットの始点フィールドが host で指定したものの 場合に、真となります。 |
|
host host |
|
IPv4/v6 パケットの始点フィールドもしくは終点フィールドが host で指定したものの場合に、真となります。上記の host プリミティブの表現には、 ip, arp, rarp, ip6 を以下のよう に付加することが可能です。 |
ip host host |
|
という表記は、 |
ether proto \ip and host host |
|
と同じ意味です。 host が複数の IP アドレスを持つホスト名 であった場合、それぞれのアドレスについて照合を検査 し ま す。 |
|
ether dst ehost |
|
イー サ ネッ トパケットの終点アドレスが ehost だった場合 に、真となります。 ehost は、/etc/ethers に記述された 名 前もしくはイーサネットアドレスの値が用いられます (イーサ ネットアドレスの形式については、 ethers(3N) を参照)。 |
|
ether src ehost |
|
イーサネットパケットの始点アドレスが ehost だっ た 場 合 に、真となります。 |
|
ether host ehost |
|
イーサネットパケットの始点アドレスもしくは終点アドレスが ehost だった場合に、真となります。 |
|
gateway host |
|
パケットが host で指定したアドレスのマシンをゲートウェイ としている場合に真となります。言い替えると、始点もしくは 終点のイーサネットアドレスが host であり、始点と終点のど ちらの IP アドレスも host でないということです。 host マ シンの host-name-to-IP-address (名前解 決) 制 御 機 構 (hosts ファ イ ル、DNS、NIS な ど) と マ シ ン の host-name-to-Ethernet-address (イーサネットアドレス解決) 制御機構 (/etc/ethers など) から見つけられる名前である必 要があります。 (同様な記述は、 |
ether host ehost and not host host |
|
です。この場合 host / ehost のどちらにも名前もしくは値を 用 い る こ とが可能になります。) この構文は、現在のとこ ろ、IPv6 が有効な構成では動作しません。 |
|
dst net net |
|
パケットの終点 IPv4/v6 アドレスが、 net で指定されたネッ ト ワー ク に 属するものである場合に、真となります。 net は、アドレス値もしくは /etc/networks で定義されたネッ ト ワー ク名のいずれかを指定可能です (詳しくは、networks(4) を参照)。 |
|
src net net |
|
パケットの始点 IPv4/v6 アドレスが、 net で指定されたネッ トワークに属するものである場合に、真となります。 |
|
net net |
|
始点 IPv4/v6 アドレスもしくは終点 IPv4/v6 アドレスが net で指定されたネットワークに属するものである場合に、真とな ります。 |
|
net net mask netmask |
|
IP アドレスが、指定された net および netmask の値で決ま るネットワークに属するものである場合に、真となり ま す。 src や dst を指定する事も可能です。この構文は IPv6 net では正当でないことに注意してください。 |
|
net net/len |
|
IPv4/v6 アドレスが、指定された len のビット長のネット マ ス クで net に属するネットワークの場合に、真となります。 src や dst を指定する事も可能です。 |
|
dst port port |
|
パケットが ip/tcp, ip/udp, ip6/tcp, ip6/udp のいずれかで あ り、 終 点 ポート番号が port の場合に、真となります。 port で指定されるポート番号は、値もしくは /etc/services で 定 義 されているサービス名で指定可能です ( tcp(4P) や udp(4P) を参照)。ポート番号がサービス名にて指定された 場 合、 ポー ト番号とプロトコルの両方がチェック対象になりま す。ポート番号や、あいまいなサービス名が指定された場合に は、 ポー ト番号のみがチェック対象となります(例えば、dst port 513 は、 tcp/login と udp/who の両方を出力 し、port domain は、tcp/domain と udp/domain の両方を出力しま す)。 |
|
src port port |
|
パケットが port で指定した始点ポート番号を保持している場 合に真となります。 |
|
port port |
|
パケットの始点ポート番号もしくは終点ポート番号が port の 場合に、真となります。上記のポート番号の指定については、 すべてキーワード tcp もしくは udp を用いて、ある程度候補 を絞り込むことが可能です。例えば、 |
tcp src port port |
|
と指定した場合には、tcp パケットのみが条件一致の評価対象 となります。 |
|
less length |
|
パ ケッ トが length で指定した長さ以下の場合、真となりま す。これは、 |
len <= length |
|
の指定と等価です。 |
|
greater length |
|
パケットが length で指定した長さ以上の場合、真とな り ま す。これは、 |
len >= length |
|
と等価です。 |
|
ip proto protocol |
|
パケットが protocol で指定したプロトコル型の IP パケット ( 詳細は ip(4P) を参照) の場 合 に、 真 と な り ま す。 protocol は、数字もしくは icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, tcp のいずれかの名前が指 定 可 能 で す。tcp, udp, icmp の各識別子はキーワードでもであり、 バックスラッシュ (\)(C-shell では \\) を用いてエスケープ しなければならないことに注意してください。このプリミティ ブはプロトコルヘッダチェーンを追跡しないことに注意してく ださい。 |
|
ip6 proto protocol |
|
パケットがプロトコル型 protocol の IPv6 パケットである場 合に、真となります。このプリミティブはプロトコル ヘッ ダ チェーンを追跡しないことに注意してください。 |
|
ip6 protochain protocol |
|
パケットが IPv6 パケットであり、プロトコルヘッダチェーン 中にタイプ protocol のプロトコルヘッダが含まれるば あ い に、真となります。例えば |
ip6 protochain 6 |
|
は、TCP プロトコルヘッダがプロトコルヘッダチェーン中に含 まれる任意のパケットにマッチします。パケット中には、IPv6 ヘッ ダと TCP ヘッダの間に、例えば、認証ヘッダ、ルーティ ングヘッダ、ホップ毎のオプションヘッダが含まれ得ます。こ の プ リ ミ ティ ブ が 出力する BPF コードは、複雑であり tcpdump 中の BPF 最適化コードでは最適化できません。 よっ て、この動作はいくぶん遅いです。 |
|
ip protochain protocol |
|
ip6 protochain protocol と同様で、 IPv4 のものです。 |
|
ether broadcast |
|
パケットがイーサネットブロードキャストパケットの場合に、 真となります。 ether キーワードは、省略可能です。 |
|
ip broadcast |
|
パケットが IPv4 ブロードキャストパケットの場合に、真とな り ます。オール 1 とオール 0 の 2 つの形式のブロードキャ ストアドレスを検査し、そして捕捉が行われてい る イ ン タ フェースのサブネットマスクを調べます。 |
|
も し、そのネットマスクが無効だった場合、この検査は正しく 動作しません。これは、捕捉を行っているインタ フェー ス に ネットマスクが設定されていなかったり、または 2 つ以上のイ ンタフェース上で捕捉を行える Linux の "any" インタ フェー スを使用している場合に起こります。 |
|
ether multicast |
|
パケットがイーサネットマルチキャストパケットの場合に、真 となります。 ether キーワードは、省略可能です。なお、 こ の指定は、‘ether[0] & 1 != 0’ の短縮系です。 |
|
ip multicast |
|
パケットが IP マルチキャストパケットの場合に、真となりま す。 |
|
ip6 multicast |
|
パケットが IPv6 マルチキャストパケットの場合に、真となり ます。 |
|
ether proto protocol |
|
パ ケットの ether 型が protocol の場合に、真になります。 protocol は、数字もしくは ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, netbeui のいずれかの名前を指定可能です。これらの識別子は キー ワードでもあり、バックスラッシュ (\) でエスケープし なければならないことに注意してください。 |
|
[FDDI (例えば ‘fddi protocol arp’) や Token Ring ( 例 え ば‘tr protocol arp’)、IEEE 802.11 無線 LAN (例えば ‘wlan protocol arp’) の場合、これらのほとんどのプロトコルに対し て、 プ ロトコルの識別は IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。通常これは FDDI ヘッダや Token Ring ヘッダ、802.11 ヘッダの上位層にあります。 FDDI, Token Ring, 802.11 のほとんどのプロトコル識別子に対 してフィルタリングをかける場合、tcpdump は、カプ セ ル 化 イー サネットに対しては、管理組織識別子 (OUI) 0x000000 を 持つ、いわゆる SNAP フォーマットの LLC ヘッダのプロトコル ID のみをチェックします。そのパケットが、0x000000 の OUI を持つ SNAP フォーマットであるかどうかはチェック し ま せ ん。例外は以下の通りです: |
|
iso |
tcpdump は、LLC ヘッダの DSAP (Destination Service Access Point) フィールドと SSAP (Source Service Access Point) フィールドもチェックしま す。 |
|
stp および netbeui |
|
tcpdump は、LLC ヘッダの DSAP をチェックします。 |
|
atalk |
tcpdump は、0x080007 の OUI と Appletalk の etype を持つ SNAP フォーマットのパ ケッ ト を チェックします。 |
|
イー サネットの場合、tcpdump は、これらのプロトコルのほと んどに対してイーサネットタイプフィールドをチェッ ク し ま す。例外は以下の通りです: |
|
iso, sap, netbeui |
|
tcpdump は、FDDI, Token Ring, 802.11 の場合と同 様に、 802.3 フレームをチェックし、次に LLC ヘッ ダをチェックします。 |
|
atalk |
tcpdump は、FDDI, Token Ring, 802.11 の場 合と同様に、イーサネットフレーム内 の Appletalk etype および SNAP フォーマットパケットの両方に対 してチェックします。 |
||
|
aarp |
tcpdump は、イーサネットフ レー ム ま た は 0x000000 の OUI を持つ 802.3 SNAP フレームに対 し、Appletalk ARP etype をチェックします。 |
||
|
ipx |
イーサネットフレーム内の IPX etype、LLC ヘッ ダ 内 の IPX DSAP、 IPX の LLC ヘッダを持たない 802.3 カプセル化、および SNAP フレーム内 の IPX etype をチェックします。 |
|
decnet src host |
|
DECNET パケットの始点アドレスが host の場合に、真となり ます。これは ‘‘10.123’’ という形式のアドレスでも DECNET のホスト名でも構いません。[DECNET のホスト名は DECNET を 動かすように設定された ULTRIXシステムのみでサポートさ れ ます。] |
|
decnet dst host |
|
DECNET パケットの終点アドレスが host の場合に、真となり ます。 |
|
decnet host host |
|
DECNET パケットの始点あるいは終点アドレスが host の場 合 に、真となります。 |
|
ifname interface |
|
パケットが、指定されたインタフェースから来たとログに記録 されると、真となります (OpenBSD の pf(4) によってログ に 記録されたパケットのみに適用されます)。 |
|
on interface |
|
ifname 修飾子と同義です。 |
|
rnr num |
|
パケットが、指定された PF のルール番号にマッチしたとログ に記録されると、真となります。 (OpenBSD の pf(4) に よっ てログに記録されたパケットのみに適用されます)。 |
|
rulenum num |
|
rnr 修飾子と同義です。 |
|
reason code |
|
パケットが、指定された PF の原因コードによってログに記録 されると、真となります。コードは次のよう な も の で す: match, bad-offset, fragment, short, normalize, memory (OpenBSD の pf(4) によってログに記録されたパケットのみに 適用されます)。 |
|
rset name |
|
パ ケッ トが、指定された PF のアンカルールセットのルール セット名にマッチしたとログに記録されると、真となります。 (OpenBSD の pf(4) によってログに記録されたパケットのみに 適用されます)。 |
|
ruleset name |
|
rset 修飾子と同義です。 |
|
srnr num |
|
パケットが、指定された PF のアンカルールセットのルール番 号 に マッ チ し た とログに記録されると、真となります。 (OpenBSD の pf(4) によってログに記録されたパケットのみに 適用されます)。 |
|
subrulenum num |
|
srnr 修飾子と同義です。 |
|
action act |
|
パ ケットが記録された時に、PF が指定された動作を行った場 合、真となります。動作とは、次のものです: pass , block (OpenBSD の pf(4) によってログに記録されたパケットのみに 適用されます)。 |
|
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui |
|
これらは |
ether proto p |
|
の短縮形です。p の部分には、上記のいずれかのプロトコル名 が入ります。 |
|
lat, moprc, mopdl |
|
これらは |
ether proto p |
|
の短縮形です。p の部分には、上記のいずれかのプロトコル名 が 入ります。 tcpdump は今のところこれらのプロトコルを解 釈できない事に注意してください。 |
|
vlan [vlan_id] |
|
パケットが IEEE 802.1Q VLAN パケットの場合、真にな り ま す。 [vlan_id] が指定された場合、パケットが指定された vlan_id を持つ場合のみ、真になります。 expression 中の最 初の vlan キーワードが、パケットが VLAN パケットであるこ とを仮定して、残りの expression のデコード用オフセットを 変更してしまうことに注意してください。 |
|
tcp, udp, icmp |
|
これらは |
ip proto p or ip6 proto p |
|
の短縮形です。p の部分には、上記のいずれかのプロトコル名 が入ります。 |
|
iso proto protocol |
|
パケットがプロトコル型 protocol の OSI パケットの場 合、 真 になります。 protocol は数値もしくは clnp, esis, isis という名前のいずれかです。 |
|
clnp, esis, isis |
|
これらは |
iso proto p |
|
の短縮形です。p の部分には、上記のいずれかのプロトコル名 が入ります。 |
|
l1, l2, iih, lsp, snp, csnp, psnp |
|
IS-IS PDU タイプの短縮形です。 |
|
vpi n |
パケットが Solaris 上の SunATM にとって、仮想パス 識別子が n の ATM パケットの場合、真となります。 |
|
|
vci n |
パケットが Solaris 上の SunATM にとって、仮想チャ ネル識別子が n の ATM パケットの場合、真となります。 |
|
|
lane |
パケットが Solaris 上の SunATM にとって、ATM パ ケットであり、 ATM LANE パケットであった場合、真となりま す。 expression に lane キーワードがあると、パケットが、 イーサネットをエミュレートした LANE パケットか、もしくは LANE LE 制御パケットであると仮定して、残りの expression に対して行われる検査が変更されることに注意してください。 lane が指定されなければ、パケットが LLC カプセル化パケッ トであると仮定して、検査が行われます。 |
|
|
llc |
パケットが Solaris 上の SunATM にとって ATM パ ケッ トであり、 LLC カプセル化パケットの場合、真となります。 |
|
|
oamf4s |
パケットが Solaris 上の SunATM にとって ATM パ ケットであり、セグメント OAM F4 フ ロー セ ル (VPI=0 & VCI=3) の場合、真となります。 |
|
|
oamf4e |
パケットが Solaris 上の SunATM にとって ATM パ ケットであり、エンド・トゥ・エンド OAM F4 フ ロー セ ル (VPI=0 & VCI=4) の場合、真となります。 |
|
|
oamf4 |
パケットが Solaris 上の SunATM にとって ATM パ ケットであり、セグメント もしくは エンド・トゥ・エ ン ド OAM F4 フローセル (VPI=0 & (VCI=3 | VCI=4)) の場合、真と なります。 |
|
|
oam |
パケットが Solaris 上の SunATM にとって ATM パ ケッ ト で あり、セグメント もしくは エンド・トゥ・エンド OAM F4 フローセル (VPI=0 & (VCI=3 | VCI=4)) の場合、真となります。 |
|
|
metac |
パケットが Solaris 上の SunATM にとって ATM パ ケッ ト で あり、メタ・シグナリング・サーキット (VPI=0 & VCI=1) 上であった場合、真となります。 |
|
|
bcc |
パケットが Solaris 上の SunATM にとって ATM パ ケッ ト で あ り、 ブロードキャスト・シグナリング・サーキット (VPI=0 & VCI=2) 上であった場合、真となります。 |
|
|
sc |
パケットが Solaris 上の SunATM にとって ATM パケット で あ り、 シグナリング・サーキット (VPI=0 & VCI=5) 上で あった場合、真となります。 |
|
|
ilmic |
パケットが Solaris 上の SunATM にとって ATM パ ケットであり、 ILMI サーキット (VPI=0 & VCI=16) 上であっ た場合、真となります。 |
|
connectmsg |
|
パケットが Solaris 上の SunATM にとって ATM パケットで、 シ グ ナ リ ング・サーキット上にあり、Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, Release Done メッセージであった場合に、真となります。 |
|
metaconnect |
|
パケットが Solaris 上の SunATM にとって ATM パケットで、 メタ・シグナリング・サーキット上に あ り、Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, Release Done メッセージであった場合に、真となります。 |
|
expr relop expr |
|
relopは、>, <, >=, <=, =, != のいずれかであり、expr の部 分には、(標準 C 言語の構文で表現された) 整数定数や通常の 二項演算子 [+, -, *, /, &, |, <<, >>]、length 演算子、そ して特殊なパケットデータへのアクセス演算子などからなる算 術表現が入って、その関係が成立する場合に、真となります。 パケット内部のデータにアクセスするためには、以下の構文を 用います。 |
proto [ expr : size ] |
|
protoは、ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 のいずれかであり、イン デックス操作を行うプロトコル層を指示します (ether, fddi, wlan, tr, ppp, slip, link はすべてリンク層を指します)。 tcp, udp および他の上位層プロトコル型は、 IPv4 のみに 適 用 され、IPv6 には適用されないことに注意してください (こ れは将来修正されます)。指示したプロトコル層からの相対 バ イ ト オ フセットは、expr で指定します。 size は省略可能 で、取得するフィールドのデータ長を表します。データ長とし ては、1,2,4 のいずれかを指定することが可能であり、デフォ ルトでは 1 が指定されたものとみなされます。 キー ワー ド len で示されるデータ長演算子は、パケット長を与えます。 例 え ば、‘ether[0] & 1 != 0’ は、全てのマルチキャストパ ケットを捕捉します。 ‘ip[0] & 0xf != 5’ という表現は、す べ て のオプション付きIPパケットを捕捉することを意味しま す。‘ip[6:2] & 0x1fff = 0’ という表現は、フラグメント の な い データグラムパケット、もしくはフラグメント化された データグラムのうち最初のフラグメントを捕捉します。この検 査 は、tcp および udp のインデックス操作においては、暗黙 のうちに適用されます。例えば、tcp[0] は常に TCP ヘッダの 先頭バイトを指し、決して各フラグメントの先頭バイトを指す ものではありません。 いくつかのオフセットとフィールド値は、数値ではなく定数と して表記できます。次のプロトコルヘッダフィールドオフセッ トが利用可能です。 icmptype (ICMP タ イ プ フィー ル ド)、icmpcode (ICMP コードフィールド) および tcpflags (TCP フラグフィールド) 次の ICMP タイ プ フィー ル ド 値 が 利 用 可 能 で す。 icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply 次 の TCP フラグフィールド値が利用可能です。 tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg |
|
プリミティブは、以下のように組み合わせることが可能です。 |
|
括弧で括られた一連のプリミティブや演算子 (括弧はシェル の 特殊文字なのでエスケープする必要があります)。 否定 (‘!’ or ‘not’). 論理積 (‘&&’ or ‘and’). 論理和 (‘||’ or ‘or’). |
|
否定は、最も高い演算優先度を持ちます。論理和と論理積は、同じ演算 優先度を持ち、左から右へ評価されます。論理積の場合には、単に識別 子 を並べるのではなく、明示的に and を使用しなければならないこと に注意して下さい。 キーワードなしで識別子が与えられている場合には、最も最近用いられ たキーワードが付加されているものと仮定されます。例えば、 |
not host vs and ace |
|
は、 |
not host vs and host ace |
|
の短縮形ですが、 |
not ( host vs or ace ) |
|
と混同してしまいがちなので気をつけましょう。 引数 expression は、単一の引数としても複数の引数としても、どちら か便利な方で、tcpdump に渡すことができます。一般的に、引数がシェ ルのメタキャラクタを含む場合、その引数をクォートされた単一の引数 としてプログラムに渡す方が容易です。複数の引数は、解析される前に スペースで連結されます。 |
|
sundown に到達する、もしくはそこから送信されるパケットのすべてを表示す る場合には、以下のように実行します。 |
tcpdump host sundown |
|
helios と、hot もしくは ace の間のトラフィックを表示する場合には、以 下 のように実行します。 |
tcpdump host helios and \( hot or ace \) |
|
ace と、helios 以外のホストとの間でやりとりされるすべての IP パケットを 表示する場合には、以下のように実行します。 |
tcpdump ip host ace and not helios |
|
ローカルなホストと Berkeley のホストとの間でやりとりされるすべてのト ラ フィックを表示する場合には、以下のように実行します。 |
tcpdump net ucb-ether |
|
インターネットゲートウェイ snup を通過するすべての ftp トラフィックを表 示する場合には、以下のように実行します (シェルが括弧を誤って解釈しな い よう、フィルタを表現する引数がクォートされていることに注意して下さい)。 |
tcpdump ’gateway snup and (port ftp or ftp-data)’ |
|
始点アドレスと終点アドレスの両方がローカルネットワーク内のホストのも の で ないトラフィックについて表示する場合には、以下のように実行します (実 行するホストが他のネットワークに対するゲートウェイの場合、そのホスト が 属すローカルネットワークでは、このコマンドは成功しないでしょう)。 |
tcpdump ip and not net localnet |
|
ロー カルネットワーク外のホストとの通信において、TCP による各通信単位の スタートパケットとエンドパケット (SYN と FIN パケット) を表示するには、 以下のように実行します。 |
tcpdump ’tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet’ |
|
ゲー トウェイ snup を中継される IP パケットのうち、576 バイトより大きい ものを表示するには、以下のように実行します。 |
tcpdump ’gateway snup and ip[2:2] > 576’ |
|
イーサネット上でブロードキャストもしくはマルチキャストを経由して送ら れ る もの以外の IP ブロードキャストもしくはマルチキャストパケットを表示す るには、以下のように実行します。 |
tcpdump ’ether[0] & 1 = 0 and ip[16] >= 224’ |
|
echo 要求/応答以外 (つまり ping パケット以外) の全ての ICMP パケット を 表示するには、以下のように実行します。 |
tcpdump ’icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply’ |
|
tcpdump の出力は、プロトコル依存です。以下の説明では、簡単なパラメータ の記述と、おおよそのフォーマットの説明を行ないます。 リンクレベルヘッダ もし ’-e’ オプションが指定されると、リンクレベルヘッダが出力されま す。 イー サネットにおいては、始点と終点のアドレス、プロトコル、そしてパケッ ト長が出力されます。 FDDI ネットワークにおいては、’-e’ オプションが指定されると tcpdump は、 「フ レーム制御」フィールド、発信元と終点アドレス、そしてパケット長を出 力します。「フレーム制御」フィールドはパケットの残りの部分の解釈を決 定 します。(IP データグラムを含むような) 通常のパケットは ‘async’ パケット で、 0 から 7 の間の優先順位を持ちます。例えば、‘async4’ です。こうした パ ケットは IEEE802.2 の論理リンク制御 (LLC) パケットを含むと仮定されま す。 LLC ヘッダは、それが ISO データグラムでない場合やいわゆる SNAP パ ケットのときには出力されます。 Token Ring ネットワークでは、’-e’ オプションを指定すると、tcpdump は、 アクセス制御」と「フレーム制御」のフィールド、始点と終点のアドレス、 パ ケット長を表示します。 FDDI ネットワークでは、パケットは LLC パケットを 含むと仮定されます。オプション ’-e’ の指定の有無にかかわらず、始点経 路 制御されたパケットに対しては、始点経路制御情報が表示されます。 802.11 ネッ トワークでは、’-e’ オプションが指定されると、「フレーム制 御」フィールド、802.11 ヘッダに含まれるすべてのアドレス、そしてパケット 長を出力します。 FDDI ネットワークと同様に、パケットには LLC パケットが 含まれると仮定されます。 (注意: 以下の記述は、利用者が RFC1144 に記述されている SLIP 圧縮アルゴ リズムについての知識がある前提で書いています。) SLIP によるリンクにおいては、方向指示子 (‘‘I’’ が入力方向、‘‘O’’ が出力 方向)、パケット型、そして圧縮情報が出力されます。パケット型は、最初に出 力されます。パケット型には ip、utcp、そして ctcp の 3 つがあります。 ip 型パケットの場合、上記以上のリンク情報は表示されません。 TCP パケットの 場 合には、コネクション識別子がパケット型に続いて出力されます。パケット が圧縮されている場合、符号化されたヘッダが出力されます。特殊な 場 合 は *S+n や *SA+n のように出力されます。ここで n は、シーケンス番号 (もしく はシーケンス番号および ack) が変更された回数です。特殊な場合で な け れ ば、0 回以上の変更について出力されます。変更は、U (緊急 (urgent) ポイン タ)、W (ウィンドウ)、A (ack)、S (シーケンス番号)、そして I ( パ ケッ ト ID) で示され、変動量 (+n or -n) もしくは新しい値 (=n) が続きます。最後 に、パケット内のデータの総量および圧縮ヘッダ長が出力されます。 例えば、以下の行は、出力方向の圧縮 TCP パケットを、暗黙のコネクション識 別 子 とともに表示しています。ack は 6 変わり、シーケンス番号は 49 変わ り、パケット ID は 6 変わっています。3 バイトのデータと6 バイトの 圧 縮 ヘッダが存在します。 |
O ctcp * A+6 S+49 I+6 3 (6) |
|
ARP/RARP パケット arp/rarp パケットの出力は、要求型とその引数を示しています。出力形式は、 その出力のみで理解可能なように作られています。以下に、ホスト rtsg か ら ホスト csam への ‘rlogin’ 開始時のパケットの実例を示します。 |
arp who-has csam tell rtsg arp reply csam is-at CSAM |
|
1行目は、ホスト rtsg が、ホスト csam のイーサネットアドレスを問い合わせ る目的で arp パケットを送信していることを意味します。ホスト csam は、自 分 自身のイーサネットアドレスを返答しています (この例では、イーサネット アドレスは大文字で、インターネットアドレス部は小文字で表記しています)。 tcpdump −n として起動した場合には、少し冗長になります。 |
arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4 |
|
tcpdump −e として起動した場合には、最初のパケットはブロードキャストパ ケットであり、次のパケットはポイントツーポイントのパケットであること が わかります。 |
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM |
|
最 初のパケットについては、始点のイーサネットアドレスは RTSG であり、終 点はイーサネットブロードキャストアドレス、型フィールドには 16 進数の 値 0806 (ETHER_ARP を意味します) が格納されており、総パケット長は 64 バイ トであると表示しています。 TCP パケット (注意:以下の記述は、RFC793 に記述されている TCP プロトコルについての 知 識 が あ る こ とを前提に記述されています。この知識がない場合、本記述と tcpdump のいずれもあなたには役に立たないでしょう。) TCP プロトコル行の一般的な形式は、以下の通りです。 |
src > dst: flags data-seqno ack window urgent options |
|
src と dst は、それぞれ始点と終点の IP アドレスとポート番号です。 flags の 部 分 に は、S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR), E (ECN-Echo) の組み合わせ、もしくは単なる ‘.’ (フラグなし) が入り ま す。 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 デー タ グ ラ ム 長 がオプションがそこにあるために十分な長さではない場合に、 tcpdump は ‘‘[bad hdr length]’’ を表示します。 特定フラグの組み合わせ (SYN-ACK, URG-ACK 等) による TCP パケットの捕捉 TCP ヘッダの制御ビットセクションには、次の 8 ビットがあります: |
|
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN |
|
TCP 接続の確立に使用されるパケットを見たいものとしましょう。新規接続 を 初 期化する時、 TCP は 3 ウェイハンドシェークプロトコルを使用することを 思い出してください。 TCP 制御ビットに関する接続の順番は次のようになりま す。 |
|
1) 呼び出し側が SYN を送信 |
|
2) 受信者が SYN, ACK で応答 |
|
3) 呼び出し側が ACK を送信 |
|
こ こで、SYN ビットを持つパケットを捕捉したいとします (第 1 ステップ)。 ステップ 2 のパケット (SYN-ACK) は不要で、最初の SYN だけが欲しいことに 注意してください。必要なのは、tcpdump の正しいフィルタ式です。 オプション無しの TCP ヘッダの構造を思い出してください: 0 15 31 ----------------------------------------------------------------- | 始点ポート | 終点ポート | ----------------------------------------------------------------- | シーケンス番号 | ----------------------------------------------------------------- | 確認応答番号 | ----------------------------------------------------------------- | HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ | ----------------------------------------------------------------- | TCP チェックサム | 緊急ポインタ | ----------------------------------------------------------------- TCP ヘッダは、オプションが無ければ通常、20 オクテットのデータを持ちま す。図の最初の行はオクテット 0 から 3 を示し、次の行はオクテット 4 から 7 を示す等となります。 0 から数え始めると、必要な TCP 制御ビットはオクテット 13 にあります: 0 7| 15| 23| 31 ----------------|---------------|---------------|---------------- | HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ | ----------------|---------------|---------------|---------------- | |13 オクテット目| | | 第 13 オクテットをもっとよく見てみましょう: | |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
これらは我々が興味がある TCP 制御ビットです。このオクテットのビットを、 右から左へ、0 から 7 と番号付けします。 PSH ビットは第 3 ビッ ト で あ り、URG ビットは第 5 ビットです。 最 初の SYN だけを持つパケットが欲しいことに注意してください。 SYN ビッ トがセットされた TCP データグラムが到着すると、第 13 オクテットになにが 起きるか見てみましょう: |C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
制御ビットセクションを見ると、ビット番号 1 (SYN) のみがセットされていま す。 オクテット番号 13 が、ネットワークバイト順で、 8 ビット符号無し整数と仮 定します。このオクテットの 2 進数値は |
|
00000010 |
|
となり、10 進数での表現は次のようになります: 7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2 SYN のみセットされている場合について理解したので、これでほとんど終りで す。 TCP ヘッダの第 13 オクテットの値は、ネットワークバイト順の 8 ビッ ト符号無し整数として解釈すると、正確に 2 となります。 この関係は次のように表現可能です: |
|
tcp[13] == 2 |
|
こ の式を tcpdump のフィルタとして使用し、 SYN パケットのみを持つパケッ トを捕捉可能です: |
|
tcpdump -i xl0 tcp[13] == 2 |
|
この式は「TCP データグラムの第 13 オクテットは 10 進数 2 を持つ」と言っ ており、まさに我々が望むものです。 次に、SYN パケットが必要であるが、ACK や他の TCP 制御ビットについてはど うでも良い場合を考えます。 SYN-ACK が設定された TCP データグラムが到 着 した時にオクテット 13 がどうなっているかを見てみましょう: |C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
今 度 は、 第 13 オクテットの第 1 ビットと第 4 ビットがセットされていま す。第 13 オクテットの 2 進数値は |
|
00010010 |
|
となり、10 進数では次のようになります: 7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18 今度は、tcpdump フィルタ式に ’tcp[13] == 18’ を使用できません。こ の 式 は、SYN-ACK がセットされているパケットのみを選択し、 SYN のみセットされ ているパケットを選択しないからです。 ACK や他の制御ビットがセットされて いようといまいと構わないことを思い出してください。 この目的を達成するために、第 13 オクテットと他の値との論理 AND を取り、 SYN ビットを得ることが必要です。我々が欲しいのはどんな場合でも SYN が セッ トされていれば良いので、第 13 オクテットと SYN の 2 進数値との論理 AND を取ります: 00010010 SYN-ACK 00000010 SYN
AND 00000010 (SYN が欲しい) AND 00000010 (SYN が欲しい)
-------- --------
= 00000010 = 00000010
この AND 操作は、ACK や他の TCP プロトコルビットがセットされていよう と いまいと、結果は同じです。 AND 用の値の 10 進数表現と、この操作の結果の 10 進数値は、共に 2 (2 進数値 00000010) であり、 SYN がセットされて い るパケットには次の関係が成立します: |
|
( ( 第 13 オクテットの値 ) AND ( 2 ) ) == ( 2 ) |
|
ここで、tcpdump フィルタ式は次のようになることが分かります: |
|
tcpdump -i xl0 ’tcp[13] & 2 == 2’ |
|
シングルクォートもしくはバックスラッシュを使用して、AND (&’) 特殊文字を シェルから隠す必要があることに注意してください。 UDP パケット UDP フォーマットは、以下の rwho パケットで例示します。 |
actinide.who > broadcast.who: udp 84 |
|
これは、ホスト actinide の who ポートが UDP データグラムをインター ネッ ト ブロードキャストアドレスであるホスト broadcast の who ポートに対して 送信していることを意味します。本パケットは、 84 バイトのユーザデータ を 含みます。 いくつかの UDP サービスは(始点もしくは終点のポート番号から)種類の判断が 可能で、さらに上位レベルのプロトコル情報が出力されます。ドメインネー ム サー ビス要求 (RFC1034/1035)、そして、Sun RPC 呼びだし (RFC1050) を用い た NFS サービスなどがこの条件に該当します。 UDP ネームサーバ要求 (注意:以下の記述は、RFC1035 に記述されているドメインサービスプロトコ ル の 知 識 があることを前提に書かれています。もしこれらの知識がない場合に は、以下の記述は未知の言語で書かれているかのように見えるでしょう。) ネームサーバ要求は、以下のような表示になります。 |
src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) |
|
ホ ス ト h2opolo は、helios 上 の ド メ イ ン サー バ に 対 し て ucbvax.berkeley.edu のホスト名に対応するアドレスレコード (qtype=A) を問 い合わせています。問い合わせの ID は ‘3’ であり、‘+’ は再帰要求フラグが 設 定されていることを意味します。問い合わせの長さは 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 |
|
そ して、クロックの精度は、カーネルクロックの精度に依存します。タイムス タンプは、カーネルが最初にパケットを見つけた時間を反映しま す。 イー サ ネッ トインタフェースがケーブルからパケットを取り出してカーネルが「新規 パケット」割り込みを受け付けるまでのタイムラグなどは補正されません |
|
元々の作者は次の通りです: Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. 現在は tcpdump.org で管理されています。 現在のバージョンは http で次のところから取得可能です: |
|
http://www.tcpdump.org/ |
|
元々の配布は匿名 ftp で次のところから取得可能です: |
|
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z |
|
IPv6/IPsec サポートは WIDE/KAME プロジェクトが追加しました。本プログラ ムは、特定の構成においては、 Eric Young の SSLeay ライブラリを使用し ま す。 |
|
問題、バグ、希望の機能拡張等については次のところに送ってください: |
|
tcpdump-workers@tcpdump.org |
|
ソースコードの寄贈等については次のところに送ってください: |
|
patches@tcpdump.org |
|
NIT では、外に出ていくトラフィックを観察できません。BPF ならできます。 後者を用いることを推奨します。 2.0[.x] カーネルの Linux システムにおいて: |
|
ループバックデバイス上のパケットは 2 度観測されます。 カーネル内でのパケットフィルタリングは不可能であり、全パケットが カーネルからコピーされてユーザモードでフィルタされます。 スナップショットの長さ部分ではなく、パケット全体が、カーネルから コピーされます (2.0[.x] のパケット捕捉機構は、パケットの一 部 を ユーザランドへコピーするように依頼されると、パケットの正しい長さ を報告しません。このため、ほとんどの IP パケットが tcpdump で エ ラーとなってしまいます)。 いくつかの PPP デバイス上での捕捉は、正しく動作しません。 |
|
2.2 以降のカーネルにアップグレードすることをお勧めします。 IP フラグメントを再構成するか、もしくは少なくとも上位プロトコルの正しい データサイズを計算するように設計しなおす必要があります。 ネームサーバについての逆引きについては、正しくダンプされません。実際 の 要 求ではなく、(empty) クエスチョンセクションが、アンサーセクションに出 力されます。逆引きについてはそれ自体がバグであると信じ、 tcpdump ではな く逆引きを要求するプログラムを修正するべきと考える人達もいます。 夏 時間との変更の時にパケットトレースを行うと、タイムスタンプは変更後の 時刻とはずれてしまいます (時間変化は無視されます)。 Token Ring ヘッダ以外のフィールドに対するフィルタ式は、始点経路制御され た Token Ring パケットを正しく扱いません。 802.11 ヘッダ以外のフィールドに対するフィルタ式は、’To DS’ と ’From DS’ の両方をもつ 802.11 データパケットを正しく扱いません。 ip6 proto はヘッダチェーンを追跡すべきですが、現在のところはそうなっ て いません。このために ip6 protochain が提供されています。 例 え ば tcp[0] といったトランスポート層ヘッダに対する演算は、 IPv6 パ ケットに対しては動作しません。 IPv4 パケットだけを見ます。 |