tcpdump

名前

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(条件式)

例

ホスト sundown にかかわる全ての入出力パケットを表示する: ホスト helios と hot あるいは ace との通信を表示する: ホスト ace と helios を除く全てのホストとのIPパケットを表示する: ローカルネットのホスト群とネットワーク Berkeley のホスト群との通信を表示する: インターネットへのゲートウェイの snup を通過する全ての ftp 通信を表示する(条件式はシェルが括弧を(誤って)解釈するのを避けるためにクオートされている点に注意せよ): ローカルホストへの入出力の通信を除外して表示する(他のネットワークへのゲートウェイであるとして、ローカルネットワークを除外する例): ローカルホスト以外が関わる TCP 通信の TCP スタートとエンドのパケット(SYN と FIN のパケット)を表示する: ゲートウェイ snup を通過する 576 バイト以上の IP パケットを表示する: イーサネットのブロードキャストまたはマルチキャストを 必要としない IP のブロードキャストまたはマルチキャストを表示する: echo 要求/応答(つまり ping のパケット)以外のすべての ICMP パケットを表示する:

出力形式

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バイトの圧縮ヘッダを持つ ARP/RARP パケット arp/rarp 出力は要求のタイプとその引数を表示する。フォーマットそれ自体 が自身の内容の説明となる。この短い例はホスト rtsg から csam への `rlogin' の開始時のものである。 一行目は rtsg が インターネットホスト csam のイーサネットアドレスを尋ねる arp パケットを送信した様子。csam はイーサネットアドレスを返信している(この例でイーサネットアドレスは大文字で、インターネットアドレスは小文字で表示されている)。 この例は tcpdump -n で実行するとこのように簡略化される: Tcpdump -e で実行すると最初のパケットがブロードキャストで二番目は point-to-point であることが見てとれる: 最初のパケットは source のイーサネットアドレスが RTSG で、 ディスティネーションがイーサネットのブロードキャストであり、 タイプフィールドは 16 進の 0806(ETHER_ARP)、全長が 64 バイトであることがわかる。 TCP パケット (注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものと みなして記述してある。もしこのプロトコルに通じていないようなら、この記 述だけでなく、tcpdump そのものも役に立たないだろうが。) 一般的なフォーマットは下記の通り: 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 の 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 のポートから UDP データグラムが ホスト broadcast すなわちインターネットブロードキャストアドレスの who のポートへ送られたことを表示している。 パケットはユーザデータ 84 バイトを含んでいる。 いくつのかの UDP サービスに関しては(そのソースまたはディスネーション のポート番号より)解釈することができ、より上位の層におけるプロトコル 情報を表示する。特にドメインネームサービス要求(RFC-1034/1035)や NFS についての Sun RPC (RFC-1050)について出力される。 UDP ネームサービス要求 (注:以下は RFC-1035 で記述される ドメインネームサービスプロトコルを 理解しているものとみなして記述している。 もしこのプロトコルに通じていないようなら、以下の記述はちんぷんかんぷんかもしれない。) ネームサーバの要求は、 ホスト 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 ネームサーバ応答 ネームサーバからの応答は、 最初の例では、 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 ([email protected]) が書いた。 NFS 要求と回答 Sun NFS(Network File System)の要求と応答は次のように出力される: 一行目はホスト 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) フラグが与えられている場合、追加の情報も出力される。例: (-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) 要求と応答は以下のように表示される。 最初の行で、ホスト 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 ファイルが アップルトークネットとノード番号を名前に変換するのに利用される。 ファイルの形式は下記の通り。 最初の二行はアップルトークネットワークに名前を与える。三行目は特定のホストの名前を与える(ホストはネットワーク番号の第三オクテットで識別される - ネットワーク番号は二オクテットで なければならず、またホスト番 号は三オクテットで なければならない。番号と名前は空白文字で区切られる(blank か tab)。 /etc/atalk.names ファイルは空行とコメント行(`#'で始まる行)を含んでもよい。 アップルトークのアドレスは次の形式で表示される。 ( /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 の ホスト 112 から ネットワークjssmag へブロードキャストされるレーザライタを探す要求送信である。nbp の id は 190 。 二行目はその要求へのホスト jssmag.209 からの応答(id 番号が同じであることに注意)で、``RM1140''という名前のレーザライタを 250 番ポートに持っていることを答えている。 三行目は同じ要求に対する別の返答でホスト techpit が186番ポートに "tecpit" が登録されていることを答えている。 ATP パケット は次のように表示される: 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) インターネットデータグラムのフラグメント化されたものは次のように表示する。 (最初の形式はまだ続くフラグメントがあることを示し、二番目の形式はそ れが最後のフラグメントであることを示す) id はフラグメントの id 。 size はフラグメントの IP ヘッダを除くサイズ(バイトで)。 offset はフラグメントのもともとのデータグラム内でのオフセット(バイトで)。 フラグメントの情報はフラグメント毎に表示される。最初のフラグメントには 上位プロトコルのヘッダを含み、フラグメント情報はプロトコル情報に続いて 表示される。二番目以降のフラグメントには上位プロトコルの情報を含まない ので、フラグメント情報はソースおよびディスティネーションアドレスに続いて表示される。 以下の例は CSNET で接続された arizona.edu から lbl-rtsg.arpa への ftp 接続の一部を示すが、これには 576 バイトのデータグラムはあらわれていない: 二つの注意点がある: 一つ目として、二行目で示されるアドレスにはポート 番号は含まれていない点に注意すること。 TCP プロトコルの情報は最初のフラグメントに含まれるため、 残りのフラグメントからは表示すべきポート番号やシーケンス番号がわからないためである。 二つ目は、一行目の TCP のシーケンス情報 には実際には 512 バイト(最初のフラグメントで 308 バイト、二番目のフラ グメントで204 バイトの場合)のユーザデータが 308 バイトであるかのように 表示されている点である。シーケンスの漏れやパケットの ack の対応を調査 するとき、ここに悩まされることがあるかもしれない。 フラグメント化禁止フラグ の設定されたパケットの場合、行末に (DF)と表示する。 時間表示 デフォルトでは全ての出力行の先頭にタイムスタンプがつく。タイムスタンプは現在の時刻を次の形式で表示し、 これは、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 パケットに対してのみ働く。