名前
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 (名前でも番号でもよい)である。修飾子には三つの種類がある:
キーワードなしで識別子があらわれた場合、直前にあらわれたキーワードを 伴っているとみなされる。 たとえば、 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
この例は 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
TCP パケット
(注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものと みなして記述してある。もしこのプロトコルに通じていないようなら、この記 述だけでなく、tcpdump そのものも役に立たないだろうが。)
一般的なフォーマットは下記の通り:
src > dst: flags data-seqno ack window urgent options
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
これに対して、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
いくつのかの 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)
例外的なものを検出した場合、追加のフィールドを[ ] で囲んで表示するだろ う:もし問合せ(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 はドメインが存在しない、という 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 は 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 フラグが複数与えられると(-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
一般に、全ての 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
アップルトークのアドレスは次の形式で表示される。
net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
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
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
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
フラグメント化禁止フラグ の設定されたパケットの場合、行末に (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 によって管理されている。
IPv6/IPsec のサポートは WIDE/KAME プロジェクトによって追加された。 このプログラムは Eric Young の SSLeay ライブラリを特定の設定の元に使用している。
バグ
問題点、バグ、質問、拡張のお願いなどは、以下のアドレスに送ってほしい。
ソースコードの寄贈などは以下のアドレスへ送ってほしい。
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 パケットに対してのみ働く。