端的に言うならば、パケットキャプチャ
これを用いることにより、ターゲット間で、どのようなパケットが送られているのかが分かるようになります。
ただし、まったくフィルタリングされていない、素のデータがガンガン流れるので、必要なデータだけを表示するように設定しないと大事なデータを取りこぼす恐れがあります。
tcpdumpのパラメータには3種類のものがあるらしい
type （対象となるパケットの種類を指定する）
dir （通信の方向を指定する）
protocol （通信のプロトコルを指定する）
type
host
net
port
dir
src
det
src or det
src and src
protocol
ether
fddi
mopdl
ip
ip6
arp
rarp
decnet
lat
sca
moprc
icmp
icmp6
tcp
udp
tcpdump host [IPアドレス] (and port [ポート番号」）
これ以降は、man コマンドで表示されるものを掲載
オプション
-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 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 はトランザクションを終了する。 そ し て 、 jss-
mag.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)