Provided by: manpages-ja_0.5.0.0.20161015+dfsg-1_all 
名前
tcpdump - ネットワークのトラフィックをダンプする
書式
tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]
[ -i interface ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ]
[ expression ]
説明
tcpdump は真偽値の 条件式 に一致するネットワークインターフェイス上のパケットのヘッダを表示
する。
nit か bpf を用いる SunOSの場合: tcpdump を動作させるためには /dev/nit か /dev/bpf* に読み
込み権限を持っている必要がある。 dlpi を利用する Solaris の場合: 仮想ネットワークデバイ
ス、たとえば /dev/le といったものに読み込み権限を持っている必要がある。 dlpi を利用する
HP-UX の場合: 実行者が root であるか、または root に setuid してインストールされている必要
がある。 snoop を用いる IRIX の場合: 実行者が root であるか、または root に setuid してイ
ンストールされている必要がある。 Linux の場合: 実行者が root であるか、または root に
setuid してインストールされている必要がある。 Ultrix および Digital UNIX の場合: ま
ず、スーパーユーザが pfconfig(8) を用いて無差別透過モード(promicuous-mode)を有効にする必要
がある。 その後は一般ユーザが tcpdump を実行可能である。 BSD の場合: /dev/bpf* に対する読
み込み権限が必要。
オプション
-a ネットワークとブロードキャストアドレスを DNS 名に変換する。
-c count 個のパケットを受信したのちに終了する。
-d コンパイルされたパケットマッチングコードを人間が読める形式で標準出力にダンプし、終
了する。
-dd パケットマッチングコードを C 言語の一部として利用可能なかたちでダンプする。
-ddd パケットマッチングコードを 十進数でダンプする(count が先行する)。
-e 各ダンプ行にリンクレベルヘッダを表示する。
-f 「外部の」インターネットアドレスをシンボルではなくて数値で表示する (このオプション
は馬鹿な Sun の yp サービスを迂回することを意図している — Sun の yp サービスはロー
カルではないインターネットアドレスを変換しようとすると 永久に動作が停止してしまうバ
グがある)。
-F フィルター条件式の指示入力として file を用いる。 この後ろにコマンドラインで条件式に
よる指示が与えられても無視する。
-i interface を監視する。 指示のない場合は tcpdump はシステムのインターフェイスのリス
トから 最も小さい番号で有効になっているもの(但しループバックは除く)を探し出す。 指
示されたインターフェイスが存在しない場合はもっとも近いものが選択される。
-l 標準出力をバッファリングする。データを蓄積しながら監視する場合に有効で ある。使用
例:
``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''.
-n アドレス(ホストアドレス、ポート番号など)を名前に変換しない。
-N ホストのドメイン名を表示しない。 つまりこれを使用した場合 tcpdump は``nic.ddn.mil''
と表示するかわりに ``nic'' と表示する。
-m SMI MIB モジュールをファイル module から読み込む。 複数の MIB モジュールを読み込む
目的で、 このオプションを複数回使用することも出来る。
-O パケットマッチングコードオプティマイザを停止する。 これはオプティマイザのバグを疑っ
ている場合にのみ有益である。
-p 無差別透過モードを 利用しない。しかしながら、他の理由でインター フェイスが無差別透
過モードになってしまうこともあることに注意すること。 このため `-p' オプションは
`ether host {loca-lw-addr} or ether broadcast' の省略形としては使用できない。
-q すばやい(というか静かな)出力。限定されたプロトコルの情報しか出力しないので、出力行
は短いものとなる。
-r パケットを(-w オプションで作成した)fileから読み込む。 fileとして ``-'' を指定した場
合には標準入力が利用される。
-s デフォルトの 68 バイト(SunOS の NIT では最小は実際には 96 バイト)に代わって snaplen
バイトをおのおののパケットから取り出し利用する。 IP, ICMP, TCP, UDP については 68
バイトあれば十分だが、ネームサーバや NFS の情報には足りないかもしれない(後述)。
snapshot 制限のために後ろが切り捨てられたパケットは出力時に``[|proto]'' の形式で示
される。 ここで proto は切り捨ての生じたレベルに対応するプロトコルの名前である。 大
きな snapshot を取ろうとするとパケットを処理する時間は増加し、またこちらのほうが重
要だが、バッファに溜めることができる量が減少してしまう点に注意すること。 すなわちパ
ケットが失なわれる可能性もある。プロトコルの情報が得られる必要最小限の snaplen とす
ること。
-T "expression"(条件式) で選択されたパケットに指示された type での翻訳を指示する。現在
有効な type は rpc (Remote Procedure Call)、 rtp (Real-Time Applications
protocol)、 rtcp (Real-Time Applications control protocol)、 snmp (Simple Network
Management Protocol), vat (Visual Audio Tool)、 wb (distributed White Board)。
-R ESP/AH パケットが古い定義(RFC1825 〜 RFC1829)に従っていると仮定する。 このオプショ
ンが指定されると、tcpdump は relplay prevention フィールドを表示しない。 ESP/AH の
定義にはプロトコルバージョンフィールドがないので、 tcpdump は ESP/AH プロトコルの
バージョンを推論することが出来ない。
-S TCP シーケンス番号を相対値ではなくて絶対値で表示する。
-t ダンプ行に時間情報を表示しない。
-tt ダンプ行に表示する時間情報を整形しない。
-v (ちょっとだけ)詳細な出力。IP パケットにおける 生存時間(TTL) やサービスの種類の情報
などを表示する。
-vv もっと詳細な出力。NFS応答パケットにおける付加フィールドなどを表示する。
-vvv さらに詳細な出力。 例えば、telnet SB ... SE オプションは全て表示される。 -X オプ
ションも指定されると、telnet オプションは 16 進表示でも表示される。
-w パケットを解析、表示するかわりに生のまま file に書き出す。 このファイルはあとで -r
オプションを用いれば表示することができる。 file として `-' を指示すると標準出力を用
いる。
-x (リンクレベルヘッダを除く)すべてのパケットを 16 進で表示する。パケット全体と
snaplen バイトの小さい方だけを表示する。
-X 16 進表示されるときに、 ASCII 文字も表示する。 従って、 -x オプションもセットされる
と、パケットは 16 進と ASCII 文字の両方で表示される。 これは新しいプロトコルを解析
するときに非常に便利である。 -x オプションが設定されていなくても、 パケットの部分に
よっては 16 進と ASCII 文字の両方で表示されることもある。
expression(条件式)
ダンプするパケットの種類を選択する。 expression が与えられないときは、ネットワーク
上のすべてのパケットをダンプする。 そうでなければ、expression が`true'(真) となるパ
ケットだけをダンプする。
expressionは一つ以上の primitive(要素) から成る。要素は一つ以上の修飾子を先行する一
個の id (名前でも番号でもよい)である。修飾子には三つの種類がある:
type 修飾子は id名または id 番号が指すものの種類を示す。利用可能なものは host,
net, port である。例: `host foo'、`net 128.3'、`port 20'。 type 修飾子が無い
場合は、 host が指示されているものとみなす。
dir 修飾子は id に向けて、または id へ、のどちらかあるいは両方の通信方向を特定す
る。方向として指示できるのは src, dst, src or dst, src and dst である。例、
`src foo'、`dst net 128.3'、`src or dst port ftp-data'。 dir 修飾子が指定さ
れない場合は src or dst が指示されているものとみなす。`null' リンク層(すなわ
ち slip のよう なポイントツーポイントプロトコル)においては、方向を指定する修
飾子として inbound と outbound も利用可能である。
proto 修飾子は一致する特定のプロトコルに制限する。利用可能なプロトコルは以下の通
り: ether, fddi, mopdl, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl,
icmp, icmp6, tcp, udp。 例: `ether src foor'、`arp net 128.3'、`tcp port
21'。 proto 修飾子が指示されない場合は type と矛盾しない範囲で全てのプロトコ
ルが指示されているものとみなす。 例: `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 ヘッダに
はその他のフィールド も含まれるが、これについてはフィルタの条件式で明示的に指示する
ことはで きない。]
上記に加えて、特別な`要素'を示すキーワードがある。 gateway, broadcast, less,
greater とarithmtic expression(数値による条件式)である。これらについてはこのあとで
記述する。
もっと複雑なフィルタ条件式は 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 prot ftp
or tcp dst port ftp-data or tcp dst prot domain'と全く同じ意味である。
許容される要素の組み合わせは以下の通り。
dst host host
パケットの IPv4/v6 ディスティネーションフィールドが host であるとき真。アド
レスでも名前でもよい
src host host
パケットの IPv4/v6 ソースフィールドが host であるとき真。
host host
パケットの IPv4/v6 ソースまたは IP/v4/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 は名前であり、また
/etc/hosts と /etc/ethers の両方に記載されていなければならない (この条件式は
host / ehost それぞれを名前か番号で記述する
ether host ehost and not host host
と同等である)。 この文法は今のところ IPv6 を有効にした設定では正しく動作しな
い。
dst net net
パケットの IPv4/v6 ディスティネーションアドレスが net ネットワークを 含んで
いるときに真。net は/etc/networks に記載される名前かネット ワーク番号である(
networks(4) を参照)。
src net net
パケットの IPv4/v6 ソースアドレスが net ネットワークのものであるときに真。
net net
パケットの IPv4/v6 ソース/ディスティネーションアドレスが net ネットワークで
あるときに真。
net net mask mask
IP アドレスが netmask でマスクして net に一致するときに真。src か dst で修飾
してもよい。 この文法は net が IPv6 のときには不正であることに注意。
net net/len
IPv4/v6 アドレスが len ビットのnetmask でマスクして net に一致するときに
真。src か dst で修飾してもよい。
dst port port
パケットが ip/tcp か ip/udp か ipv6/tcp か ipv6/udp である場合で、 行き先の
port 番号が port であるときに真。 Port は番号の数値か /etc/services による名
前を利用できる( tcp(4P) と udp(4P) を参照のこと)。名前が利用されている場合は
port 番号と protocol の両方で照合される。 番号か多重に定義されている名前が利
用されている場合は port 番号だけが照合される (例: dst port 513 は tcp/login
と udp/who の両方の通信を表示するし、 port domain は tcp/domain と
udp/domain の両方を表示する)。
src port port
パケットが port 番号のポートをソースにしているとき真。
port port
パケットのソースかディスティネーションポートが port であるとき真。 この port
を指定する条件式は tcp と udp のキーワードを付加してもよい:
tcp src port port
は port をソースとする tcp のパケットのみに一致する。
less length
パケットが length 以下のときに真。 これは下記と同じ:
len <= length.
greater length
パケットが length 以上のときに真。 これは下記と同じ:
len >= length.
ip proto protocol
パケットが protocol 型のプロトコルの IP パケット( ip(4P) を参照)のものである
とき真。 protocol として利用できるのは数値と icmp、 igrp、udp、nd、tcp であ
る。tcp、udp、 icmp はキーワードでもあるので、バックスラッシュ(\)でキーワー
ド として解釈されるのを回避する必要がある。C-Shell では \\ を使う。 この要素
はプロトコルヘッダチェインを追跡しないことに注意。
ip6 proto protocol
パケットがprotocol型の IPv6 パケットであるときに真。 この要素はプロトコル
ヘッダチェインを追跡しないことに注意。
ip6 protochain protocol
パケットが IPv6 パケットであり、 そのプロトコルヘッダチェインの中
にprotocol型のプロトコルヘッダがある場合に真。 例えば、
は プロトコルヘッダチェインに TCP プロトコルを持つ IPv6 パケットに一致する。
パケットには、例えば認証ヘッダ、ルーティングヘッダ、 hop-by-hopヘッダなど
がIPv6 ヘッダと TCP ヘッダの間に含まれるかもしれない。 この要素が作り出す
BPF コードは複雑で、 tcpdumpの BPF 最適化コードで最適化できない。 そのた
め、少し遅いかもしれない。
ip protochain protocol
ip6 protochain protocol と同様だが、これは IPv4 のためのものである。
ether broadcast
パケットがイーサネットのブロードキャストであるとき真。ether はなくてもよい。
ip broadcast
パケットが IP ブロードキャストパケットであるとき真。これは全て 0 と 全て 1
の両方のブロードキャスト形式に対応し、さらにサブネットマスクにも対応してい
る。
ether multicast
パケットがイーサネットのマルチキャストであるとき真。ether はなくて もよ
い。これは `ether[0] & 1 != 0'の省略記法である。
ip multicast
パケットが IP のマルチキャストであるとき真。
ip6 multicast
パケットが IPv6 マルチキャストパケットであるとき真。
ether proto protocol
パケットが ether の protocol 型のものであるとき真。 protocol には番号か
ip、ip6、arp、rarp の名前が利 用可能。これらの識別子はキーワードでもあるの
で、バックスラッシュ(\)で キーワードとして解釈されるのを回避する必要がある。
[ FDDI (たとえば `fddi protocol arp')の場合、プロトコルの識別方法は 802.2
Logical Link Control (LLC) ヘッダーによる。それは通常は FDDI ヘッダーの先頭
に置かれている。tcpdump は プロトコル識別子で フィルターする場合に、全ての
FDDI パケットは LLC ヘッダーを持っていて、 その LLC ヘッダーは SNAP と呼ばれ
る形式になっているものとみなす。 ]
decnet src host
DECNET においてソースアドレスが``10.123''のようなアドレスや DECNETのホ スト
ネームの形式で指示される host と一致するとき真。[DECNETのホストネーム形式は
DECNETに接続された ultrix システムにおいてのみ利用可能である。]
decnet dst host
DECNETにおいてディスティネーションアドレスが host に一致するとき真。
decnet host host
DECNETにおいて、ソースまたはディスティネーションアドレスが host に一致すると
きに真。
ip, ip6, arp, rarp, decnet
下記において:
ether proto p
p をそのいずれかのプロトコルとするのと同等である。
lat, moprc, mopdl
下記において:
ether proto p
p をそのいずれかのプロトコルとするのと同等である。 tcpdump はこれらのプロト
コルの解析方法は正確には知らない点に注意 すること。
tcp, udp, icmp
下記において:
ip proto pip6 proto p
p をそのいずれかのプロトコルとするのと同等である。
expr relop expr
関係式が成り立てば真。relop(演算子)は >、<、>=、<=、=、!= のいず れか一つで
あり、expr(表現) は整定数による数値表現 (表現方法は標準 的な C の文法にした
がう)、標準的な二項演算子[+、-、*、/、&、|]、長さ演算子、パ ケットデータアク
セス演算子のいずれか。パケット内のデータに対して適用するにはこのように記述す
る:
proto [ expr : size ]
proto は ether、fddi、ip、arp、rarp、tcp、udp、icmp、ip6 のいずれかで 操作対
象のプロトコル層を指示する。 tcp, udp とその他の上位プロトコル層は IPv4 での
み利用でき、 IPv6では利用できないことに注意。(これは将来修正されるだろう) 指
示されたプロトコル層についてのバイトオフセットは expr で指定する。 size を指
示する場合は注目するフィールドでのバイト数で指示するが、 それは one、two ま
た four のいずれかを用いる。指示のない場合は one で あるとみなす。長さ演算子
はキーワード len で示され、パケット長を与える。 たとえば、`ether[0] & 1 !=
0'という条件式はすべてのマルチキャスト による通信をとらえる。`ip[0] & 0xf !=
5' という条件式はすべてのオ プション付きの IP パケットをとらえる。`ip[6:2] &
0x1fff = 0'はフラ グメント化されていないデータグラムか 0 番の(最初の)フラグ
メントだけを表示する。 なお、この条件は tcp と udp への適用を暗示してい
る。さら に tcp[0] は TCP ヘッダ の最初のバイトを意味するが、フラ グメントの
先頭のバイトではありえない。
要素を複合させて用いる場合:
括弧でグループ分けする要素と演算子(括弧はシェルにとっても特別な意味を持つの
でたぶんエスケープしなければならないだろう)。
否定 (`!' or `not').
結合 (`&&' or `and').
択一 (`||' or `or').
否定はもっとも高い優先度をもつ。択一と結合は同等の優先度を持ち、 左から右へ評価され
る。 結合は併記するだけでなく明示的な and トークンが必要なことに注意すること。
キーワードなしで識別子があらわれた場合、直前にあらわれたキーワードを 伴っているとみ
なされる。 たとえば、
not host vs and ace
は
not host vs and host ace
の省略であり、これは
not ( host vs or ace )
とは違う。
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 通信の TCP スタートとエンドのパケット(SYN と FIN のパケッ
ト)を表示する:
tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'
ゲートウェイ snup を通過する 576 バイト以上の IP パケットを表示する:
tcpdump 'gateway snup and ip[2:2] > 576'
イーサネットのブロードキャストまたはマルチキャストを 必要としない IP のブロードキャストま
たはマルチキャストを表示する:
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
echo 要求/応答(つまり ping のパケット)以外のすべての ICMP パケットを表示する:
tcpdump 'icmp[0] != 8 and icmp[0] != 0"
出力形式
tcpdump の出力はプロトコルに依存する。下記は大部分の様式の簡単な解説と例である。
リンクレベルヘッダ
`-e' オプションが指示されている場合、リンクレベルヘッダが表示される。 イーサネットではソー
スおよびディスティネーションのアドレスとパケット長が表示される。
FDDI のネットワークにおいては '-e' オプションにより tcpdump は、ソ ースおよびディスティ
ネーションのアドレスとパケット長からなるフレーム制御フィールドを表示する。(フレーム制御
フィールドはパケットの残りの部分の解釈 の制御をおこなう)。(IP データグラムを含むような)通
常のパケットは優先度 0 から 7 を持つ`async' パケットである;たとえば `async 4'。この ような
パケットは 802.2 LLC を含むとみなされる。LLCヘッダはそれが ISO データグラムやいわゆる SNAP
パケット でない ならば、表示される。
(注:以下の記述は RFC-1144 による SLIP 圧縮アルゴリズムを理解しているものと みなして記述し
てある)。
SLIP 接続では、方向指示(``I''が入力、``O''が出力)、パケットタイプと圧縮情報が表示される。
最初にパケットタイプが表示される。 タイプには ip、utcp、ctcp の三種類がある。 ip パケット
についてこれ以上のリンク情報は表示されない。 TCPパケットは接続識別子が次に表示される。 パ
ケットが圧縮されている場合はその符号化されたヘッダが表示される。 *S+n、*SA+n と表示される
特別な状態もある。ここで n はシーケンス番号(またはシーケンス番号と ack)が何回変更されたか
を示す。 特別な場合でなければ、ゼロかまたは変更の回数が出力される。 変更は U(urgent
pointer)、W(windows)、A(ack)、S(sequence number)、I(packet 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 で実行すると最初のパケットがブロードキャストで二番目は point-to-point であるこ
とが見てとれる:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
最初のパケットは source のイーサネットアドレスが RTSG で、 ディスティネーションがイーサ
ネットのブロードキャストであり、 タイプフィールドは 16 進の 0806(ETHER_ARP)、全長が 64 バ
イトであることがわかる。
TCP パケット
(注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものと みなして記述してあ
る。もしこのプロトコルに通じていないようなら、この記 述だけでなく、tcpdump そのものも役に
立たないだろうが。)
一般的なフォーマットは下記の通り:
src > dst: flags data-seqno ack window urgent options
src と dst は ソースとディスティネーションとなる IPアドレスとポート番号である。 flags は
S(SYN)、F(FIN)、P(PUSH)か R(RST) の組合せか一つの `.'(フラグなし)である。 data-seqno はこ
のパケットに含まれるデータのシーケンス空間の一部を示す(下記の例を参照)。 ack はこの接続に
おける次の期待される応答データのシーケンス番号。 window はこの接続における応答に対して用意
されているバッファ空間のバイト数。 urg はこのパケットに `urgent' データが含まれることを示
す。 options は tcp のオプションで <>で囲まれる(例<mss 1024>)。
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 でこの
パケットはデータを 含まない。(このように nbytes バイトのユーザデータを含むシーケ ンス番号
first から、last (last は含まれない)を示すために `first:last(nbytes)'と表記する)。またこの
パケットには ack は設定されて おらず、受信 window は 4096 バイト、最大セグメントサイ
ズ(mss)オプショ ン が 1024 バイトに設定されていた。
これに対して、csam は rtsg の SYN に対する ack を含む他は同等の内容のパケットを返してい
る。 そこで、rtsg は csam の SYN に ack 応答を返す。`.' はフラグがセットされていないことを
示す。 このパケットにはデータが含まれないので、シーケンス番号もない。ack 応答のシーケンス
番号は小さな整数 1 である点に注意すること。 最初に tcp の「会話」を見いだすと、tcpdump は
そのパケットのシー ケンス番号を出力する。その会話のパケットからは、そのシーケンス番号と 初
期化されたシーケンス番号との差異が表示される。 これは最初以外のシーケンス番号はその会話の
データグラムにおける相対的な バイト位置として解釈できることを意味する (各データグラムは 1
から始ま る)。 '-S' オプションはこの機能を無視して、本来のシーケンス番号を出力する。
6 行目で rtsg は scam へ 19 バイト(rtsg から csam の方向へ、2 バイト目 から 20 バイト目ま
で) のデータを送る。このパケットには PUSH フラグが設定されている。7 行目で、 csam は rtsg
が送信したデータを受信した、と言っているが、これには 21 バイト目は含まれない。csam の受信
window が 19 バイト小さくなっていることか ら、このデータはソケットバッファに留まっていると
推測される。csam はま た 1バイトのデータを rtsg に送信する。8 行目と 9 行目とで csam は
urgent および pushed 付きのパケット 2バイト をrtsg へ送信している。
もし、snapshot が小さすぎて tcpdump が TCP ヘッダの全てを捉えられなかった場合は、できるだ
け の解釈をして、その残りには解釈不能だったものがあることを示すために ``[|tcp]''と表示す
る。ヘッダに意味不明なオプション(たとえば、小 さすぎたり、ヘッダよりも長かったりする
length とか)が設定されていた場 合は、tcpdump は ``[bad opt]''と表示し、それ以上のオプショ
ン解析 を中止する(それがどこから始められるかわからないので)。 ヘッダ長がオプションを送信し
たことを示しているのに、 IP データグラム長はそこにオプションを含められないことを示す場合は
tcpdump は ``[bad hdr length]''と表示する。
UDP パケット
UDP はこの rwho のパケットで説明する:
actinide.who > broadcast.who: udp 84
これはホスト actinide の who のポートから UDP データグラムが ホスト broadcast すなわちイン
ターネットブロードキャストアドレスの who のポートへ送られたことを表示している。 パケットは
ユーザデータ 84 バイトを含んでいる。
いくつのかの UDP サービスに関しては(そのソースまたはディスネーション のポート番号より)解釈
することができ、より上位の層におけるプロトコル 情報を表示する。特にドメインネームサービス
要求(RFC-1034/1035)や NFS についての Sun RPC (RFC-1050)について出力される。
UDP ネームサービス要求
(注:以下は RFC-1035 で記述される ドメインネームサービスプロトコルを 理解しているものとみな
して記述している。 もしこのプロトコルに通じていないようなら、以下の記述はちんぷんかんぷん
かもしれない。)
ネームサーバの要求は、
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
のような形式である。
ホスト h2opolo は helios のドメインネームサーバに対して、 ucb-bax.berkeley.edu. という名前
についてのアドレスレコード(qtype=A)を尋ねる。 問い合わせの id は `3'。`+'は再帰可
能(recursion desired)フラグが設定されていることを示す。 問い合わせは UDP と IP のヘッダは
含まめずに 37バイトある。 問合せは標準的な Query なので op フィールドは省略されている。 も
し、op フィールドを持つなら、それがなんであれ、`3' と `+' の間に表示する。 また同様に、問
合せクラス(qclass)も標準的な C_IN なので、省略されている。 ほかの問合せクラスの場合は `A'
に続いて表示する。
例外的なものを検出した場合、追加のフィールドを[ ] で囲んで表示するだろ う:もし問合
せ(query)に回答、ネームサーバ、権威セクションが含まれる場合、 ancount, nscount, arcount は
それぞれn をカウント数として、 `[na]'、`[nn]' か `[nau]' のように表示される。 もし、第二お
よび第三バイトにいくつかの応答bitが設定されている(AA、RA か または rcode)場合か、`must be
zero' ビットが設定されている場合は `[b2&3=x]'と表示する。ここで x はヘッダの第二および第三
バイトの 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 は h2opolo の id 3 の要求に三個の回答 レコード、三個のネームサーバレ
コードと七個の権威レコードを返答している。 最初の回答は A レコードで、このデータはインター
ネットアドレスの 128.32.137.3 である。 応答のサイズは UDP と IP のヘッダは含まずに 273 バ
イトである。 (queryの) op と response code(この場合は NoError)は、A レコードのクラ
ス(C_IN)と同様に省略されている。
次の例は helios はドメインが存在しない、という response code (NXDomain) で回答はなし、ネー
ムサーバは一個、権威レコードもなし、という返答をしている。 `*' は authoritative answer
ビットが設定されていることを示す。 回答がないので、 type とクラスおよびデータは表示されな
い。
ほかのフラグは`-'(RA(再帰可)が設定されていない)、`|'TC(まるめら れたメッセージ)が設定され
ている。`question' セクションが一つでない場合 には、`[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 パケットの形式や all teフィールドが何を意味するかの情報は、 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 に送信している (src ホストに
続く数字は port 番号 ではなくて トランザクション id である点に注意せよ)。 要求は UDP と IP
のヘッダを除いて 112 バイトである。動作要求はファイルハンドル(fh) 21,24/10.731657119 に対
する readlink (シンボリックリンクの値を読む)である。 (この例では、幸運なことに、デバイスの
major および minor 番号の対と inode 番号、generation 番号がファイルハンドルから抽出できて
いる) Wrl はリンクの内容と `ok' を返答している。
三行目では sushi は wrl に対し ディレクトリファイル 9,74/4096.8678 から `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 に対して、 file 21,11/12.195 のバイトオフセット 24576
から 8192 バイト読み出し要求を出 している。Wrl は `ok' を返している; 二行目に表示されてい
るこのパ ケットはフラグメント化された返答の一番目のパケットであるため、1472 バ イトのみで
ある(残りのバイトはその後のフラグメントとして続くが、それら のフラグメントは NFS ヘッダも
UDP ヘッダも持たないので、フィルタ条件式の指定次第で表示されないことがある)。 また -v フラ
グがあたえられていることにより、いくつかのファイルの属性 も表示される(ファイルデータに付加
して返答される): ファイルのタイプ (``REG'' は普通のファイル)、ファイルのモード(八進
で)、uid と gid、またファイルのサイズなど。
-v フラグが複数与えられると(-vvのこと)もっと詳細な情報が出力される。
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 呼び出し名はデコードされる。 ほとんどの AFC RPC は
少なくともいくつかの引数はデコードされる (一般に `興味深い' 引数のみがデコードされる)。
表示フォーマットは自己説明的なものを目指しているが、 AFS と RX の動作に詳しくない人々に
とってはおそらく便利ではないだろう。
-v (詳細) オプションが 2 回指定されると、追加情報が表示される。 これは RX 呼び出し ID、呼
び出し番号、シーケンス番号、シリアル番号、RX パケットフラグなどである。
さらに -v オプションが指定されると、セキュリティインデックスとサービス ID が表示される。
中断パケットのエラーコードも表示される。 但し、Ubik ビーコンパケットは例外である。 (なぜな
ら、Ubik プロトコルにおける中断パケットは賛成票を意味するからである)。
AFS 要求は非常に大きく、 多くの引数はsnaplenを増やさないとおそらく表示されないことに注意す
ること。 AFS 通信を監視する場合は `-s 256' を試してみるとよい。
AFS 応答パケットは明示的に RPC 操作を識別しない。 代わりに、tcpdumpは``最近の''要求を覚え
ていて、 それを呼び出し番号とサービス ID を用いて応答と照合させる。 もし応答が対応する要求
と結び付けられなかった場合、そのパケットはパーズできない。
KIP Appletalk (UDP 内 DDP)
UDP データグラム内に格納されたアップルトークの DDP パケットは取り出されて、 DDP パケットと
して表示される(すなわちすべての UDP ヘッダ情報は捨てられる)。 /etc/atalk.names ファイルが
アップルトークネットとノード番号を名前に変換するのに利用される。 ファイルの形式は下記の通
り。
番号 名前
1.254 ether
16.1 icsd-net
1.254.110 ace
最初の二行はアップルトークネットワークに名前を与える。三行目は特定のホストの名前を与え
る(ホストはネットワーク番号の第三オクテットで識別される - ネットワーク番号は二オクテットで
なければならず、またホスト番 号は三オクテットで なければならない。番号と名前は空白文字で区
切られる(blank か tab)。 /etc/atalk.names ファイルは空行とコメント行(`#'で始まる行)を含ん
でもよい。
アップルトークのアドレスは次の形式で表示される。
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 のポート番号 2 )からネットワーク icsd のノード 112 ポート番号220 番への送信を示
す。 二番目も同様だが、ノード名(`office') がわかっている場合の例。 三行目はネットワーク
jssmag のノード 149 の 235 番ポートから icsd-net の NBPポートへのブロードキャストを示す。
ブロードキャストアドレス(255)はホスト番号を伴わないネットワーク名だけの出 力で識別できるこ
とに注意すること - /etc/atalk.names にノード名とネッ トワーク名を記述しておくのはよい考え
である)。
NBP(名前解決プロトコル)と ATP(アップルトークトランザクションプロトコル)パケットについて
は、その内容も解析される。 その他のプロトコルはプロトコル名(名前がわからなければ番号)とパ
ケットのサイズが表示されるだけである。
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 番号が同じであることに注意)で、``RM1140''という名前のレーザライタ
を 250 番ポートに持っていることを答えている。 三行目は同じ要求に対する別の返答でホスト
techpit が186番ポートに "tecpit" が登録されていることを答えている。
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
jssmga.209 はホスト helios に対して id 12266 でトランザクションを開始し最大 8パケッ
ト(`<0-7>'と示す)を要求する。 行末の 16 進数字は要求に含まれる `userdata'のフィールドであ
る。
helios は八個の 512 バイトのパケットを返答している。トランザクションid に続く `:数字' 表現
はトランザクションにおけるパケットのシーケンス番号で、カッコに囲まれた数字は atp ヘッダを
除いたパケットのデータ量である。パケット 7 番の `*' は EOM ビットが設定されていることを示
す。
jssmag.209 はパケット 3 番とパケット 5 番の再送を要求している。helios はそれらを再送
し、jssmag はトランザクションを終了する。そして、 jssmag.209 は次の要求を開始する。要求の
`*' は XO (`一回だけ')は設定 されていない ことを示す。
IP フラグメント化(fragmentation)
インターネットデータグラムのフラグメント化されたものは次のように表示する。
(frag id:size@offset+)
(frag id:size@offset)
(最初の形式はまだ続くフラグメントがあることを示し、二番目の形式はそ れが最後のフラグメント
であることを示す)
id はフラグメントの id 。size はフラグメントの IP ヘッダを除くサイズ(バイトで)。offset は
フラグメントのもともとのデータグラム内でのオフセット(バイトで)。
フラグメントの情報はフラグメント毎に表示される。最初のフラグメントには 上位プロトコルの
ヘッダを含み、フラグメント情報はプロトコル情報に続いて 表示される。二番目以降のフラグメン
トには上位プロトコルの情報を含まない ので、フラグメント情報はソースおよびディスティネー
ションアドレスに続いて表示される。 以下の例は CSNET で接続された arizona.edu から lbl-
rtsg.arpa への 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
二つの注意点がある: 一つ目として、二行目で示されるアドレスにはポート 番号は含まれていない
点に注意すること。 TCP プロトコルの情報は最初のフラグメントに含まれるため、 残りのフラグメ
ントからは表示すべきポート番号やシーケンス番号がわからないためである。 二つ目は、一行目の
TCP のシーケンス情報 には実際には 512 バイト(最初のフラグメントで 308 バイト、二番目のフラ
グメントで204 バイトの場合)のユーザデータが 308 バイトであるかのように 表示されている点で
ある。シーケンスの漏れやパケットの ack の対応を調査 するとき、ここに悩まされることがあるか
もしれない。
フラグメント化禁止フラグ の設定されたパケットの場合、行末に (DF)と表示する。
時間表示
デフォルトでは全ての出力行の先頭にタイムスタンプがつく。タイムスタンプは現在の時刻を次の形
式で表示し、
hh:mm:ss.frac
これは、kernel の時間情報同様に正確である。タイムスタンプは kernel が パケットを確認した時
点の時刻を反映している。イーサネットインターフェイス が回線からパケットを取得した時点から
カーネルが `新しいパケット' による 割り込みを受ける時点までの時間差は反映されていない。
関連項目
traffic(1C), nit(4P), bpf(4), pcap(3)
著者
原著者は:
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National
Laboratory, University of California, Berkeley, CA.
最新版は tcpdump.org によって管理されている。
http://www.tcpdump.org/
IPv6/IPsec のサポートは WIDE/KAME プロジェクトによって追加された。 このプログラムは Eric
Young の SSLeay ライブラリを特定の設定の元に使用している。
バグ
問題点、バグ、質問、拡張のお願いなどは、以下のアドレスに送ってほしい。
tcpdump-workers@tcpdump.org
ソースコードの寄贈などは以下のアドレスへ送ってほしい。
patches@tcpdump.org
NIT は外へ出ていく通信は見ることができない。BPF はそれが可能である。後者の利用を推奨する。
用途によっては、IPフラグメントを再構築したり、上位プロトコルの長さを計算するくらいのことは
必要となるだろう。
ネームサーバの逆引き要求は正確に表示できない。(空の)質問はむしろ回答の 中に含まれる要求と
して表示される。逆引き要求にはバグがふくまれていて、 それを修正するのは tcpdump ではなくて
ネームサービスの方であるべきと考 えている人もいる。
アップルの EtherTalk の DDP パケットは KIP DDP パケットのように容易に dump できるはずだ
が、行なわない。たとえ ethertalk を扱おうという気になっ ても(なってないが)、LBLが ネット
ワーク上のethertalk へのアクセスを許さ ないので、コードのテストができないのだ。
夏時間に切り替わるときにパケットトレースを行なっていると時間がずれてし まう(時間の変更は無
視される)。
FDDI ヘッダに対するフィルタの条件式はすべての FDDI パケットがイーサネット のパケットをカプ
セル化しているものとみなして適用される。 これは、IP,ARP と DECNET PhaseIV については正しく
動作するが、 ISO CLNS のようなプロトコルではうまくいかないだろう。 それゆえにフィルターは
条件式に一致しないようなパケットをあやまって あつかってしまうかもしれない。
ip6 proto はヘッダチェインを追跡するべきだが、今のところそうはなっていない。 tcp や udp も
ヘッダチェインを追跡するべきである。
tcp[0]のようなトランスポート層ヘッダに対する算術表現は、 IPv6 パケットに対してはうまく働か
ない。 IPv4 パケットに対してのみ働く。
30 June 1997 TCPDUMP(8)