kazmax - Linux で自宅サーバー

tcpdump - コマンド (プログラム) の説明 - Linux コマンド集 一覧表

  1. 名前
  2. 書式
  3. 説明
  4. オプション
  5. 例
  6. 出力形式
  7. 関連項目
  8. 著者
  9. バグ

名前

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 サービスを迂回することを意図している \(em Sun の yp サービスはローカルではないインターネットアドレスを変換しようとすると 永久に動作が停止してしまうバグがある)。
-F
フィルター条件式の指示入力として file を用いる。 この後ろにコマンドラインで条件式による指示が与えられても無視する。
-i
interface を監視する。 指示のない場合は tcpdump はシステムのインターフェイスのリストから 最も小さい番号で有効になっているもの(但しループバックは除く)を探し出す。 指示されたインターフェイスが存在しない場合はもっとも近いものが選択される。
-l
標準出力をバッファリングする。データを蓄積しながら監視する場合に有効で ある。使用例:
``tcpdump-l|tee dat'' or ``tcpdump-l > dat&tail-fdat''.
-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 が`true'(真) となるパケットだけをダンプする。

expression は一つ以上の primitive (要素)から成る。要素は一つ以上の修飾子を先行する一個の id (名前でも番号でもよい)である。修飾子には三つの種類がある:
修飾子は id名または id 番号が指すものの種類を示す。利用可能なものは host , net , port である。例: `host foo'、`net 128.3'、`port 20'。 type 修飾子が無い場合は、 host が指示されているものとみなす。
修飾子は 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 も利用可能である。
修飾子は一致する特定のプロトコルに制限する。利用可能なプロトコルは以下の通り: 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'と全く同じ意味である。

許容される要素の組み合わせは以下の通り。
パケットの IPv4/v6 ディスティネーションフィールドが host であるとき真。アドレスでも名前でもよい
パケットの IPv4/v6 ソースフィールドが host であるとき真。
パケットの IPv4/v6 ソースまたは IP/v4/v6 ディスティネーションフィールドが host であるとき真。 上記の各 host を示す条件式には ip 、arp 、rarp 、ip6 のいずれかを付加してもよい。 

ip host host

は下記と同じ。 
ether proto \ip and host host

もし host の名前が複数の IP アドレスを持つ時はそれぞれのアドレスに一致する。
イーサネットディスティネーションアドレスが ehost であるときに真。 ehost は /etc/ethers か数値である(数値のフォーマットについては ethers (3N)を参照のこと)。
イーサネットソースアドレスが ehost であるときに真。
イーサネットソースアドレスかディスティネーションアドレスが ehost であるときに真。
パケットが host をゲートウェイとしているときに真。 すなわち、イーサネットソース/ディスティネーションアドレスは host であるが、 IP ソース/ディスティネーションアドレスは host ではないときのこと。 host は名前であり、また /etc/hosts と /etc/ethers の両方に記載されていなければならない (この条件式は host / ehost それぞれを名前か番号で記述する 
ether host ehost and not host host

と同等である)。 この文法は今のところ IPv6 を有効にした設定では正しく動作しない。
パケットの IPv4/v6 ディスティネーションアドレスが net ネットワークを 含んでいるときに真。net は/etc/networks に記載される名前かネット ワーク番号である( networks(4) を参照)。
パケットの IPv4/v6 ソースアドレスが net ネットワークのものであるときに真。
パケットの IPv4/v6 ソース/ディスティネーションアドレスが net ネットワークであるときに真。
IP アドレスが netmask でマスクして net に一致するときに真。src か dst で修飾してもよい。 この文法は net が IPv6 のときには不正であることに注意。
IPv4/v6 アドレスが len ビットのnetmask でマスクして net に一致するときに真。src か dst で修飾してもよい。
パケットが 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 の両方を表示する)。
パケットが port 番号のポートをソースにしているとき真。
パケットのソースかディスティネーションポートが port であるとき真。 この port を指定する条件式は tcp と udp のキーワードを付加してもよい: 
tcp src port port

は port をソースとする tcp のパケットのみに一致する。
パケットが length 以下のときに真。 これは下記と同じ: 
len <= length.


パケットが length 以上のときに真。 これは下記と同じ: 
len >= length.


パケットが protocol 型のプロトコルの IP パケット( ip (4P)を参照)のものであるとき真。 protocol として利用できるのは数値と icmp 、 igrp 、udp 、nd 、tcp である。tcp 、udp 、 icmp はキーワードでもあるので、バックスラッシュ(\)でキーワード として解釈されるのを回避する必要がある。C-Shell では \\ を使う。 この要素はプロトコルヘッダチェインを追跡しないことに注意。
パケットがprotocol 型の IPv6 パケットであるときに真。 この要素はプロトコルヘッダチェインを追跡しないことに注意。
パケットが IPv6 パケットであり、 そのプロトコルヘッダチェインの中にprotocol 型のプロトコルヘッダがある場合に真。 例えば、 


は プロトコルヘッダチェインに TCP プロトコルを持つ IPv6 パケットに一致する。
パケットには、例えば認証ヘッダ、ルーティングヘッダ、
hop-by-hopヘッダなどがIPv6 ヘッダと TCP ヘッダの間に含まれるかもしれない。
この要素が作り出す BPF コードは複雑で、
tcpdump
の BPF 最適化コードで最適化できない。
そのため、少し遅いかもしれない。

ip6 protochain 
protocol
 と同様だが、これは IPv4 のためのものである。

パケットがイーサネットのブロードキャストであるとき真。ether
 はなくてもよい。

パケットが IP ブロードキャストパケットであるとき真。これは全て 0 と 全て 1 の両方のブロードキャスト形式に対応し、さらにサブネットマスクにも対応している。

パケットがイーサネットのマルチキャストであるとき真。ether
 はなくて
もよい。これは `ether[0] & 1 != 0
'の省略記法である。

