EN JA
TCPDUMP(1)
TCPDUMP(1) FreeBSD General Commands Manual TCPDUMP(1)

名称

tcpdump -ネットワーク上のトラフィックデータのダンプ

書式

tcpdump [ -AbdDefhHIJKlLnNOpqRStuUvxX ] [ -B buffer_size ] [ -c count ]
 
[ -C file_size ] [ -G rotate_seconds ] [ -F file ]
 
[ -i interface ] [ -j tstamp_type ] [ -m module ] [ -M secret ]
 
[ -r file ] [ -V file ] [ -s snaplen ] [ -T type ] [ -w file ]
 
[ -W filecount ]
 
[ -E spi@ipaddr algo:secret,... ]
 
[ -y datalinktype ] [ -z postrotate-command ] [ -Z user ] [ expression ]
 

解説

tcpdump は、ブール値 expression (式) にマッチするネットワークインタフェースのパケットの内容の記述を印刷 (表示) します。パケットデータを後で分析するためファイルに保存するよう、 -w フラグで実行することもできます。また、 -r フラグで、ネットワークインタフェースからのパケットではなく、ファイルに保存されたパケットから読み込むことができます。また、それは、保存されたパケットファイルのリストを読み込む、 -V フラグで実行することができます。すべての場合に、 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) によって設定する必要があります)。

ネットワークインタフェースからパケットを読むには、権限を必要とします。詳細については、 pcap (3PCAP) マニュアルページを参照してください。保存されているパケットファイルの読み込みに、特権を必要としません。

オプション

