日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
TCPDUMP(1) TCPDUMP(1)
名称
tcpdump - ネットワークのトラフィックをダンプする
書式
tcpdump [ -AbdDefhHIJKlLnNOpqStuUvxX# ] [ -B buffer_size ]
[ -c count ]
[ -C file_size ] [ -G rotate_seconds ] [ -F file ]
[ -i interface ] [ -j tstamp_type ] [ -m module ] [ -M secret ]
[ --number ] [ -Q in|out|inout ]
[ -r file ] [ -V file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ]
[ -E spi@ipaddr algo:secret,... ]
[ -y datalinktype ] [ -z postrotate-command ] [ -Z user ]
[ --time-stamp-precision=tstamp_precision ]
[ --immediate-mode ] [ --version ]
[ expression ]
解説
tcpdump は、ブール値 expression (式) にマッチするネットワークインタ
フェースのパケットの内容の記述を印刷 (表示) します。説明は、タイムスタ
ンプによって先行され、デフォルトで、真夜中以来の時、分、秒、と秒の分数
として、印刷 (表示) されます。また、それは、-w フラグによって後の解析の
ためのファイルにパケットデータを保存して、実行することができ、および/ま
たは -r フラグによって、ネットワークインタフェースからパケットを読み込
むのではなく保存されたパケットファイルから読み込みます。また、それは、
保存されたパケットファイルのリストを読み込む、-V フラグで実行することが
できます。すべての場合に、expression と一致するパケットだけが、tcpdump
によって処理されます。
tcpdump は、-c フラグを付けて実行されないなら、(例えば、利用者の割り込
み文字通常 control-C によって生成される) SIGINT シグナルまたは (通常、
kill(1) コマンドによって生成される) SIGTERM シグナルによって割り込まれ
るまで、パケットを捕獲し続けます。-c フラグを付けて実行されるなら、
SIGINT または、SIGTERM シグナルによって割り込まれるか、またはパケットの
指定された数が処理されるまで、パケットを捕獲します。
tcpdump がパケットを捕獲することを終わるとき、それは、次のカウントを報
告します:
``捕獲された" パケット (これは、tcpdump が受信し、処理したパケッ
トの数です)。
``フィルタによって受信された'' パケット (この意味は、利用者が実
行している tcpdump で OS に依存します、たぶん OS が設定された方
法に依存し - フィルタがコマンド行で指定されたなら、いくつかの OS
で、フィルタ表現によって一致してもしなくてもパケットをカウント
し、たとえそれらがフィルタ表現によって一致しても、tcpdump がまだ
それら読み込み処理してもしなくても、他の OS で、フィルタ表現に
よって一致していたパケットだけをカウントし、tcpdump によって処理
されました。
``カーネルによって落とされる'' パケット (これは、OS がその情報を
アプリケーションに報告するなら、tcpdump が実行している OS のパ
ケット捕獲メカニズムによってバッファ空間の不足のために、落とされ
たパケットの数です。そうでなければ、それは、0 として報告されま
す。)
SIGINFO シグナルをサポートするプラットフォームで、(Mac OS X を含んで)
ほとんどの BSD と Digital/Tru64 UNIX のような、生成された SIGINFO シグ
ナルを受信するとき、それらのカウントを報告します (例えば、利用者の
``status'' 文字、通常 control-T ををタイプすることによって生成されます
が、いくつかのプラットフォームで、Mac OS X のような、``status'' 文字
は、デフォルトで設定されないので、利用者は、それを使用する順序で
stty(1) 設定されなければなりません)、そしてパケットを捕獲することを続け
ます。SIGINFO シグナルをサポートしないプラットフォームで、SIGUSR1 シグ
ナルを使用することによって、達成することができます。
ネットワークインタフェースからの読み込んでいるパケットは、利用者が特別
の特権があることを必要とします。詳細については、pcap (3PCAP) マニュアル
ページを参照してください。保存されているパケットファイルの読み込みに、
特権を必要としません。
オプション
-A (リンクレベルヘッダがない) 各パケットを ASCII で印刷 (表示) しま
す。web ページを捕捉するために便利です。
-b ASPLAIN 記法でなく ASDOT 記法で BGP パケットの AS 番号を印刷しま
す。
-B buffer_size
--buffer-size=buffer_size
オペレーティングシステムの獲得バッファサイズを KiB (1024 バイト)
の単位で buffer_size に設定します。
-c count
count パケットを受信した後に終了します。
-C file_size
生のパケットを保存ファイルに書き込む前に、ファイルが file_size
より大きいかどうかをチェックし、そうであるなら、現在の保存ファイ
ルをクローズし、新しいものをオープンします。最初の保存ファイルの
後の保存ファイルは、1 で始まり、上方に続ける、その後の数で -w フ
ラグで指定された名前があります。file_size の単位は、100 万バイト
(1,048,576 バイトのことでなく、1,000,000 バイト) です。
-d 人間に読み込み可能な形式でコンパイルされたパケットマッチングコー
ドを標準出力にダンプし、停止します。
-dd C プログラムのフラグメントとしてパケットマッチングコードをダンプ
します。
-ddd (カウントが先行する) 10 進数としてパケットマッチングコードをダン
プします。
-D
--list-interfaces
システムで利用可能で、tcpdump がパケットを捕獲することができる
ネットワークインタフェースのリストを印刷 (表示) します。場合によ
りインタフェースのテキストの説明が続く、ネットワークインタフェー
ス、数値とインタフェース名ごとに印刷 (表示) されます。捕獲するイ
ンタフェースを指定するために -i フラグでインタフェース名または数
値を供給することができます。
これは、それらをリストするコマンドがないシステム (例えば、
ifconfig -a を欠く Windows システム、または UNIX システム) で役
に立つことができます。インタフェース名は、多少複雑な文字列であ
る、Windows 2000 と以降のシステムで数値を役に立てることができま
す。
tcpdump が、pcap_findalldevs() 関数を欠く libpcap の古いバージョ
ンで構築されているなら、-D フラグは、サポートされません。
-e 各ダンプ行で、リンクレベルのヘッダを印刷 (表示) します。これは、
例えば、イーサネットと IEEE 802.11 のようなプロトコルのための
MAC レイヤ (層) アドレスを印刷するために、使用することができま
す。
-E addr にアドレス指定され、セキュリティパラメータインデックス値
spi を含む、IPsec ESP パケットを暗号解読するために spi@ipaddr
algo:secret を使用します。この組み合わせは、コンマまたは改行で区
切られ繰り返されます。
現時点で IPv4 ESP パケットのための秘密 (secret) を設定すること
が、サポートされることに注意してください。
アルゴリズムは、des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc,
cast128-cbc または none です。デフォルトは、des-cbc です。パケッ
トを暗号解読する能力は、tcpdump が有効にされた暗号化でコンパイル
されていた場合のみ、存在します。
secret は、ESP 秘密キーのための ASCII テキストです。0x が先行す
るなら、16 進数の値が、読み込まれます。
オプションは、RFC 1827 ESP ではなく、RFC 2406 ESP を仮定していま
す。オプションは、デバッグの目的のためだけであり、真の `secret'
キーをつけたこのオプションの使用は、推奨されません。コマンド行に
IPsec 秘密キーを提示することによって、利用者は、ps(1) と他の機会
を通して他にそれを見えるようにします。
上記の構文に加えて、構文 file name は、提供されたファイルを読み
込む tcpdump に使用されます。ファイルは、最初の ESP パケットを受
信するときオープンされるので、tcpdump に与えられているあらゆる特
別なパーミッションは、すでに放棄されているべきです。
-f シンボルでなく `foreign' IPv4 アドレスの数値を印刷 (表示) します
(このオプションは、Sun の NIS サーバの重大な障害を回避することを
意図しています -- 通常、それは、ローカルでないインターネット番号
を永久に変換することをハングアップします)。
`foreign' IPv4 アドレスのためのテストは、捕獲が行なわれているイ
ンタフェースの IPv4 アドレスとネットマスクを使用して行なわれま
す。そのアドレスまたはネットマスクが利用可能ではなく、捕獲が行な
われているインタフェースにアドレスまたはネットマスクがないので、
または複数のインタフェースで捕獲することができる Linux の "any"
インタフェースで行なわれているので、このオプションは、正しく動作
しません。
-F file
フィルタ表現のための入力として file を使用します。コマンド行で与
えられた追加の表現は、無視されます。
-G rotate_seconds
指定されるなら、rotate_seconds 秒毎に -w オプションで指定された
ダンプファイルをローテート (回転) させます。savefile は、
strftime(3) によって定義されるように、時間形式を含むべきである
-w によって指定された名前があります。時間形式が指定されないな
ら、それぞれの新しいファイルは、前のものを上書きします。
-C オプションと同時に使用されるなら、ファイル名は、`file<count>'
の形式を取ります。
-h
--help tcpdump と libpcap バージョンの文字列を印刷し、使用法のメッセー
ジを印刷し、終了します。
--version
tcpdump と libpcap バージョンの文字列を印刷 (表示) し、終了しま
す。
-H 802.11s 草案のメッシュヘッダを検出することを試みます。
-i interface
--interface=interface
interface listen (接続を受け付け) します。指定されないなら、
tcpdump は、(ループバックを除いて) 設定されたインタフェース、最
も小さい番号が付けられたシステムインタフェースのリストに検索しま
す、例えば、"eth0"。
2.2 以降のカーネルがある Linux システムで、すべてのインタフェー
スからパケットを捕獲するために ``any'' の interface 引数を使用す
ることができます。``any'' デバイスでの捕獲は、promiscuous (不規
則) なモードで行なわれないことに注意してください。
-D フラグがサポートされているなら、そのフラグによって印刷 (表示)
されるようなインタフェース番号は、システムのインタフェースに名前
としてその番号がないなら、interface 引数として使用することができ
ます。
-I
--monitor-mode
"モニタモード" のインタフェースの状態にします。これは、IEEE
802.11 Wi-Fi インタフェースのみでサポートされ、いくつかのオペ
レーティングシステムでのみサポートされます。
モニタモードで、アダプタは、利用者がそのアダプタでどんなワイヤレ
スネットワークでも使用できないように、それが関連しているネット
ワークから分離するかもしれないことに注意してください、これは、モ
ニタモードでキャプチャし、別のアダプタで別のネットワークに接続さ
れないなら、ネットワークサーバでファイルにアクセスを防ぐか、また
はホスト名かネットワークアドレスの解決を防ぐかもしれません、
このフラグは、-L フラグの出力に影響します。-I が指定されないな
ら、モニタモードでないとき利用可能なそれらのリンクレイヤのタイプ
だけが表示されます。-I が指定されるなら、モニタモードであるとき
利用可能なそれらのリンクレイヤのタイプだけが表示されます。
--immediate-mode
"即時モード" で捕獲します。このモードで、効率のためにバッファリ
ングされるのではなく、それらが到着するとすぐにパケットは、
tcpdump に配信されます。これは、パケットがファイルまたはパイプで
はなく端末に印刷 (表示) されているなら、パケットを ``savefile''
に保存するのではなく、パケットを印刷 (表示) するとき、デフォルト
です。
-j tstamp_type
--time-stamp-type=tstamp_type
捕獲のためのタイムスタンプのタイプを tstamp_type に設定します。
タイムスタンプのタイプのために使用する名前は、pcap-tstamp(7) で
与えられます。そこにリストされたすべてのタイプは、あらゆる与えら
れたインタフェースに対して有効になるとは限りません。
-J
--list-time-stamp-types
インタフェースのためにサポートされたタイムスタンプのタイプをリス
トして、終了します。インタフェースに対してタイムスタンプのタイプ
を設定することができないなら、タイムスタンプのタイプは、リストさ
れません。
--time-stamp-precision=tstamp_precision
捕獲されるとき、捕獲のためのタイムスタンプの精度を
tstamp_precision に設定します。高い精度のタイムスタンプ (ナノ秒)
とそれらの実際の精度の利用可能性は、プラットフォームとハードウェ
ア依存であることに注意してください。また、ナノ秒の精度で行われる
捕獲を保存ファイルに書き込むとき、タイムスタンプは、タイムスタン
プが、秒とナノ秒単位であることを示して、ナノ秒の解像度で書き込ま
れ、ファイルは、異なったマジックナンバで書き込まれることに注意し
てください。pcap 保存ファイルを読み込むすべてのプログラムは、そ
れらの捕獲を読み込むことができるとは限りません。
保存ファイルを読み込むとき、タイムスタンプを、timestamp_precision に
よって指定された精度に変換し、その解像度でそれらを表示します。指定され
た精度がファイルのタイムスタンプの精度より少ないなら、変換は、精度を失
います。
timestamp_precision のためのサポートされた値は、マイクロ秒の解像度に対
して micro で、ナノ秒の解像度に対して nano です。デフォルトは、マイクロ
秒の解像度です。
-K
--dont-verify-checksums
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
--list-data-link-types
指定されたモードでインタフェースのための既知のデータリンクタイプ
をリストし、終了します。既知のデータリンクタイプのリストは、指定
されたモードに依存しています。例えば、いくつかのプラットフォーム
では、Wi-Fi インタフェースは、モニタモードでないとき、(例えば、
ラジオ情報で偽のイーサネットヘッダのみをサポートするかもしれませ
ん、または 802.11 ヘッダをサポートするかもしれませんが、802.11
ヘッダをサポートしません) データリンクタイプのセットの 1 つを、
モニタモードのとき、(例えば、モニタモードでのみラジオ情報で
802.11 ヘッダ、または 802.11 ヘッダをサポートするかもしれません)
データリンクタイプの別のセットをサポートするかもしれません。
-m module
ファイル module から SMI MIB モジュール定義をロードします。いく
つかの MIB モジュールを tcpdump にロードするために、このオプショ
ンを数回使用することができます。
-M secret
存在するなら、TCP-MD5 オプション (RFC2385) で TCP セグメントにあ
るダイジェストを有効にするための共有された秘密として secret を使
用します。
-n アドレス (すなわち、ホストアドレス、ポート番号など) を名前に変換
しません。
-N ホスト名のドメイン名の資格を印刷 (表示) しません。例えば、利用者
がこのフラグを与えるなら、tcpdump は、``nic.ddn.mil'' の代わりに
``nic'' を印刷 (表示) します。
-#
--number
行の最初でオプションのパケット数を印刷 (表示) します。
-O
--no-optimize
パケットマッチングコードのオプティマイザを実行しません。これは、
利用者がオプティマイザのバグを疑っている場合のみ役に立ちます。
-p
--no-promiscuous-mode
インタフェースを promiscuous (不規則) モードに入れません。インタ
フェースは、いくらかの他の理由のために promiscuous (不規則) モー
ドであるかもしれないことに注意してください。したがって、`-p'
は、`ether host {local-hw-addr} or ether broadcast' のための短縮
形として使用することはできません。
-Q direction
--direction=direction
パケットが捕獲されるべき送信/受信方向 direction を選択します。指
定できる値は、`in', `out' と `inout' です。すべてのプラット
フォームで利用可能であるとは限りません。
-q 迅速な (静寂?) 出力。少ないプロトコル情報を印刷 (表示) するの
で、出力行は、より短くなります。
-r file
(-w オプションで、または pcap または pcap-ng ファイルを書き込む
他のツールによって作成された) file からパケットを読み込みます。
file が ``-'' であるなら、標準入力が使用されます。
-S
--absolute-tcp-sequence-numbers
TCP シーケンス番号を相対番号でなく絶対番号で印刷 (表示) します。
-s snaplen
--snapshot-length=snaplen
262144 バイトのデフォルトでなく各パケットから snaplen バイトの
データを取得します。制限されたスナップショットのために切り詰めら
れたパケットは、``[|proto]'' で出力に示されます、ここで、proto
は、切り詰めが起こったプロトコルレベルの名前です。大きいスナップ
ショット取ることは、パケットを処理するために、取る時間の量を増加
させ、効果的にパケットのバッファリングの量を減少させることに注意
してください。これによって、パケットを失うかもしれません。利用者
は、snaplen を利用者が興味を持っているプロトコル情報を獲得する最
も少ない数に制限するべきです。tcpdump の最近の古いバージョンとの
後方互換性のためにデフォルトの 262144 にするために snaplen を 0
に設定します。
-T type
"expression" によって選択されたパケットを指定された type と解釈
されるように強制します。現在知られているタイプは、aodv (Ad-hoc
On-demand Distance Vector プロトコル), carp (Common Address
Redundancy プロトコル), cnfp (Cisco NetFlow プロトコル), lmp
(Link Management プロトコル), pgm (Pragmatic General Multicast),
pgm_zmtp1 (ZMTP/1.0 inside PGM/EPGM), resp (REdis Serialization
プロトコル), radius (RADIUS), rpc (Remote Procedure Call), rtp
(Real-Time Applications プロトコル), rtcp (Real-Time
Applications control プロトコル), snmp (Simple Network
Management プロトコル), tftp (Trivial File Transfer プロトコル),
vat (Visual Audio Tool), wb (distributed White Board), zmtp1
(ZeroMQ Message Transport プロトコル 1.0) と vxlan (Virtual
eXtensible Local Area Network) です。
上記の pgm タイプは、UDP の解釈のみに影響し、負の PGM は、常に
IP プロトコル 113 と認識されることに注意してください。UDP カプセ
ル化された PGM は、しばしば "EPGM" または "PGM/UDP" と呼ばれま
す。
上記の pgm_zmtp1 タイプは、同時に負の PGM と UDP の両方の解釈に
影響することに注意してください。ODATA/RDATA パケットのアプリケー
ションデータをデコードしている負の PGM の間に、ZMTP/1.0 フレーム
で ZeroMQ データグラムとしてデコードされます。あらゆる UDP パ
ケットがカプセル化された PGM パケットとして扱われることに加えて
UDP のデコードの間。
-t 各ダンプ行でのタイムスタンプを印刷 (表示) しません。
-tt 1970 年 1 月 1 日 00 時 00 分 00 秒、UTC 以来の秒数と各ダンプ行
で、その時以来の秒の分数として、タイムスタンプを印刷 (表示) しま
す。
-ttt 各 dump 行で、現在と以前の行の間の差分 (マイクロ秒の解像度) を印
刷 (表示) します。
-tttt 各 dump 行で、日付に先行する真夜中以来の時、分、秒、と秒の分数と
して、タイムスタンプを印刷 (表示) します。
-ttttt 各ダンプ行で、現在と最初の行の間の差分 (マイクロ秒の解像度) を印
刷 (表示) します。
-u デコードされない NFS 操作を印刷 (表示) します。
-U
--packet-buffered
-w オプションが指定されないなら、印刷 (表示) されたパケット出力
を ``packet-buffered'' にします。すなわち、各パケットの内容の記
述が印刷 (表示) されるとき、端末に書き込まないとき、出力バッファ
が満杯の場合のみ書き込まれるのではなく、それは、標準出力に書き込
まれます。
-w オプションが指定されるとき、保存された生のパケット出力を
``packet-buffered'' とします。すなわち、各パケットが保存されると
き、出力バッファが満杯の場合のみ書き込まれるのではなく、それは、
出力ファイルに書き込まれます。
-U フラグは、tcpdump が pcap_dump_flush() 関数を欠いている古い
バージョンの libpcap を使って構築されたなら、サポートされませ
ん。
-v 解析して印刷 (表示) するとき、(わずかに多く) の冗長な出力を生成
します。例えば、IP パケットの有効期間、識別、合計の長さ、とオプ
ションが、印刷 (表示) されます。また、IP と ICMP ヘッダのチェッ
クサムを検証するのような、追加のパケットの整合性チェックを有効に
します。
-w オプションでファイルに書き込むとき、10 秒毎に獲得されたパケッ
トの数を報告します。
-vv さらなる冗長な出力。例えば、追加のフィールドは、NFS 応答パケット
から印刷 (表示) され、SMB パケットは、完全にデコードされます。
-vvv さらなる冗長な出力。例えば、telnet SB ... SE オプションは、完全
に印刷 (表示) されます。-X を付けて、telnet オプションは、同様に
16 進数で印刷 (表示) されます。
-V file
file からファイル名のリストを読み込みます。file が ``-'' である
なら、標準入力が使用されます。
-w file
それらを解析して印刷 (表示) するのではなく、生のパケットを 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
--linktype=datalinktype
パケットを捕捉している間に使用するデータリンクタイプを
datalinktype に設定します。
-z postrotate-command
-C または -G オプションと同時に使用され、これによって、file が、
各回転の後に savefile としてクローズされるところで、tcpdump は、
"postrotate-command file" を実行します。例えば、-z gzip または
-z bzip2 を指定すると、各 savefile は、gzip または bzip2 を使用
して圧縮されます。
tcpdump は、捕獲プロセスを邪魔しないように、最も低い優先度を使用
して捕獲のために並列にコマンドを実行することに注意してください、
そして、フラグまたは異なった引数を取るコマンド自体を使用したい場
合、フラグと引数をアレンジメントし、利用者が望むコマンドを実行す
る、唯一の引数として savefile 名を取る、シェルスクリプトを常に書
くことができます。
-Z user
--relinquish-privileges=user
tcpdump が root として実行しているなら、出力のためのあらゆる
savefile をオープンする前で、捕獲デバイスまたは入力 savefile を
オープンした後に、ユーザ ID を user に変更し、グループ IDを user
のプライマリグループに変更します。
また、コンパイル時にデフォルトでこの振る舞いを有効にすることもで
きます。
expression
ダンプするパケットを選択します。expression が指定されない場合に
は、ネットワーク上のすべてのパケットがダンプ対象になります。それ
以外の場合には、expression の条件が `真' になるパケットのみダン
プします。
expression の構文については、pcap-filter(7) を参照してください。
どちらかより便利な、単一のシェル引数または複数のシェル引数として
tcpdump に、expression 引数を渡すことができます。一般的に、式が
プロトコル名をエスケープするために使用されるバックスラッシュのよ
うなシェルのメタキャラクタを含んでいるなら、シェルのメタキャラク
タをエスケープするのではなくシングルクォートで囲まれた引数として
それを渡すほうが簡単です。複数の引数は、解析される前に空白で連結
されます。
使用例
sundown に到着するか、またはそこから出発するすべてのパケットを印刷 (表
示) するためには、次の通りです:
tcpdump host sundown
helios と hot またはr 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)'
発信元でもなく、ローカルホストのための宛先でもないトラフィックを印刷
(表示) するためには、次の通りです (1 つの他のネットへの利用者ゲートウェ
イであるなら、このスタッフは、利用者のローカルネットでそれを決して行な
うべきではありません)。
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 を通して送信される 576 バイト以上の IP パケットを印刷
(表示) するためには、次の通りです:
tcpdump 'gateway snup and ip[2:2] > 576'
イーサネットのブロードキャスト (同報通信) またはマルチキャストを通して
送信されなかった IP ブロードキャスト (同報通信) またはマルチキャストパ
ケットを印刷 (表示) するためには、次の通りです:
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
エコー要求/応答 (すなわち、ping パケットではなく) されないすべての ICMP
パケットを印刷 (表示) するためには、次の通りです:
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
出力形式
tcpdump の出力は、プロトコル依存です。短い説明と形式のほとんどの例は、
次に与えられます。
タイムスタンプ
デフォルトで、すべての出力行は、タイムスタンプが先行します。タイムスタ
ンプは、形式
hh:mm:ss.frac
の現在のクロック時間で、カーネルのクロックと同じくらい正確です。タイム
スタンプは、カーネルがタイムスタンプをパケットに適用した時間を反映しま
す。カーネルがタイムスタンプをパケットに適用したとき、ネットワークイン
タフェースがネットワークからパケットを受信することを終了するとき、間の
タイムラグを説明する試みは、行いません。そのタイムラグは、ネットワーク
インタフェースがネットワークからパケットを受信することを終了するときの
時間と割り込みがネットワークからそれを取得するカーネルに配信されるとき
の時間の間の遅延とカーネルが、`新しいパケット' 割り込みをサービスしたと
きの時間とパケットのタイムスタンプを適用するときの時間の間の遅延を含む
かもしれません。
リンクレベルヘッダ
'-e' オプションが与えられるなら、リンクレベルヘッダが、印刷 (表示) され
ます。イーサネットで、発信元と宛先アドレス、プロトコルとパケット長が印
刷 (表示) されます。
FDDI ネットワークでは、'-e' オプションによって、tcpdump は、`フレーム制
御' フィールド、発信元と宛先アドレスとパケット長を印刷 (表示) します。
(`フレーム制御' フィールドは、パケットの残りの解釈を管理します。(それら
が含んでいる IP データグラムのような) 通常のパケットは、0 から 7 までの
優先度がある `async' パケットです。例えば、`async4'。そのようなパケット
は、802.2 論理的なリンク制御 (Logical Link Control; LLC) パケットを含む
と仮定されます。LLC ヘッダは、それが ISO データグラムまたはいわゆる
SNAP パケットではないなら、印刷 (表示) されます。
トークンリング (Token Ring) ネットワークで、'-e' オプションによって、
tcpdump は、`アクセス制御' と `フレーム制御' フィールド、発信元と宛先ア
ドレスとパケット長を印刷 (表示) します。FDDI ネットワークと同様に、パ
ケットは、LLC パケットを含むと仮定されます。'-e' オプションが指定される
かどうかにかかわらず、指定経路制御情報は、発信元経路のパケットのために
印刷 (表示) されます。
802.11 ネットワークで、'-e' オプションによって、tcpdump は、`フレーム制
御' フィールド、802.11 ヘッダのアドレスのすべてとパケット長を印刷 (表
示) します。FDDI ネットワークと同様に、パケットは、LLC パケットを含むと
仮定されます。
(注: 次の説明は、RFC-1144 に記述された SLIP 圧縮アルゴリズムで良く知っ
ていることを仮定します。)
SLIP リンクで、方向指示子 (入力方向のための ``I''、出力方向のための
``O'')、パケットタイプと圧縮情報が、印刷 (表示) されます。パケットタイ
プは、最初に印刷 (表示) されます。3 つのタイプは、ip、utcp と ctcp で
す。さらなるリンク情報は、ip パケットのために印刷 (表示) されません。
TCP パケットのために、接続識別子は、タイプに続いて印刷 (表示) されま
す。パケットが圧縮されているなら、そのエンコードされたヘッダが、印刷
(表示) されます。特別な場合は、*S+n と *SA+n として印刷 (表示) され、こ
こで、n は、シーケンス番号 (または、シーケンス番号と ack) が変更された
量です。それが特別な場合ではないなら、0 以上の変更が印刷 (表示) されま
す。変更は、U (至急ポインタ)、W (ウィンドウ)、A (ack)、S (シーケンス番
号)と I (パケット ID) によって示され、デルタ (+n または -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
最初の行は、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 が行なわれたなら、最初のパケットがブロードキャスト (同報通
信) され、2 番目がポイントツーポイント (point-to-point) であるという事
実は、明らかになるかもしれません:
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 バイトであったことを記述しています。
IPv4 パケット
IPv4 パケットのためにリンクレイヤのヘッダが印刷 (表示) されていないな
ら、IP は、タイムスタンプの後に印刷 (表示) されます。
-v フラグが指定されるなら、IPv4 ヘッダからの情報は、IP またはリンクレイ
ヤのヘッダの後に括弧で囲まれて表示されます。この情報の一般的な形式は、
次の通りです:
tos tos, ttl ttl, id id, offset offset, flags [flags], proto proto, length length, options (options)
tos は、サービスフィールドのタイプです。ECN ビットが 0 でないなら、それ
らは、ECT(1), ECT(0) または CE として報告されます。ttl は、有効期間で
す。それが 0 であるなら、報告されません。id は、IP 識別フィールドです。
offset は、フラグメントオフセットフィールドです。これが、フラグメントさ
れたデータグラムの一部であるかどうかが、印刷 (表示) されます。flags
は、MF と DF フラグです。+ は、MF が設定されるなら、報告され、DFP は、F
が設定されるなら、報告されます。いずれも設定されないなら、. が報告され
ます。proto は、プロトコル ID フィールドです。length は、合計の長さ
フィールドです。options は、もしあるなら、IP オプションです。
次に、TCP と UDP パケットについて、各 IP アドレスとその対応したポートの
間のドットがある、発信元と宛先 IP アドレスと TCP または UDP ポートは、
発信元と宛先を分離する > を付けて印刷 (表示) されます。他のプロトコルに
ついて、アドレスは、発信元と宛先を分離する > を付けて印刷 (表示) されま
す。高いレベルのプロトコル情報は、もしあるなら、その後に印刷 (表示) さ
れます。
フラグメント化された IP データグラムについて、最初のフラグメントは、高
いレベルのプロトコルヘッダを含んでいます。最初の後のフラグメントは、高
いレベルのプロトコルヘッダを含んでいません。フラグメンテーションの情報
は、上での説明されるように IP ヘッダ情報で -v フラグでのみ印刷 (表示)
されます。
TCP パケット
(注意: 次の説明は、RFC-793 に説明された TCP プロトコルで熟知を仮定しま
す。もし利用者がプロトコルに精通していないなら、この説明は、利用者の使
用にあまり役に立ちません。)
TCP プロトコル行の一般的な形式は、次の通りです:
src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len
src と dst は、発信元と宛先の IP アドレスとポートです。Tcpflags は、S
(SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo)
または `.' (ACK) のいくつかの組み合わせ、またはフラグが設定されていない
なら、`none' です。data-seqno は、このパケットのデータによってカバーさ
れたシーケンス空間の部分を説明しています (以下の例を参照)。ackno は、こ
の接続で他の方向に期待される次のデータのシーケンス番号です。window は、
この接続の他の方向で利用可能な受信バッファ空間のバイトです。urg は、パ
ケットの `urgent' (緊急) データがあることを示します。opts は、TCP オプ
ションです (例えば、mss 1024)。len は、ペイロード (ヘッダ部を除いたデー
タの本体) データの長さです。
Iptype, Src, dst と flags は、常に提示されます。他のフィールドは、パ
ケットの TCP プロトコルヘッダの内容に依存して、適切な場合のみ出力されま
す。
ここに、ホスト rtsg からホスト csam に rlogin の開設部分を示します。
IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]
IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096
IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1
IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096
IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19
IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1
IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1
IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1
最初の行は、rtsg の TCP ポート 1023 が csam のポート login にパケットを
送信することを記述しています。S は、SYN フラグが設定されていたことを示
します。パケットのシーケンス番号は、768512 であり、それは、データを含ん
でいませんでした。(表記法は、last を含んでいない、シーケンス番号 first
までを意味している `first:last' です。) ピギーバック ack がなく、利用可
能な受信ウィンドウは、4096 バイトであり、1024 バイトの mss を要求してい
る最高セグメントサイズのオプションがありました。訳注: ピギーバックは、
他人の無線インターネット接続を無断で利用すること。
csam は、rtsg の SYN のためのピギーバック ack を含んでいることを除い
て、同様のパケットで応答します。次に、rtsg は、csam の SYN への ack を
返します。`.' は、ACK フラグが設定されていたことを意味します。パケット
は、データを含んでいないので、データシーケンス番号または長さは、ありま
せん。ack シーケンス番号は、小さい整数 (1) であることに注意してくださ
い。はじめて tcpdump は、TCP `conversation (通信)' を調べて、それは、パ
ケットからのシーケンス番号を印刷 (表示) します。conversation (通信) の
その後のパケットで、現在のパケットのシーケンス番号とこの初期のシーケン
ス番号の間の違いが印刷 (表示) されます。これは、最初の後のシーケンス番
号が、(最初のデータバイトの各方向が `1' である) 通信のデータストリーム
の相対的なバイト位置として解釈することができることを意味しています。
`-S' は、オリジナルのシーケンス番号を出力して、この機能を上書きします。
6 番目の行で、rtsg は、19 バイトのデータを csam に送信します (通信の
rtsg -> csam 側の 2 から 20 までのバイト)。PUSH フラグは、パケットで設
定されます。7 番目の行で、csam は、それが、バイト 21 を含みませんが、
rtsg によって受信されたデータであることを記述します。このデータのほとん
どは、見たところで、csam の受信ウィンドウが、19 バイト小さくなったの
で、ソケットバッファに位置しています。また、csam は、1 バイトのデータを
このパケットで rtsg に送信します。8 番目と 9 番目の行で、csam は、プッ
シュされたデータを rtsg に緊急に 2 バイトを送信します。
スナップショットが完全な TCP ヘッダを捕獲しなかった、その tcpdump に十
分に小さかったなら、それは、できる限り多くヘッダを解釈し、次にそれか
ら、残りが解釈できなかったことを示すために、``[|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)。単に平板な初期の SYN である、ステップ 2 (SYN-ACK) からパ
ケットを必要としないことに注意してください。必要なものは、tcpdump のた
めの正しいフィルタ表現です。
オプションなしで TCP ヘッダの構造を再呼び出しします:
0 15 31
-----------------------------------------------------------------
| 発信元ポート | 宛先ポート |
-----------------------------------------------------------------
| シーケンス番号 |
-----------------------------------------------------------------
| 確認応答番号 |
-----------------------------------------------------------------
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
-----------------------------------------------------------------
| TCP チェックサム | 緊急ポインタ |
-----------------------------------------------------------------
TCP ヘッダは、オプションが存在しないなら、通常データの 20 オクテットを
保持します。グラフの最初の行は、オクテット 0 - 3、2 番目の行は、オク
テット 4 - 7 その他を含んでいます。
0 でカウントを開始して、関連する TCP 制御ビットは、オクテット 13 に含ま
れます:
0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
----------------|---------------|---------------|----------------
| |13 オクテット目| | |
オクテット no. 13 をよく調べましょう:
| |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
これらは、興味がある TCP 制御ビットです。右から左に、0 から 7 までのこ
のオクテットのビットに番号が付けられるので、PSH ビットは、ビット番号 3
で、一方、URG ビットは、番号 5 です。
SYN セットだけでパケットを捕獲したいことを思い起こします。TCP データグ
ラムが、そのヘッダに設定された SYN ビットで到着するなら、オクテット 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 ビット符号なし整数であ
ることを仮定し、このオクテットのバイナリの値は、
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
設定された SYN のみがあるパケットを監視するための順序で、tcpdump のため
のフィルタとしてこの表現を使用することができます:
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|
今、ビット 1 と 4 は、13 番目のオクテットに設定されています。オクテット
13 のバイナリの値は、10 進数に変換される
00010010
です。
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
SYN-ACK 設定がある、それらのパケットだけを選択しますが、SYN 設定だけで
ないので、今、ちょうど、tcpdump フィルタ式で 'tcp[13] == 18' を使用する
ことはできません。ACK または何かの他の制御ビットが、SYN が設定されるの
と同じくらい設定されるなら、気にしないことを覚えておいてください。
ゴールを達成するために、SYN ビットを保存するいくらかの他の値があるオク
テット 13 のバイナリ値を論理的に論理積 (AND) する必要があります。どんな
場合でも、SYN が設定されて欲しいことを知っているので、SYN のバイナリの
値がある 13 番目のオクテットの値を論理的に論理積 (AND) します:
00010010 SYN-ACK 00000010 SYN
AND 00000010 (SYN が欲しい) AND 00000010 (SYN が欲しい)
-------- --------
= 00000010 = 00000010
ACK または別の TCP 制御ビットが設定されるかどうかにかかわらず、同じ結果
となる、この AND 操作であることがわかります。この操作の結果と同様に AND
値の 10 進数の表現は、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
これは、ホスト actinide のポート who が、インターネットブロードキャスト
(同報通信)アドレスのホスト broadcast のポート who に udp データグラムを
送信していることを記述しています。パケットは、ユーザデータの 84 バイト
を含んでいました。
いくつかの UDP サービスは、(発信元または宛先ポート番号から) 認識され、
上位レベルのプロトコル情報が、印刷 (表示) されます。特に、NFS へのドメ
インネームサービス要求 (RFC-1034/1035) と Sun RPC 呼び出し (RFC-1050)。
UDP ネームサーバ要求
(注意: 次の説明は、RFC-1035 に記述されているドメインサービスプロトコル
との良く知っていることを仮定しています。利用者がプロトコルに精通せず、
次の説明が greek (ギリシャ語) で書かれているように思われるでしょう。)
ネームサーバの要求は、次のように書式化されます。
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
ホスト h2opolo は、名前 ucbvax.berkeley.edu と関連するアドレスレコード
(qtype=A) のための helios でドメインサーバに問い合わせました。問い合わ
せ ID は、`3' でした。`+' は、再帰要求フラグが設定されたことを示しま
す。問い合わせの長さは、UDP と IP プロトコルヘッダを含まない 37 バイト
でした。問い合わせ操作は、通常のもので Query であったので、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)
最初の例で、helios は、3 つの答えレコード、3 つのネームサーバレコードと
7 つの追加のレコードで h2opolo からの問い合わせ id 3 に応答します。最初
の答えレコードは、タイプ A (アドレス) で、そのデータは、インターネット
アドレス 128.32.137.3 です。応答の合計のサイズは、UDP と IP ヘッダを除
いて、273 バイトでした。op (問い合わせ) と応答コード (NoError) は、A レ
コードのクラス (C_IN) であったように省略されました。
2 番目の例で、helios は、1 つのネームサーバと権限レコードなしで、存在し
ないドメイン (NXDomain) の応答コードで問い合わせ 2 に応答します。`*'
は、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 (ネットワークファイルシステム) 要求と応答は、次のように印刷 (表
示) されます:
src.sport > dst.nfs: NFS request xid xid len op args
src.nfs > dst.dport: NFS reply xid xid reply stat len op results
sushi.1023 > wrl.nfs: NFS request xid 26377
112 readlink fh 21,24/10.73165
wrl.nfs > sushi.1023: NFS reply xid 26377
reply ok 40 readlink "../var"
sushi.1022 > wrl.nfs: NFS request xid 8219
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.1022: NFS reply xid 8219
reply ok 128 lookup fh 9,74/4134.3150
最初の行で、ホスト sushi は、id 26377 から wrl までトランザクションを送
信します。要求は、UDP と IP ヘッダを除いて 112 バイトでした。操作は、
ファイルハンドル (fh) 21,24/10.731657119 で (シンボリックリンクを読み込
む) readlink でした。(この場合のように、ラッキであるなら、inode 番号と
世代番号が続いている、メジャー、マイナのデバイス番号のペアとしてファイ
ルハンドルを解釈することができます。) 2 番目の行で、wrl は、同じトラン
ザクション id とリンクの内容で `ok' を応答します。
3 番目の行で、sushi は、ルックアップにディレクトリファイル
9,74/4096.6878 の名前 `xcolors' を検索するために (新しいトランザクショ
ン id を使用して) wrl に問い合わせます。4 番目の行で、wrl は、個別のト
ランザクション id で返答を送信します。
印刷 (表示) されたデータは、操作タイプに依存していることに注意してくだ
さい。形式は、NFS プロトコルの仕様とともに読み込まれるなら、一目瞭然で
あることを意図しています。また、tcpdump の古いバージョンは、少し異なっ
た形式で NFS パケットを印刷 (表示) したことに注意してください: トランザ
クション id (xid) は、パケットの NFS ポート番号の代わりに印刷 (表示) さ
れます。
-v (冗長) フラグが与えられるなら、追加の情報が印刷 (表示) されます。例
えば、次の通りです:
sushi.1023 > wrl.nfs: NFS request xid 79658
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1023: NFS reply xid 79658
reply ok 1472 read REG 100664 ids 417/0 sz 29388
(-v は、また、この例から省略された IP ヘッダの TTL、ID、長さとフラグメ
ンテーションフィールドを印刷 (表示) します。) 最初の行で、sushi は、バ
イトオフセット 24576 でファイル 21,11/12.195 から 8192 バイトを読み込む
ように wrl に要求します。wrl は、`ok' と応答します。2 番目の行で表示さ
れるパケットは、応答の最初のフラグメントで、そのため、1472 バイトの長さ
のみです (他のバイトは、その後のフラグメントに続きますが、これらのフラ
グメントは、NFS または UDP ヘッダさえないので、使用されたフィルタ表現に
依存して、印刷 (表示) されません)。-v フラグが与えられるので、(ファイル
データに加えて返される) ファイル属性のいくつかが、印刷 (表示) されます:
ファイルタイプ (通常のファイルに対しては、``REG'' )、(8 進数の) ファイ
ルモード、uid と gid とファイルサイズ。
-v フラグが複数回与えられるなら、さらなる詳細が、印刷 (表示) されます。
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 呼び出しは、536876964/1/1 の古いディレクトリファイル id
と `.newsrc.new' の古いファイル名を 536876964/1/1 の新しいディレクトリ
ファイル id、と `.newsrc' の新しいファイル名に名前を変更されました。ホ
スト pike は、(アボートパケットではなく、それがデータパケットであったの
で成功した) 名前変更 (rename) 呼び出しへの RPC 応答で応答します
一般的に、すべての AFS RPC は、少なくとも RPC 呼び出し名でデコードされ
ます。ほとんどの AFS RPC は、(一般的に、興味のあるいくつかの定義のため
の `興味のある' 引数のみ) すくなくともデコードされる引数のいくつかがあ
ります。
形式は、それ自体で説明することを意図していますが、それは、たぶん、AFS
と RX の動作に精通していない人々に役に立たないかもしれません。
-v (冗長) フラグが 2 度与えられるなら、確認応答パケットと追加のヘッダ情
報は、RX 呼び出し ID、呼び出し番号、シーケンス番号、シリアル番号と RX
パケットフラグなどが印刷 (表示) されます。
-v フラグが 2 度与えられるなら、RX 呼び出し ID、シリアル番号と RX パ
ケットフラグのような追加の情報が印刷 (表示) されます。MTU ネゴシエー
ション情報は、また、RX 肯定応答 (ack) パケットから印刷 (表示) されま
す。
-v フラグが 3 度与えられるなら、セキュリティインデックスとサービス id
が印刷 (表示) されます。
エラーコードは、(アボートパケットが Ubik プロトコルのために yes の投票
を意味するように使用されるので) Ubik ビーコンパケットを除いて、アボート
パケットに対して印刷 (表示) されます。
AFS 要求は、snaplen が増加しないなら、非常に大きく、引数の多くが印刷
(表示) されないことに注意してください。AFS トラフィックを見るために、
`-s 256' を使用することを試みてください。
AFS 応答パケットは、RPC 操作を明示的に識別しません。代わりに、tcpdump
は、``最近'' の要求の経過を追い、呼び出し番号とサービス ID を使用してそ
れらと応答を照合します。応答が、対応する要求に綿密に従わないなら、それ
は、解析可能でないかもしれません。
KIP AppleTalk (UDP の DDP)
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 が存在しないか、またはいくつかの AppleTalk ホスト/
ネット番号のためのエントリを含んでいないなら、アドレスは、数値形式で印
刷 (表示) されます。) 最初の例で、ネット 144.1 ノード 209 の NBP (DDP
ポート 2) は、ネット icsd ノード 112 のポート 220 でlisten (接続を受け
付け) しているものは何でも送信しています。2 番目の行は、発信元のノード
のフルネームが知られている (`office') ことを除いて同じです。3 番目の行
は、ネット jssmag ノード 149 のポート 235 から icsd-net NBP ポートでブ
ロードキャスト (同報通信) に送信します (ブロードキャストアドレス (255)
が、ホストの番号なしでネット名によって示されます - この理由のために、そ
れは、/etc/atalk.names でノード名とネット名を区別を保持するための良い考
えです)。
NBP (名前バインディングプロトコル) と ATP (AppleTalk トランザクションプ
ロトコル) パケットは、解釈されたそれらの内容があります。他のプロトコル
は、ちょうど、プロトコル名前 (または、名前がプロトコルのために登録され
ていないなら、数値) とパケットサイズをダンプします。
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
最初の行は、ネット jssmag でネット icsd ホスト 112 とブロードキャスト
(同報通信) によって送信されたレザーライタ (laserwriter) のための名前検
索要求です。検索のための nbp ID は、190 です。2 番目の行は、ポート 250
で登録された "RM1140" と名前が付けられたレーザライタ (laserwriter) のリ
ソースがあると記述しているホストの jssmag.209 から (それに同じ ID があ
ることに注意) この要求のための応答を表示します。3 番目の行は、ポート
186 で登録されるレーザライタ (laserwriter) "techpit" があるホスト
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 は、最大 8 個のパケット (`<0-7>') までの要求することによって
ホスト helios でトランザクション ID 12266 を開始します。行の終わりの 16
進数の数は、要求の `userdata' フィールドの値です。
helios は、8 つの 512 バイトパケットで応答します。トランザクション id
に続いている `:digit' は、トランザクションのパケットのシーケンス番号を
与えて、括弧内の数は、atp ヘッダを除いたパケットのデータ量です。パケッ
ト 7 の `*' は、EOM ビットが設定されたことを示しています。
次に、jssmag.209 は、パケット 3 & 5 が再転送されることを要求します。次
に、helios は、それらを再送し、jssmag.209 は、トランザクションを解放し
ます。最後に、jssmag.209 は、次の要求を開始します。要求の `*' は、XO
(`ちょうど 1 回') が設定されなかったことを示します。
関連項目
stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-
filter(7), pcap-tstamp(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 で利用可能です:
https://www.tcpdump.org/
オリジナルの配布は、次の匿名 ftp で利用可能です:
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z
IPv6/IPsec のサポートは、WIDE/KAME プロジェクトによって追加されました。
このプログラムは、特有の設定の下で、Eric Young の SSLeay ライブラリを使
用します。
バグ
セキュリティ問題を報告するためには、電子メールを security@tcpdump.org
に送信してください。
バグと他の問題、パッチを寄与し、機能を要求し、一般的なフィードバックな
どを報告するためには、tcpdump ソースツリーのルートのファイル
CONTRIBUTING を参照してください。
NIT は、利用者自身の外向きのトラフィックを観察できません。BPF は、観察
できます。利用者が、後者を使用するように推奨します。
2.0[.x] カーネルの Linux システムで:
ループバックデバイスのパケットは、2 回見られます。
すべてのパケットは、ユーザモードでフィルタリングされるためにカー
ネルからコピーされなければならないので、パケットフィルタリング
は、カーネルで行なうことはできません。
パケットのすべては、スナップショットの長さ内の部分だけではなく、
カーネルからコピーされます (2.0[.x] パケット捕獲メカニズムは、パ
ケットの一部だけをユーザランドにコピーするように問い合わせるな
ら、パケットの真の長さを報告しません。これによって、ほとんどの
IP パケットは、tcpdump からエラーを取得します)。
いくつかの PPP デバイスでの捕獲は、正しく動作しません。
利用者が 2.2 以降のカーネルにアップグレードすることを勧めます。
いくつかの試みは、IP フラグメントを再びアセンブルするために、または少な
くともより高いレベルのプロトコルのための正しい長さを計算するために行な
われるべきです。
ネームサーバの逆引きは、正しくダンプされません: (空の) 質問セクション
は、答えのセクションの実際の問い合わせではなく印刷 (表示) されます。い
くつかは、逆引きがそれら自体のバグであることを信じて、tcpdump ではな
く、それらを生成するプログラムを修正することを好みます。
夏時間時間の変更を交差しているパケットトレースは、歪曲されたタイムスタ
ンプを与えます (時間の変更は、無視されます)。
トークンリング (Token Ring) ヘッダのそれら以外のフィールドでのフィルタ
式は、発信元の経路制御されたトークンリング (Token Ring) パケットを正し
く処理しません。
802.11 のヘッダのそれらを以外のフィールドでのフィルタ式は、To DS と
From DS セットの両方で 802.11 のデータパケットを正しく処理しません。
ip6 proto は、ヘッダチェーンを追跡するべきですが、現時点では、そうしま
せん。ip6 protochain は、この振る舞いのために供給されています。
トランスポート層ヘッダに対する演算式は、tcp[0] のように、IPv6 パケット
に対して動作しません。それは、IPv4 パケットだけを見ます。
2 February 2017 TCPDUMP(1)