パケットが IP のマルチキャストであるとき真。

パケットが IPv6 マルチキャストパケットであるとき真。

パケットが ether の protocol
 型のものであるとき真。
protocol
 には番号か ip
、ip6
、arp
、rarp
 の名前が利
用可能。これらの識別子はキーワードでもあるので、バックスラッシュ(\)で
キーワードとして解釈されるのを回避する必要がある。
[ FDDI (たとえば `fddi protocol arp
')の場合、プロトコルの識別方法は
802.2 Logical Link Control (LLC) ヘッダーによる。それは通常は
FDDI ヘッダーの先頭に置かれている。tcpdump
 は プロトコル識別子で
フィルターする場合に、全ての FDDI パケットは LLC ヘッダーを持っていて、
その LLC ヘッダーは SNAP と呼ばれる形式になっているものとみなす。 ]

DECNET においてソースアドレスが``10.123''のようなアドレスや DECNETのホ
ストネームの形式で指示される

host
と一致するとき真。[DECNETのホストネーム形式は DECNETに接続された
ultrix システムにおいてのみ利用可能である。]

DECNETにおいてディスティネーションアドレスが

host
に一致するとき真。

DECNETにおいて、ソースまたはディスティネーションアドレスが

host
に一致するときに真。

下記において:

ether proto p



p
 をそのいずれかのプロトコルとするのと同等である。

下記において:

ether proto p



p
 をそのいずれかのプロトコルとするのと同等である。
tcpdump
 はこれらのプロトコルの解析方法は正確には知らない点に注意
すること。

下記において:

ip proto pip6 proto p



p
 をそのいずれかのプロトコルとするのと同等である。

関係式が成り立てば真。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 の開始時の一部。



-2rtsg.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+2






一行目は 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
 をカウント数として、
`[n
a]'、`[n
n]' か `[n
au]' のように表示される。
もし、第二および第三バイトにいくつかの応答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' セクションが一つでない場合
には、`[n
q]'と出力する。



ネームサーバの応答はデフォルトの 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 パケット
 は次の例のように表示される:



-2icsd-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+2






一行目はネットワーク icsd の ホスト 112 から ネットワークjssmag へブロードキャストされるレーザライタを探す要求送信である。nbp の id は 190 。
二行目はその要求へのホスト jssmag.209 からの応答(id 番号が同じであることに注意)で、``RM1140''という名前のレーザライタを 250 番ポートに持っていることを答えている。
三行目は同じ要求に対する別の返答でホスト techpit が186番ポートに "tecpit" が登録されていることを答えている。



ATP パケット
 は次のように表示される:



-2jssmag.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+2






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 バイトのデータグラムはあらわれていない:



-2arizona.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 のシーケンス情報
には実際には 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 パケットに対してのみ働く。