-A
各々のパケット (からリンクレベルのヘッダを除いたもの) を ASCII で表示します。 Web ページを捕捉する場合に便利です。
-b
ASPLAIN 記法でなく ASDOT 記法で BGP パケットの AS 番号を印刷します。
-B
オペレーティングシステムの獲得バッファサイズを KiB (1024 バイト) の単位で buffer_size に設定します。
-c
count で指定した数のパケットを受信した後に終了します。
-C
保存ファイルに raw パケットを書き込む前に、現在のファイルが file_size より大きいかどうかをチェックします。もし大きいなら、現在の保存ファイルを閉じて新しいものを開きます。付けられるファイル名は、最初の保存ファイルを除く 2 番目以降の保存ファイルから -w フラグで指定されたファイル名の後にそれぞれ番号がつきます。その番号は、1 から始まり順に大きくなります。 file_size の単位は、100 万バイト (1,000,000 バイト。 1,048,576 バイトのことではない) です。
-d
解釈されたパケットマッチングコードを読みやすい形に整形した後、標準出力にダンプして停止します。
-dd
C プログラムの断片の形でパケットマッチングコードをダンプします。
-ddd
(先頭に個数を付加した) 10 進数の形でパケットマッチングコードをダンプします。
-D
そのシステム上で利用可能で、 tcpdump がパケットを捕捉できるネットワークインタフェースのリストを出力します。それぞれのネットワークインタフェースに対して、番号とインタフェース名、そして可能であればそのインタフェースの説明を表示します。ネットワークインタフェース名、および番号は、捕捉を行うインタフェースを -i フラグで指定する際に使用できます。
これは、インタフェースをリストするコマンドを持たないシステムにおいて有用です (例えば、Windows システムや ifconfig -a を持たない UNIX システム)。また番号は、Windows 2000 以降のシステムのように、インタフェース名が何か複雑な文字列の場合に便利です。
tcpdumppcap_findalldevs() 関数を持たない古いバージョンの libpcap を使って構築されたなら、 -D フラグは、サポートされません。
-e
各ダンプ行で、リンクレベルのヘッダを印刷 (表示) します。これは、例えば、イーサネットと IEEE 802.11 のようなプロトコルのための MAC レイヤ (層) アドレスを印刷するために、使用することができます。
-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 に記述してある内容を用います。コマンドラインで指定された追加表現は、無視されます。
-G
指定されるなら、 rotate_seconds 秒毎に -w オプションで指定されたダンプファイルをローテート (回転) させます。 savefile は、 strftime(3) によって定義されるように、時間形式を含むべきである -w によって指定された名前があります。時間形式が指定されないなら、それぞれの新しいファイルは、前のものを上書きします。
-C オプションと同時に使用されるなら、ファイル名は、` file<count>' の形式を取ります。
-h
tcpdump と libpcap バージョンの文字列を印刷し、使用法のメッセージを印刷し、終了します。
-H
802.11s 草案のメッシュヘッダを検出することを試みます。
-i
interface で指定されたインタフェースを監視します。指定されないなら、 tcpdump は、システムインタフェースリストの中で最も小さい番号の稼働中のものを検索し、監視するインタフェースとして設定します (ループバックインタフェースは、検索しません)。この動作は、最初にインタフェースが選択された時点で終了します。
2.2 以降のカーネルの Linux システムでは、 interface 引数 ``any'' を指定して全インタフェースからのパケットを捕捉可能です。 ``any'' デバイスでの捕捉は、promiscuous モードではないことに注意してください。
-D フラグがサポートされているなら、このフラグで表示されるインタフェース番号は、 interface 引数に使用できます。
-I
"モニタモード"のインタフェースの状態にします。これは、IEEE 802.11 Wi-Fi インタフェースのみでサポートされ、いくつかのオペレーティングシステムでのみサポートされます。
モニタモードで、アダプタは、利用者がそのアダプタでどんなワイヤレスネットワークでも使用できないように、それが関連しているネットワークから分離するかもしれないことに注意してください、これは、モニタモードでキャプチャし、別のアダプタで別のネットワークに接続されないなら、ネットワークサーバでファイルにアクセスを防ぐか、またはホスト名かネットワークアドレスの解決を防ぐかもしれません、
このフラグは、 -L フラグの出力に影響します。 -I が指定されないなら、モニタモードでないとき利用可能なそれらのリンクレイヤのタイプだけが表示されます。 -I が指定されるなら、モニタモードであるとき利用可能なそれらのリンクレイヤのタイプだけが表示されます。
-j
捕獲のためのタイムスタンプのタイプを tstamp_type に設定します。タイムスタンプのタイプのために使用する名前は、 pcap-tstamp-type(7) で与えられます。そこにリストされたすべてのタイプは、あらゆる与えられたインタフェースに対して有効になるとは限りません。
-J
インタフェースのためにサポートされたタイムスタンプのタイプをリストして、終了します。インタフェースに対してタイムスタンプのタイプを設定することができないなら、タイムスタンプのタイプは、リストされません。
-K
IP、TCP または UDP チェックサムを検証する試みを行いません。これは、ハードウェアでそれらのチェックサムの計算のいくつかまたはすべてを実行するインタフェースの役に立ちます。そうでなければ、すべての発信 TCP チェックサムは、悪いものとしてフラグが付けられます。
-l
stdout (標準出力) を行でバッファリングします。補足している間にデータを見たいなら、有用です。例えば、

tcpdump -l | tee dat
または

tcpdump -l > dat & tail -f dat
WinDump は、 -l が指定されるなら、各文字を個々に書き込みできるように、 Windows で、``line buffered'' は、``unbuffered'' を意味することに注意してください。
-U は、その振る舞いで -l に似ていますが、出力が、各行の終わりではなく各パケットの終りで stdout (標準出力) に書き込みできるように、出力は、``packet-buffered'' とします。これは、Windows 含むすべてのプラットフォームでバッファリングされます。
-L
指定されたモードでインタフェースのための既知のデータリンクタイプをリストし、終了します。既知のデータリンクタイプのリストは、指定されたモードに依存しています。例えば、いくつかのプラットフォームでは、Wi-Fi インタフェースは、モニタモードでないとき、 (例えば、ラジオ情報で偽のイーサネットヘッダのみをサポートするかもしれません、または 802.11 ヘッダをサポートするかもしれませんが、802.11 ヘッダをサポートしません) データリンクタイプのセットの 1 つを、モニタモードのとき、 (例えば、モニタモードでのみラジオ情報で 802.11 ヘッダ、または 802.11 ヘッダをサポートするかもしれません) データリンクタイプの別のセットをサポートするかもしれません。
-m
SMI MIB モジュールの定義を、ファイル module からロードします。複数の MIB モジュールを tcpdump にロードするために、複数回このオプションを使用することができます。
-M
存在するなら、TCP-MD5 オプション (RFC2385) で TCP セグメントにあるダイジェストを有効にするための共有された秘密として secret を使用します。
-n
アドレス (IP アドレスやポート番号など) を名前に変換しません。
-N
ホスト名のうち、ドメイン名の表示をしません。例えば、本オプションを指定すると、 tcpdump は、``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
65535 バイトのデフォルトでなく各パケットから snaplen バイトのデータを取得します。スナップショットが限られた量しかとれずに切り詰められたパケットは、出力に ``[| proto]'' という文字列がいっしょに表示されます。 proto は、切り詰めが行われたプロトコルレベルの名前です。大きなスナップショットをとる場合には、それだけパケット処理の時間がかかるということと、パケットバッファリング用のバッファの量が減るということに注意してください。これにより、パケットが消失するかもしれません。利用者は、 snaplen を利用者が興味を持っているプロトコル情報を獲得する最も少ない数に制限するべきです。 tcpdump の最近の古いバージョンとの後方互換性のためにデフォルトの 65535 にするために snaplen を 0 に設定します。
-T
" expression"により選択されたパケットを強制的に type で指定されたタイプと解釈します。現在知られているタイプは、 aodv (Ad-hoc On-demand Distance Vector プロトコル), carp (Common Address Redundancy Protocol), cnfp (Cisco NetFlow protocol), radius (RADIUS), rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), snmp (Simple Network Management Protocol), tftp (Trivial File Transfer Protocol), vat (Visual Audio Tool), wb (distributed White Board), zmtp1 (ZeroMQ Message Transport Protocol 1.0) と vxlan (Virtual eXtensible Local Area Network) です。
-t
各ダンプ行でのタイムスタンプを印刷 (表示) しません
-tt
各ダンプ行毎にタイムスタンプを人間が読みやすい形に変換せずに出力します。
-ttt
直前のダンプ行と現在のダンプ行の差分 (マイクロ秒の解像度) を表示します。
-tttt
各ダンプ行で、デフォルト書式でタイムスタンプを表示し、その前に日付を付けます。
-ttttt
各ダンプ行で、現在と最初の行の間のデルタ (マイクロ秒の解像度) を印刷 (表示) します。
-u
デコードされてない NFS 操作を出力します。
-U
-w オプションが指定されないなら、印刷 (表示) されたパケット出力を ``packet-buffered'' にします。すなわち、各パケットの内容の記述が印刷 (表示) されるとき、端末に書き込まないとき、出力バッファが満杯の場合のみ書き込まれるのではなく、それは、標準出力に書き込まれます。
-w オプションが指定されるとき、保存された生のパケット出力を ``packet-buffered'' とします。すなわち、各パケットが保存されるとき、出力バッファが満杯の場合のみ書き込まれるのではなく、それは、出力ファイルに書き込まれます。
-U フラグは、 tcpdumppcap_dump_flush() 関数を欠いている古いバージョンの libpcap を使って構築されたなら、サポートされません。
-v
解析して印刷 (表示) するとき、(わずかに多く) の冗長な出力を生成します。例えば、IP パケット中の TTL、識別、全長、IP パケット中のオプションが表示されます。追加のパケットの完全性確認が有効になります。これは、例えば IP および ICMP のヘッダのチェックサムです。
-w オプションでファイルに書き込むとき、10 秒毎に獲得されたパケットの数を報告します。
-vv
さらに多くの情報を出力します。例えば、NFS の返答パケットの追加フィールドや完全にデコードされた SMB パケットを出力します。
-vvv
もっと多くの情報を出力します。例えば、telnet SB ... SE オプションが完全に表示されます。 -X 付きでは、telnet オプションが 16 進数で表示されます。
-V
file からファイル名のリストを読み込みます。 file が ``-'' であるなら、標準入力が使用されます。
-w
受信した生パケットを、解析したり画面に出力したりせずに file で指定したファイルに出力します。本オプションを用いて取得したパケットは、-r オプションを用いることで情報を見ることができます。 file で指定するファイル名が ``-'' の場合には、標準出力を用います。
この出力は、ファイルまたはパイプに書き込むなら、バッファリングされるので、ファイルまたはパイプから読み込むプログラムは、それらが受信された後に、任意の時間パケットを確認しません。 -U フラグを使用することによって、パケットは、それらが受信されるとすぐに、書き込まれます。
MIME タイプ application/vnd.tcpdump.pcap は、 pcap ファイルのための IANA で登録されました。ファイル名の拡張子 .pcap は、 .cap.dmp とともに最も共通に使用されるように思われます。 tcpdump それ自体は、捕獲ファイルを読み込むとき、拡張子をチェックせず、それらを書き込むとき、拡張子を追加しません (代わりにファイルヘッダのマジック番号を使用します)。しかしながら、多くのオペレーティングシステムとアプリケーションは、それが存在し、拡張子 (例えば、.pcap) を追加することが推奨されるなら、拡張子を使用します。
ファイル形式の記述については、 pcap-savefile(5) を参照してください。
-W
-C オプションとともに使用されるなら、作成されるファイルの数を指定された数に制限して、始めからファイルを上書きし始め、その結果、 'ローテーションする' バッファを作成します。さらに、ファイルの最大数をサポートするために十分な先導する 0 を付けたファイルに名前付けして、正しくソートできるようにします。
-G オプションと同時に使用され、これは、作成される回転されたダンプファイルの数を制限し、制限に到達するとき状態 0 で終了します。同様に、 -C と共に使用されるなら、振る舞いは、タイムスライス毎に循環するファイルの結果となります。
-x
解析して印刷するとき、各パケットのヘッダを印刷することに加えて、 16 進数で (リンクレベルヘッダを除いて) 各パケットのデータを印刷します。全体のパケットまたは snaplen バイトの小さいほうが、印刷 (表示) されます。ここで出力されるのは、リンク層のパケット全体であるため、パディングするようなリンク層 (例えばイーサネット) の場合、上位層のパケットが必要な長さよりも短かった時には、パディングされたバイトも表示されることに注意してください。
-xx
解析して印刷するとき、各パケットのヘッダを印刷することに加えて、 16 進数でリンクレベルヘッダを 含めて 、各パケットのデータを印刷します。
-X
解析して印刷するとき、各パケットのヘッダを印刷することに加えて、 16 進数と ASCII で (リンクレベルヘッダを除いて) 各パケットのデータを印刷します。新規プロトコルを解析するのに非常に便利です。
-XX
解析して印刷するとき、各パケットのヘッダを印刷することに加えて、 16 進数と ASCII でリンクレベルヘッダを 含めて 、各パケットのデータを印刷します。
-y
パケット捕捉中に使用するデータリンクタイプを datalinktype に設定します。
-z
-C または -G オプションと同時に使用され、これによって、 file が、各回転の後に savefile としてクローズされるところで、 tcpdump は、 " command file"を実行します。例えば、 -z gzip または -z bzip2 を指定すると、各 savefile は、gzip または bzip2 を使用して圧縮されます。
tcpdump は、捕獲プロセスを邪魔しないように、最も低い優先度を使用して捕獲のために並列にコマンドを実行することに注意してください、
そして、フラグまたは異なった引数を取るコマンド自体を使用したい場合、フラグと引数をアレンジメントし、利用者が望むコマンドを実行する、唯一の引数として savefile 名を取る、シェルスクリプトを常に書くことができます。
-Z
tcpdump が root として実行しているなら、出力のためのあらゆる savefile をオープンする前で、捕獲デバイスまたは入力 savefile をオープンした後に、ユーザ ID を user に変更し、グループ IDを user のプライマリグループに変更します。
また、コンパイル時にデフォルトでこの振る舞いを有効にすることもできます。
expression
ダンプするパケットを選択します。 expression が指定されない場合には、ネットワーク上のすべてのパケットがダンプ対象になります。それ以外の場合には、 expression の条件が `真' になるパケットのみダンプします。

expression の構文については、 pcap-filter(7) を参照してください。

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'

ポート 80 への、そしてポート 80 からのすべての IPv4 HTTP パケットを印刷 (表示) するには、すなわち、データを含むパケット、例えば、SYN と FIN パケット、および ACK-only パケットではなく、だけを印刷 (表示) します。 (IPv6 については、読者への課題として残しておきます)。

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

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

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

SLIP によるリンクにおいては、方向指示子 (``I'' が入力方向、``O'' が出力方向)、パケット型、そして圧縮情報が出力されます。パケット型は、最初に出力されます。パケット型には、 iputcp、そして 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
 

srcdst は、それぞれ始点と終点の IP アドレスとポート番号です。 flags は、S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) または `.' (ACK) のいくつかの組み合わせ、またはフラグが設定されていないなら、`none' です。 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 を返します。 `.' は、ACK フラグが設定されていたことを意味します。パケットは、データを含まないため、データシーケンス番号は、入りません。 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'

いくつかのオフセットとフィールド値は、数値としてではなく名前として表現されます。例えば、tcp[13] は、tcp[tcpflags] で置き換えられます。また、次の TCP フラグも利用可能です: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-act, tcp-urg。

次のようにこれを例示することができます:


tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'

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

 

UDP パケット

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

 

actinide.who > broadcast.who: udp 84
 

これは、ホスト actinidewho ポートが UDP データグラムをインターネットブロードキャストアドレスであるホスト broadcastwho ポートに対して送信していることを意味します。本パケットは、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]' が出力されます。

 

SMB/CIFS のデコード

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

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

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 が ID 6709 のトランザクションを 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 オクテットの数字でIなければ なりません。) 数字と名前は、空白文字もしくはタブ文字で区切られます。この /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

そして、クロックの精度は、カーネルクロックの精度に依存します。タイムスタンプは、カーネルが最初にパケットを見つけた時間を反映します。イーサネットインタフェースがケーブルからパケットを取り出してカーネルが「新規パケット」割り込みを受け付けるまでのタイムラグなどは補正されません

関連項目

stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-filter(7), pcap-tstamp-type(7)

http://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap

作者

元々の作者は、次の通りです:

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/old/tcpdump.tar.Z

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

バグ

問題、バグ、希望の機能拡張、パッチ等については、次のところに送ってください:

tcpdump-workers@lists.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 パケットだけを見ます。

12 July 2012