tcpdump(1) FreeBSD 一般コマンドマニュアル

tcpdump

前のページ 上に戻る 次のページ

tcpdump



書式

       tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]
               [ -i interface ] [ -m module ] [ -r file ] [ -s
       snaplen ]
               [ -T type ] [ -w file ]
               [ -E algo:secret ] [ expression ]


解説

       tcpdump は、オプションで指定されたネットワークインタフェー
       ス上で取得可能なパケットのヘッダのうち expression にマッチ
       するものを出力します。

       SunOS B>上B>の nit B>なB>いB>し bpf B>のB>場B>合: tcpdump を実行するには、
       /dev/nit   ないし /dev/bpf* への読み込みアクセス権が必要で
       す。 Solaris B>上B>の dlpi B>のB>場B>合: /dev/le 等のネットワーク 仮
       想 デ バ イスへの読み書きアクセス権が必要です。 HP-UX B>上B>の
       dlpi B>のB>場B>合: 使用者が root であるか、プログラムが root  に
       setuid  されてインストールされている場合のみ実行可能です。
       IRIX B>上B>の snoop B>のB>場B>合: 使用者が root であるか、プログラム
       が root に setuid されてインストールされている場合のみ実行
       可能です。 Linux B>のB>場B>合: 使用者が root であるか、プログ ラ
       ムが root に setuid されてインストールされている場合のみ実
       行可能です。 Ultrix B>おB>よB>び Digital UNIX B>のB>場B>合: スーパユー
       ザ が、 pfconfig(8) を用いて promiscuous-mode での操作を許
       可していれば、どのユーザも tcpdump を起動できます。 BSD B>の
       B>場B>合: /dev/bpf* への読み込みアクセス権が必要です。


オプション

       -a      ネットワークアドレスとブロードキャストアドレスを名
              前に変換しようとします。

       -c     count で指定した数のパケットを受信した後に終了し ま
              す。

       -d      解釈されたパケットマッチングコードを読みやすい形に
              整形した後、標準出力にダンプして停止します。

       -dd    C プログラムの断片の形でパケットマッチングコード を
              ダンプします。

       -ddd   (先頭に個数を付加した) 十進数の形でパケットマッチン
              グコードをダンプします。

       -e     各ダンプ行ごとに、リンクレベルのヘッダを出 力 し ま
              す。

       -E     algo:secret  を、IPsec ESP パケットの解読に使用しま
              す。アルゴリズムは des-cbc, 3des-cbc, blowfish-cbc,
              rc3-cbc, cast128-cbc, none のいずれかです。デフォル
              トは des-cbc です。パケット解読能力は、 tcpdump  が
              暗 号機能付きでコンパイルされた場合のみ存在します。
              secret は、ESP 秘密鍵の ASCII テキストです。現 状、

       -F     フィルタの表現として、file に記述してある内容を用い
              ます。コマンドラインで指定された追加表現は、無視 さ
              れます。

       -i     interface  で指定されたインタフェースを監視します。
              指定されない場合には、tcpdump はシステムインタ フェ
              ー スリストの中で最も小さい番号の稼働中のものを検索
              し、監視するインタフェースとして設定します (ルー プ
              バックインタフェースは検索しません)。この動作は、最
              初にインタフェースが選択された時点で終了します。

              2.2 以降のカーネルの Linux システムでは、 interface
              引数 ``any'' を指定して全インタフェースからのパケッ
              トを捕捉可能です。 ``any''  デ バ イ ス で の 捕 捉
              は、promiscuous-mode   ではないことに注意してくださ
              い。

       -l     標準出力を行バッファリングにします。データを捕捉 し
              つ つ、そのデータを見たい場合には、本オプションは有
              効です。例えば
              ``tcpdump  -l  |  tee dat''  や  ``tcpdump  -l    >
              dat  &  tail  -f  dat'' のように使用します。

       -n     アドレス (IP アドレスやポート番号など) を名前に変換
              しません。

       -N     ホスト名のうち、ドメイン名の表示をしませ ん。 例 え
              ば、 本オプションを指定すると、``nic.ddn.mil'' とは
              表示されず、かわりに ``nic'' とだけ表示します。

       -m     SMI MIB モジュールの定義を、ファイル module から ロ
              ー ドします。複数の MIB モジュールを tcpdump にロー
              ドするために、本オプションを複数回使用可能です。

       -O     パケットマッチングコードのオプティマイザを動かし ま
              せ ん。本オプションは、オプティマイザ中のバグを疑う
              場合にのみ有効なものです。

       -p     ネットワークインタフェースを、promiscuous mode に設
              定 しません。ネットワークインタフェースは、何らかの
              理由により promiscuous mode に設定されることもあ り
              得 るということに注意してください。ゆえに `-p' オプ
              ション は、`ether  host  {local-hw-addr}  or  ether
              broadcast' の短縮形として使うことは出来ません。

       -q     素早い (静かな?) 出力を行ないます。出力する行を短く
              するために、通常出力されるプロトコル情報の一部は 出
              力されません。

       -r     パケットを、file で指定したファイル  (-w オプション
              で作成されます) から読み込みます。file とし て``-''
              が指定された場合は標準入力が用いられます。
              が減るということに注意してください。これにより、 パ
              ケッ ト が 消失するかもしれません。snaplen の大きさ
              を、必要なプロトコル情報を取得できる最小の値にと ど
              め る よ うにしてください。 snaplen を 0 に設定する
              と、パケット全体の捕捉に必要な長さを使用すること を
              意味します。

       -T     "expression"   に よ り選択されたパケットを強制的に
              type で指定されたタイプと解釈します。有効なタ イ プ
              は、 cnfp (Cisco NetFlow プロトコル), rpc (リモート
              プロシージャコール) rtp (リアルタイムアプリケーショ
              ン プロトコル) rtcp (リアルタイムアプリケーション制
              御プロトコル) snmp (シンプルネットワークマネージ メ
              ントプロトコル) vat (ビジュアルオーディオツール) wb
              (ディストリビューテッドホワイトボード) です。

       -R     ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に
              基 いているものと仮定します。指定すると、tcpdump は
              リレー防止フィールドを表示しません。 ESP/AH 仕様 に
              は プロトコルバージョンフィールドがありませんので、
              tcpdump は ESP/AH プロトコルのバージョンを推定で き
              ません、

       -S     TCP  シーケンス番号を相対番号ではなく、絶対番号で出
              力します。

       -t     各ダンプ行のタイムスタンプを出力しません。

       -tt    各ダンプ行毎にタイムスタンプを人間が読みやすい形 に
              変換せずに出力します。

       -ttt    直前のダンプ行と現在のダンプ行の差分 (マイクロ秒単
              位) を表示します。

       -tttt  各ダンプ行で、デフォルト書式でタイムスタンプを表 示
              し、その前に日付を付けます。

       -v     ( 少 し で はありますが) 出力情報を増やします。例え
              ば、IP パケット中の TTL、識別、全長、IP パケット 中
              の オプションが表示されます。追加のパケットの完全性
              確認が有効になります。これは例えば IP およ び  ICMP
              のヘッダのチェックサムです。

       -vv     さらに多くの情報を出力します。例えば、NFS の返答パ
              ケットの追加フィールドを出力します。

       -vvv   もっと多くの情報を出力します。例えば、telnet SB ...
              SE   オ プ ショ ン が完全に表示されます。 -X 付きで
              は、telnet オプションが 16 進数で表示されます。

       -w     受信した生パケットを、解析したり画面に出力したり せ
              ず に  file  で指定したファイルに出力します。本オプ
              部が16 進数と ASCII の組み合わせで表示されます。

        expression
              ダンプするパケットを選択します。expression が指定さ
              れない場合には、ネットワーク上のすべてのパケット が
              ダ ン プ対象になります。それ以外の場合には、expres-
              sion の条件が真になるパケットのみダンプします。

              expression は、1 つ以上の プリミティブから成り立 ち
              ま す。 プリミティブは通常 1 つ以上の限定子のついた
              id (名前もしくは番号) から成り立ちます。限定子は、3
              種類あります。

              型     限定子は id 名や番号が参照するものの種類を指
                     します。型には host, net, port がありま す。
                     例 え ば、`host foo', `net 128.3', `port 20'
                     のように用います。型限定子が指定されない場合
                     には、 host が指定されたものとみなされます。

              方向   限定子は、パケットが id へ出ていく方 向 か、
                     id   か ら来る方向か、もしくはその両方かとい
                     う、特定の転送方向を指定します。指定可能な方
                     向 は、 src, dst, src or dst, src and dst の
                     4 つで す。 例 え ば、`src  foo',  `dst  net
                     128.3',  `src or dst port ftp-data' のように
                     指定します。もし方向限定子が指定されない場合
                     には、 src or dst が指定されたものとみなしま
                     す。 `null' リンクレイヤ (つまり、slip な ど
                     ポイント・トゥ・ポイント・プロトコル) では、
                     必要な方向を指定するのに inboundoutbound
                     限定子を用いる事ができます。

              プロトコル
                     限定子は、特定のプロトコルに一致するパケット
                     のみに制限します。プロトコルとして指定可能な
                     も の は、  ether,  fddi,  tr, ip, ip6, arp,
                     rarp, decnet, lat, sca, moprc,  mopdl,  iso,
                     esis,  isis, icmp, icmp6, tcp , udp です。例
                     えば `ether src foo', `arp net 128.3',  `tcp
                     port  21' のように使用します。もしプロトコル
                     限定子が指定されない場合には、上記のプロトコ
                     ルのうち、型に矛盾しないすべてのものが指定さ
                     れたものとみなしま す。 例 え ば  `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' の別名になっています。解
              析ではこれらを「特定のネットワークインタフェース で
              使 われるデータリンクレベル」を意味するものとして同
              broadcast, less, greater と算術演算表現です。これら
              の 後ろにパターンが続く事はありません。プリミティブ
              キーワードについては後述します。

              より複雑なフィルタの表現は、プリミティブの 結 合 に
              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 port ftp
              or tcp dst port ftp-data or tcp dst port domain' と
              同じ意味です。

              許されるプリミティブは、以下の通りです。

              dst host host
                     IPv4/v6 パケットの終点フィールドが host で指
                     定したものの場合に、真となります。 host は、
                     ホスト名もしくは IP アドレスです。

              src host host
                     IPv4/v6 パケットの始点フィールドが host で指
                     定したものの場合に、真となります。

              host host
                     IPv4/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 だった場合に、真となりま
                     の 構文は、現在のところ、IPv6 が有効な構成で
                     は動作しません。

              dst net net
                     パケットの終点 IPv4/v6 アドレスが、 net で指
                     定 さ れたネットワークに属するものである場合
                     に、真となります。 net は、アドレス値もし く
                     は  /etc/networks で定義されたネットワーク名
                     のいずれかを指定可能です ( 詳 し く は、net-
                     works(4) を参照)。

              src net net
                     パケットの始点 IPv4/v6 アドレスが、 net で指
                     定されたネットワークに属するものである 場 合
                     に、真となります。

              net net
                     始点 IPv4/v6 アドレスもしくは終点 IPv4/v6 ア
                     ドレスが net で指定されたネットワークに属 す
                     るものである場合に、真となります。

              net net mask mask
                     IP アドレスが、指定された net および netmask
                     の値で決まるネットワークに属するものである場
                     合に、真となります。 srcdst を指定する事
                     も可能です。この構文は IPv6 net では正当でな
                     いことに注意してください。

              net net/len
                     IPv4/v6   ア ドレスが、指定された net および
                     len のビット長のネットマスクで決まるネットワ
                     ークに属するものである場合に、真となります。
                     srcdst を指定する事も可能です。

              dst port port
                     パケットが ip/tcp, ip/udp, ip6/tcp,  ip6/udp
                     のいずれかであり、終点ポート番号が port の場
                     合に、真となります。 port で指定されるポート
                     番 号は、値もしくは /etc/services で定義され
                     ているサービス名で指定可能です ( tcp(4P)udp(4P)  を参照)。ポート番号がサービス名にて
                     指定された場合、ポート番号とプロトコルの両方
                     がチェック対象になります。ポート番号や、あい
                     まいなサービス名が指定された場合には、ポート
                     番号のみがチェック対象となります(例えば、dst
                     port 513 は、 tcp/login と udp/who の両方 を
                     出 力 し、port  domain   は、tcp/domain   と
                     udp/domain の両方を出力します)。

              src port port
                     パケットが port で指定した始点ポート番号を保
                     持している場合に真となります。
                          len <= length
                     の指定と等価です。

              greater length
                     パケットが length で指定した長さ以上の場合、
                     真となります。これは、
                          len >= length
                     と等価です。

              ip proto protocol
                     パケットが protocol で指定したプロトコル型の
                     IP   パケット ( 詳細は ip(4P) を参照) の場合
                     に、真となります。 protocol は、数字もしくは
                     icmp,  icmp6, igmp, igrp, pim, ah, esp, udp,
                     or tcp のいずれかの名前が指定可能で す。tcp,
                     udp, icmp の各識別子はキーワードでもであり、
                     バックスラッシュ (\)(C-shell では \\) を用い
                     てエスケープしなければならないことに注意して
                     ください。このプリミティブはプロトコルヘッダ
                     チェーンを追跡しないことに注意してください。

              ip6 proto protocol
                     パケットがプロトコル型 protocol の IPv6   パ
                     ケットである場合に、真となります。このプリミ
                     ティブはプロトコルヘッダチェーンを追跡しない
                     ことに注意してください。

              ip6 protochain protocol
                     パ ケッ トが IPv6 パケットであり、プロトコル
                     ヘッダチェーン中にタイプ protocol のプロトコ
                     ル ヘッダが含まれるばあい に、真となります。
                     例えば
                          ip6 protochain 6
                     は、TCP プロトコルヘッダがプロトコル ヘッ ダ
                     チェーン中に含まれる任意のパケットにマッチし
                     ます。パケット中には、IPv6 ヘッダと TCP ヘッ
                     ダ の 間に、例えば、認証ヘッダ、ルーティング
                     ヘッダ、ホップ毎のオプションヘッダが含まれ得
                     ま す。このプリミティブが出力する BPF コード
                     は、複雑であり tcpdump 中の BPF 最適化コード
                     では最適化できません。よって、この動作はいく
                     ぶん遅いです。

              ip protochain protocol
                     Equivalent to ip6 protochain  protocol,  but
                     this is for IPv4.

              ether broadcast
                     パケットがイーサネットブロードキャストパケッ
                     トの場合に、真となります。 ether キーワー ド
                     は、省略可能です。

                     に、真となります。

              ip6 multicast
                     パケットが IPv6 マルチキャストパケットの場合
                     に、真となります。

              ether proto protocol
                     パ ケットが protocol で指定した ether 型の場
                     合に、真になります。 protocol は、数字もしく
                     は  ip, ip6, arp, rarp, atalk, aarp, decnet,
                     sca, lat, mopdl, moprc, iso のいずれかの名前
                     を指定可能です。これらの識別子はキーワードで
                     もあり、バックスラッシュ (\) でエスケープ し
                     な け れ ば ならないことに注意してください。
                     [FDDI の場合 (例えば `fddi protocol  arp')、
                     プ ロトコルの識別は IEEE802.2 の論理リンク制
                     御 (LLC) ヘッダによって行われます。通常こ れ
                     は  FDDI   ヘッダの上の層にあります。tcpdump
                     は、プロトコル識別子でフィルタリングするとき
                     は、 すべての FDDI パケットは LLC ヘッダを含
                     み、かつその LLC ヘッダがいわゆる SNAP 形 式
                     で あ る と 仮定します。 Token Ring も同様で
                     す。]

              decnet src host
                     DECNET パケットの始点アドレスが host の場 合
                     に、真となります。これは ``10.123'' という形
                     式のアドレスでも DECNET のホスト名でも構いま
                     せん。[DECNET のホスト名は DECNET を動かすよ
                     うに設定された Ultrix システムのみでサポート
                     されます。]

              decnet dst host
                     DECNET  パケットの終点アドレスが host の場合
                     に、真となります。

              decnet host host
                     DECNET パケットの始点あるいは終点アドレス が
                     host の場合に、真となります。

              ip, ip6, arp, rarp, atalk, aarp, decnet, iso
                          ether proto p
                     の短縮形です。p の部分には、上記のいずれかの
                     プロトコル名が入ります。

              lat, moprc, mopdl
                          ether proto p
                     の短縮形です。p の部分には、上記のいずれかの
                     プ ロトコル名が入ります。 tcpdump は今のとこ
                     ろこれらのプロトコルを解釈できない事に注意し
                     てください。


              iso proto protocol
                     パ ケッ ト がプロトコル型 protocol の OSI パ
                     ケットの場合、真になります。 protocol は数値
                     もしくは clnp, esis, isis という名前のいずれ
                     かです。

              clnp, esis, isis
                          iso proto p
                     の短縮形です。p の部分には、上記のいずれかの
                     プ ロトコル名が入ります。 tcpdump はこれらの
                     プロトコルを完全には解釈できない事に注意して
                     ください。

              expr relop expr
                     relop は、>, <, >=, <=, =, != のいずれかであ
                     り、expr の部分には、(標準 C 言語の構文で 表
                     現 された) 整数定数や通常の二項演算子 [+, -,
                     *, /, &, |]、length 演算子、そして特殊 な パ
                     ケットデータへのアクセス演算子などからなる算
                     術表現が入って、その関係が成立する場合に、真
                     となります。パケット内部のデータにアクセスす
                     るためには、以下の構文を用います。
                          proto [ expr : size ]
                     protoは、ether, fddi,  tr,  ip,  arp,  rarp,
                     tcp,  udp,  icmp, ip6 のいずれかであり、イン
                     デックス操作を行うプロトコル層を指示します。
                     tcp,  udp   および他の上位層プロトコル型は、
                     IPv4 のみに適用され、IPv6 には適用されないこ
                     と に 注意してください (これは将来修正されま
                     す)。指示したプロトコル層からの相対バイト オ
                     フ セットは、expr で指定します。 size は省略
                     可能で、取得するフィールドのデータ長を表しま
                     す。データ長としては、1,2,4 のいずれかを指定
                     することが可能であり、デフォルトでは 1 が 指
                     定 さ れたものとみなされます。キーワード len
                     で示されるデータ長演算子は、パケット長を与え
                     ます。

                     例えば、`ether[0] & 1 != 0' は、全てのマルチ
                     キャストパケットを捕捉します。 `ip[0] &  0xf
                     != 5' という表現は、すべてのオプション付きIP
                     パケットを捕捉することを意味します。`ip[6:2]
                     & 0x1fff = 0' という表現は、フラグメントのな
                     いデータグラムパケット、もしくはフラグメント
                     化されたデータグラムのうち最初のフラグメント
                     を捕捉します。この検査は、tcp および udp  の
                     インデックス操作においては、暗黙のうちに適用
                     されます。例えば、tcp[0] は常に TCP ヘッダの
                     先頭バイトを指し、決して各フラグメントの先頭
                     バイトを指すものではありません。

              積は、同じ演算優先度を持ち、左から右へ評価 さ れ ま
              す。 論 理 積の場合には、単に識別子を並べるのではな
              く、明示的に and を使用しなければならないことに注意
              して下さい。

              キ ーワードなしで識別子が与えられている場合には、最
              も最近用いられたキーワードが付加されているものと 仮
              定されます。例えば、
                   not host vs and ace
              は、
                   not host vs and host ace
              の短縮形ですが、
                   not ( host vs or ace )
              と混同してしまいがちなので気をつけましょう。

              引 数 expression は、単一の引数としても複数の引数と
              しても、どちらか便利な方で、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

       echo   要 求/ 応答以外 (つまり ping パケット以外) の全ての
       ICMP パケットを表示するには、以下のように実行します。
              tcpdump 'icmp[0] != 8 and icmp[0] != 0'


出力形式

       tcpdump の出力は、プロトコル依存です。以下の説明では、簡単
       なパラメータの記述と、おおよそのフォーマットの説明を行ない
       ます。

       B>リB>ンB>クB>レB>ベB>ルB>ヘB>ッI</I>ダ

       もし '-e' オプションが指定されると、リンクレベルヘッダが出
       力されます。イーサネットにおいては、始点と終点のアドレス、
       プロトコル、そしてパケット長が出力されます。

       FDDI ネットワークにおいては、'-e' オプションが指定されると
       tcpdump は、「フレーム制御」フィールド、発信元と終点アドレ
       ス、そしてパケット長を出力します。「フレーム制御」フィール
       ドはパケットの残りの部分の解釈を決定します。(IP データグラ
       ムを含むような) 通常のパケットは `async' パケットで、 0 か
       ら 7 の間の優先順位を持ちます。例えば、`async4' です。こう
       したパケットは IEEE802.2 の論理リンク制御 (LLC) パケットを
       含むと仮定されます。 LLC ヘッダは、それが ISO データグラム
       でない場合やいわゆる SNAP パケットのときには出力されます。

       Token  Ring   ネッ トワークでは、'-e' オプションを指定する
       と、tcpdump は、アクセス制御」と「フレーム制御」のフィール
       ド、 始 点 と終点のアドレス、パケット長を表示します。 FDDI
       ネットワークでは、パケットは LLC パケットを含むと仮定さ れ
       ます。オプション '-e' の指定の有無にかかわらず、始点経路制
       御されたパケットに対しては、始点経路制御情報が表示さ れ ま
       す。

        ( 注 意:  以下の記述は、利用者が RFC1144 に記述されている
       SLIP 圧縮アルゴリズムについての知識がある前提で書いてい ま
       す。)

       SLIP   に よるリンクにおいては、方向指示子 (``I'' が入力方
       向、``O'' が出力方向)、パケット型、そして圧縮情報が出力 さ
       れ ま す。パケット型は、最初に出力されます。パケット型には
       iputcp、そして ctcp の 3 つがあります。 ip 型パケット の
       場 合、上記以上のリンク情報は表示されません。 TCP パケット
       の場合には、コネクション識別子がパケット型に続いて出力され
       ます。パケットが圧縮されている場合、符号化されたヘッダが出
       力されます。特殊な場合は *S+n*SA+n のように出力され ま
       す。 ここで n は、シーケンス番号 (もしくはシーケンス番号お
       よび ack) が変更された回数です。特殊な場合でなければ、0 回
       以 上 の変更について出力されます。変更は、U (緊急 (urgent)
       ポインタ)、W (ウィンドウ)、A (ack)、S (シーケンス番号)、そ
       し て I (パケット ID) で示され、変動量 (+n or -n) もしくは
       新しい値 (=n) が続きます。最後に、パケット内のデータの総量
       時のパケットの実例を示します。
              arp who-has csam tell rtsg
              arp reply csam is-at CSAM
       1行目は、ホスト 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 として起動した場合には、最初のパケットはブロ ー
       ドキャストパケットであり、次のパケットはポイントツーポイン
       トのパケットであることがわかります。
              RTSG Broadcast 0806  64: arp who-has csam tell rtsg
              CSAM RTSG 0806  64: arp reply csam is-at CSAM
       最初のパケットについては、始点のイーサネットア ド レ ス は
       RTSG  であり、終点はイーサネットブロードキャストアドレス、
       型フィールドには 16 進数の値 0806 (ETHER_ARP を意味します)
       が格納されており、総パケット長は 64 バイトであると表示して
       います。

       TCP B>パB>ケB>ッB>ト

       (注意:以下の記述は、RFC793 に記述されている TCP プロトコル
       についての知識があることを前提に記述されています。この知識
       がない場合、本記述と tcpdump のいずれもあなたには役に立 た
       ないでしょう。)

       TCP プロトコル行の一般的な形式は、以下の通りです。
              src > dst: flags data-seqno ack window urgent options
       srcdst は、それぞれ始点と終点の IP アドレスとポート番
       号です。flags の部分には、S (SYN), F (FIN),  P  (PUSH),  R
       (RST) の組み合わせ、もしくは単なる `.' (フラグなし) が入り
       ます。 data-seqno は、このパケット内のデータがシーケンス空
       間 の どの部分にあたるかを示します (以下の例を参照して下さ
       い)。 ack は、本コネクション上を逆方向に次に流れるデータパ
       ケットのシーケンス番号です。 window は、本コネクションの逆
       方向のパケットを格納するバッファサイズです。 urg   は、 パ
       ケッ ト中に `urgent' (緊急) データが格納されていることを示
       します。 options は、例えば <mss 1024> のように、アング ル
       ブラケット (大小記号) で括られた tcp オプションです。

       srcdst、 そして flags は、常に表示されます。他のフィール
       ドは、パケットの TCP ヘッダに依存し、表示できる場合だけ 表
       示されます。

       以下の例は、ホスト rtsg からホスト csam への rlogin 開設時
       のシーケンスの一部です。
              rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>

       ない nbytes のユーザデータということ」を意味していま す。)
       こ のパケット中に ack はなく、有効な受信ウィンドウの大きさ
       は 4096 バイトであり、1024 バイトの最大セグメントサイズ 要
       求を行なうオプションが付加されています。

       csam は、rtsg から送られたパケットと類似したパケットを送り
       返しますが、 rtsg の送った SYN に対する ack が含まれるとこ
       ろ が 異なります。続いて、rtsg は csam の SYN に対する ack
       を返します。 `.' は、S (SYN), F (FIN), P (PUSH),  R  (RST)
       のいずれのフラグも立っていないことを意味します。パケットは
       データを含まないため、データシーケンス番号は入りま せ ん。
       ack  シーケンス番号が小さい整数 (1) であることに注意して下
       さい。 tcpdump は、初めて TCP の「通信」を検出する と、 パ
       ケットから取得したシーケンス番号を表示します。通信のその後
       のパケットについては、現在のパケットシーケンス番号と、この
       最初のシーケンス番号の間の差を表示します。このことは、最初
       に取得した以降のシーケンス番号は、通信データストリームの相
       対位置として解釈できることを意味します (最初の各方向のデー
       タバイトは 1 です)。`-S' は、本機能を無効にし、元のシー ケ
       ンス番号を表示します。

       6  行目では、rtsg は csam に 19 バイトのデータを送信してい
       ます (rtsg -> csam の方向の通信における、2 バイト目から 20
       バイト目までのデータ)。PUSH フラグがこのパケットでは設定さ
       れています。 7 行目では、csam は rtsg から 20 バイトまでの
       デ ー タ を 受 け とった旨のレスポンスを rtsg に返していま
       す。csam の受信ウィンドウが19バイト小さくなったことか ら、
       これらのデータのほとんどは、ソケットバッファの中に存在する
       ことが分かります。 csam は、rtsg に 1 バイトのデータを送信
       し ています。 8 行めと 9 行めでは、csam は緊急 (urgent) で
       PUSH フラグの設定された 2 バイトデータを送信しています。

       スナップショットが小さ過ぎて tcpdump が TCP ヘッダ全体を捕
       え なかった場合、可能な限りのヘッダを解釈し、``[|tcp]'' を
       表示して残りを解釈できなかったことを示します。 (短か過ぎる
       またはヘッダを越えてしまうといった) 不正なオプションをヘッ
       ダが持つ場合には、tcpdump は ``[bad opt]'' を表示して残 り
       のオプションを解釈しません (どこから開始したら良いのか分か
       らないからです)。ヘッダ長によりオプションが存在すること が
       分かるが、 IP データグラム長がオプションがそこにあるために
       十分な長さではない場合に、 tcpdump は ``[bad hdr length]''
       を表示します。

       B>特B>定B>フB>ラB>グB>のB>組B>みB>合B>わB>せ (SYN-ACK, URG-ACK B>等) B>にB>よB>る TCP B>パ
       B>ケB>ッB>トB>のB>捕B>捉

       TCP ヘッダの制御ビットセクションには、次の 6 ビットがあ り
       ます:

              URG | ACK | PSH | RST | SYN | FIN

       TCP   接続の確立に使用されるパケットを見たいものとしましょ

        0                            15                              31
       -----------------------------------------------------------------
       |          始点ポート           |       終点ポート              |
       -----------------------------------------------------------------
       |                        シーケンス番号                         |
       -----------------------------------------------------------------
       |                         確認応答番号                          |
       -----------------------------------------------------------------
       |  HL   | 予約      |U|A|P|R|S|F|        ウィンドウサイズ       |
       -----------------------------------------------------------------
       |         TCP チェックサム      |          緊急ポインタ         |
       -----------------------------------------------------------------

       TCP  ヘッダは、オプションが無ければ通常、20 オクテットのデ
       ータを持ちます。図の最初の行はオクテット 0 から 3 を示し、
       次の行はオクテット 4 から 7 を示す等となります。

       0   から数え始めると、必要な TCP 制御ビットはオクテット 13
       にあります:

        0             7|             15|             23|             31
       ----------------|---------------|---------------|----------------
       |  HL   | 予約      |U|A|P|R|S|F|        ウィンドウサイズ       |
       ----------------|---------------|---------------|----------------
       |               |13 オクテット目|               |               |

       第 13 オクテットをもっとよく見てみましょう:

                       |               |
                       |---------------|
                       |   |U|A|P|R|S|F|
                       |---------------|
                       |7   5   3     0|

       このオクテットの上位 2 ビットは予約フィールドから来てい ま
       す。  RFC  793  によると、この欄は将来の使用のために予約と
       なっていて、必ず 0 です。残りの 6 ビットは、我々が興味があ
       る  TCP 制御ビットです。このオクテットのビットを、右から左
       へ、0 から 7 と番号付けします。 PSH ビットは第 3 ビット で
       あり、URG ビットは第 5 ビットです。

       最 初の SYN だけを持つパケットが欲しいことに注意してくださ
       い。 SYN ビットがセットされた TCP データグラムが到着 す る
       と、第 13 オクテットになにが起きるか見てみましょう:

                       |   |U|A|P|R|S|F|
                       |---------------|
                       |0 0 0 0 0 0 1 0|
                       |---------------|
                       |7 6 5 4 3 2 1 0|

       SYN のみセットされている場合について理解したので、これでほ
       と んど終りです。 TCP ヘッダの第 13 オクテットの値は、ネッ
       トワークバイト順の 8 ビット符号無し整数として解釈する と、
       正確に 2 となります。

       この関係は次のように表現可能です:
              tcp[13] == 2

       この式を tcpdump のフィルタとして使用し、 SYN パケットのみ
       を持つパケットを捕捉可能です:
              tcpdump -i xl0 tcp[13] == 2

       この式は「TCP データグラムの第 13 オクテットは 10 進 数  2
       を持つ」と言っており、まさに我々が望むものです。

       次 に、SYN パケットが必要であるが、ACK や他の TCP 制御ビッ
       トについてはどうでも良い場合を考えます。 SYN-ACK が設定 さ
       れ た  TCP  データグラムが到着した時にオクテット 13 がどう
       なっているかを見てみましょう:

            |   |U|A|P|R|S|F|
            |---------------|
            |0 0 0 1 0 0 1 0|
            |---------------|
            |7 6 5 4 3 2 1 0|

       今度は、第 13 オクテットの第 1 ビットと第 4 ビットがセット
       されています。第 13 オクテットの 2 進数値は

                   00010010

       となり、10 進数では次のようになります:

          7     6     5     4     3     2     1     0
       0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18

       今 度は、tcpdump フィルタ式に 'tcp[13] == 18' を使用できま
       せん。この式は、SYN-ACK がセットされているパケットのみを選
       択 し、 SYN のみセットされているパケットを選択しないからで
       す。 ACK や他の制御ビットがセットされていようといまいと 構
       わないことを思い出してください。

       この目的を達成するために、第 13 オクテットと他の値との論理
       AND を取り、 SYN ビットを得ることが必要です。我々が欲し い
       のはどんな場合でも SYN がセットされていれば良いので、第 13
       オクテットと SYN の 2 進数値との論理 AND を取ります:


                 00010010 SYN-ACK              00000010 SYN
            AND  00000010 (SYN が欲しい)  AND  00000010 (SYN が欲しい)
                 --------                      --------
            =    00000010                 =    00000010

       (&') 特殊文字をシェルから隠す必要があることに注意してく だ
       さい。

       UDP B>パB>ケB>ッB>ト

       UDP フォーマットは、以下の rwho パケットで例示します。
              actinide.who > broadcast.who: udp 84
       これは、ホスト actinidewho ポートが UDP データグラムを
       インターネットブロードキャストアドレスであるホスト  broad-
       castwho ポートに対して送信していることを意味します。本
       パケットは、 84 バイトのユーザデータを含みます。

       いくつかの UDP サービスは(始点もしくは終点のポート番 号 か
       ら) 種類の判断が可能で、さらに上位レベルのプロトコル情報が
       出力されます。ドメインネームサービス要求  (RFC1034/1035)、
       そして、Sun RPC 呼びだし (RFC1050) を用いた NFS サービスな
       どがこの条件に該当します。

       UDP B>ネB>ーB>ムB>サB>ーB>バB>要B>求

       (注意:以下の記述は、RFC1035 に記述されているドメインサービ
       スプロトコルの知識があることを前提に書かれています。もしこ
       れらの知識がない場合には、以下の記述は未知の言語で書かれて
       いるかのように見えるでしょう。)

       ネームサーバ要求は、以下のような表示になります。
              src > dst: id op? flags qtype qclass name (len)
              h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
       ホ スト h2opolo は、helios 上のドメインサーバに対して ucb-
       vax.berkeley.edu のホスト名に対応するアドレ ス レ コ ー ド
       (qtype=A)  を問い合わせています。問い合わせの ID は `3' で
       あり、`+' は再帰要求フラグが設定されていることを意味 し ま
       す。 問い合わせの長さは 37 バイトであり、この中に UDP およ
       び IP のプロトコルヘッダの長さは含みません。質問操作は普通
       の 操作 (Query) であり、op フィールドは省略されます。op が
       他のいずれかであった場合、その op は `3' と `+' の間に表示
       さ れ ま す。これと同様に、qclass は普通のもの (C_IN) であ
       り、省略されます。他の qclass が入った場合、`A' の直後に表
       示されます。

       少数の変則的なパケットは検査され、カギカッコで囲まれた付加
       フィールドにその結果が表示されます。query が返答、ネームサ
       ー バ も しくはオーソリティセクションを含む場合、 ancount,
       nscount, arcount のいずれかが、`[na]', `[nn]', `[nau]'  の
       よ う な形式で表示されます。n は、それぞれの個数です。応答
       ビットのいずれかが設定されている (AA, RA, rcode のい ず れ
       か)  場合、もしくは「0 でなければならない」ビットが 2 バイ
       ト目と 3 バイト目に設定されている場合には、`[b2&3=x]' が出
       力されます。x は、ヘッダの 2 バイト目および 3 バイト目の値
       を 16 進で表したものです。

       UDP B>ネB>ーB>ムB>サB>ーB>バB>応B>答
       2  つめの例は、helios が質問 ID 2 の要求に対し、存在しない
       ドメイン (NXDomain) という返答コードとともに、0 個のアンサ
       ー レコード、1 つのネームサーバレコード、そして 0 個のオー
       ソリティレコードを含んだレスポンスを返 し て い ま す。`*'
       は、authoritative  answer ビットが設定されていることを示し
       ます。アンサーレコードがないため、型、クラス、データは出力
       されません。

       出 力される可能性のある他のフラグキャラクタは、`-' (再帰利
       用,RA,が設定されていない)および `|' (メッセージ切捨て, TC,
       が設定されている) です。 `question' セクションに含まれるエ
       ントリがちょうど 1 つでない場合には、 `[nq]' が出力され ま
       す。

       ネームサーバ要求および応答は、大きくなる傾向にあり、デフォ
       ルトの snaplen の値である 68 バイトの長さは、パケットを 捕
       捉してその内容を表示するには十分でないかも知れないことに注
       意して下さい。もしネームサーバトラフィックの調査を真剣に行
       な おうとするならば、-s オプションを用いて、snaplen を増や
       して下さい。自分の経験上、`-s 128' で十分使い物に な り ま
       す。


       SMB/CIFS B>のB>デB>コB>ーB>ド

       現 在の 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 パケット書式の情報とすべてのフィールドの意味につ い て
       は、  www.cifs.org   または好きな samba.org ミラーサイトの
       pub/samba/specs/ ディレクトリを見てください。 SMB パッチは
       Andrew Tridgell (tridge@samba.org) が書きました。


       NFS B>要B>求B>とB>応B>答

       Sun NFS (Network File System) 要求および応答は、以下のよう
       に表示されます。
              src.xid > dst.nfs: len op args
              src.nfs > dst.xid: reply stat len op results

       例のように運が良ければ、ファイルハンドルはデバイスのメジャ
       ー、 マイナー番号のペアと、それに続く i ノード番号と世代番
       号と解釈することができます。) wrl はリンクの内容とと も に
       `ok' と返答しています。

       3   行 め で は、sushiwrl  に対し、ファイルハンドル
       9,74/4096.6878 のディレクトリ中の `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 と長さとフラグメンテーション
       フィールドも出力しますが、この例では省略しています。) 最初
       の 行では、sushiwrl に対してファイル 21,11/12.195 のオ
       フセット 24576 バイト目から 8192 バイトを読むように要求 し
       て い ます。wrl は `ok' と返答しています。2 行めに示したパ
       ケットは応答の最初のフラグメントなので、1472 バイトしか あ
       りません (その他のデータは継続するフラグメント中に続きます
       が、これらのフラグメントは NFS ヘッダも UDP ヘッダさえも持
       たないので、使われるフィルタリングの表現によっては出力され
       ないでしょう)。-v フラグがあるのでいくつかのファイル属性 (
       ファイルデータに追加されて返されてくる) が出力されます。そ
       れらはファイルの型 (普通のファイルなら ``REG'')、(8 進数表
       現の) ファイルモード、uid と gid、そしてファイルの大きさで
       す。

       -v フラグが 2 回以上指定されると、さらに詳しい情報が出力さ
       れます。

       NFS 要求は非常に大きなデータになるため、snaplen を大きくし
       ないと詳しい出力は得られません。NFS トラフィックを監視する
       には、 `-s 192' と指定してみて下さい。

       NFS  応答パケットは RPC 操作であることを明示的には示しませ
       ん。その代わり、tcpdump は「最近の」要求を追跡して、トラン
       ザクション ID を用いて応答と照合します。応答が対応する要求
       のすぐ後に続かないと、解析することはできません。

       AFS B>のB>要B>求B>とB>応B>答

       Transarc AFS (Andrew File System) の要求と応答は次のように
       表示されます:

       クトリファイル ID 536876964/1/1  と 新 し い ファ イ ル 名
       `.newsrc' で呼び出しています。ホスト pike は、RPC 応答をリ
       ネーム呼び出しに対して返します (データパケットであり、アボ
       ートパケットではないため、これは成功しました)。

       一 般的には、AFS RPC の RPC 呼び出し名だけは最低限デコード
       されます。ほとんどの AFS RPC は、少ななくともいくらかの 引
       数がデコードされます (一般的には「興味のある」引数のみであ
       り、興味についてはある定義によります)。

       書式は、自明となることを意図していますが、 AFS およ び  RX
       の動作に親しみのない方々にとっては有用ではないかもしれませ
       ん。

       -v (冗長) フラグを 2 度指定すると、確認応答パケットと追 加
       のヘッダ情報を表示します。これは、RX 呼び出し ID、呼び出し
       番号、シーケンス番号、シリアル番号、RX パケットフ ラ グ と
       いったものです。

       -v   フラグを 2 度指定すると、追加情報が表示されます。これ
       は、RX 呼び出し ID、呼び出し番号、RX パケットフラグと いっ
       たものです。 MTU ネゴシエーション情報も、RX 確認応答パケッ
       トから表示されます。

       -v フラグを 3 度指定すると、セキュリティインデックスとサー
       ビス ID を表示します。

       アボートパケットに対しては、エラーコードが表示されます。た
       だし、Ubik ビーコンパケットは例外です (Ubik プロトコ ル で
       は、アボートパケットは、肯定投票に使用されるからです)。

       AFS  要求は非常に大きく、 snaplen を増やさなければ多くの引
       数が表示されないことに注意してください。 AFS トラフィッ ク
       を見るには `-s 256' を試してみてください。

       AFS  応答パケットは、明示的には RPC 操作を識別しません。代
       りに tcpdump が「最近の」要求の追跡を行い、応答に対応す る
       要求のマッチングを、呼び出し番号とサービス ID を使用して行
       います。応答パケットが対応する要求パケットに近くないと、パ
       ーズできないかもしれません。


       KIP Appletalk (DDP in UDP)

       UDP  データグラムでカプセル化された Appletalk DDP パケット
       は、カプセル化を解かれ、DDP パケットとしてダンプされます (
       全 て の  UDP   ヘッ ダ 情 報 は 破 棄 されます)。ファイル
       /etc/atalk.names が、Appletalk ネットワークおよびノード 番
       号を名前に変換するのに用いられます。本ファイルの内容は、以
       下のように記述されます。
              number    name


              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 port 2) が、ネットワ
       ーク icsd のノード 112 のホストのポート 220 を開いている何
       者かにデータを送信しています。次の行は、1 行めとほぼ同じ例
       ですが、始点のノード名が既知である (`office') ところが異な
       ります。 3 行目の例は、ネットワーク jssmag のノード 149 の
       ポ ート 235 から、icsd-net の NBP ポートにブロードキャスト
       でデータ送信をしています (ブロードキャストアドレ ス  (255)
       は、ホスト番号なしでネットワーク番号のみが表示されていると
       ころでわかります。このことから、/etc/atalk.names ではノ ー
       ド名とネットワーク名を区別する方がよいことが分かります)。

       NBP (name binding protocol) および ATP (Appletalk transac-
       tion protocol) パケットでは、その内容は解釈されます。他 の
       プロトコルは、プロトコル名 (もしくは、プロトコルが登録され
       ていない場合には、プロトコル番号) およびパケットサイズをダ
       ンプします。

       NBP B>パB>ケB>ッB>ト は、以下のような形式で表示されます。
              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 を
       持 つ こ と に注意して下さい) で、 ポート 250 に登録された
       RM1140 という名前のレーザライタがあると答えています。 3 行
       めは、同じ要求に対する他のホストからの応答で、ホスト tech-
       pit が、ポート 186 に登録されたレーザライタ "techpit"   を
       持っていると答えています。

       ATP B>パB>ケB>ッB>ト の形式は、以下のように表示されます。
              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 はトランザクションを解放 し ま す。 最 後 の 行
       で、jssmag.209  は次の要求を開始します。この要求の表示で付
       加されている `*' は、XO (`exactly once') が設定されてい な
       いことを示します。


       IP B>フB>ラB>グB>メB>ンB>テB>ーB>シB>ョB>ン

       フラグメントのあるインターネットデータグラムは、以下のよう
       に表示されます。
              (frag id:size@offset+)
              (frag id:size@offset)
       (最初の形式では、まだフラグメントがあることを示し、2 番 め
       の 形 式は、これが最後のフラグメントであることを示していま
       す。)

       id は、フラグメント ID です。size は、フラグメントサイズを
       バイト単位であらわしたものです。ただし IP ヘッダサイズは含
       みません。 offset は、元のデータグラムでの本フラグメントの
       オフセットをバイト単位であらわしたものです。

       フラグメント情報は、各フラグメントごとに表示されます。最初
       のフラグメントには、上位レベルのプロトコルヘッダが含まれる
       ので、フラグ情報がプロトコル情報の後に表示されます。2 つ目
       以降のフラグメントについては、上位レベルのプロトコルヘッダ
       を含まないので、フラグ情報は始点および終点アドレスの後ろに
       表示されます。例えば、 こ れ は  arizona.edu   か ら  lbl-
       rtsg.arpa への CSNET 接続での 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
       注意すべきことがいくつかあります。まず最初に、2 行目はポー
       ト番号を含みません。これは、TCP プロトコル情報は、最初のフ
       ラグメントに全て入っており、後のフラグメントを出力する時に
       はポート番号やシーケンス番号を知る術がないからです。次に、
       最初の行の TCP シーケンス情報は、パケットが 308 バイトのユ
       ーザデータを持ってるかのように表示されますが、実際には 512
       バイトのユーザデータを持っています (308 バイトが最初のフラ
       グ分で、204 バイトが 2 番目のフラグ分です)。シーケンススペ
       ースの穴をさがしたり、パケットの ack の対応が正しいかを こ
       のデータで見ようとしてはいけません。

       フラグメント不可フラグが設定されたパケットは、最後の部分に
       (DF) と印が付けられます。

       B>タB>イB>ムB>スB>タB>ンB>プ

       デフォルトでは、すべての出力行は最初にタイムスタンプが出力
       されます。タイムスタンプは、以下の形式で、現在のクロックタ
       イムを表示します
              hh:mm:ss.frac

       fornia, Berkeley, CA.

       現在は tcpdump.org で管理されています。

       現在のバージョンは http で次のところから取得可能です:

              http://www.tcpdump.org/

       元々の配布は匿名 ftp で次のところから取得可能です:
              ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

       IPv6/IPsec サポートは WIDE/KAME プロジェクトが追加し ま し
       た。 本 プログラムは、特定の構成においては、 Eric Young の
       SSLeay ライブラリを使用します。


バグ

       問題、バグ、希望の機能拡張等については次のところに送ってく
       ださい:

              tcpdump-workers@tcpdump.org

       ソースコードの寄贈等については次のところに送ってください:

              patches@tcpdump.org

       NIT では、外に出ていくトラフィックを観察できません。BPF な
       らできます。後者を用いることを推奨します。

       2.0[.x] カーネルの Linux システムにおいて:

              ループバックデバイス上のパケットは 2 度観測さ れ ま
              す。

              カ ー ネ ル内でのパケットフィルタリングは不可能であ
              り、全パケットがカーネルからコピーされてユーザモ ー
              ドでフィルタされます。

              ス ナッ プ ショットの長さ部分ではなく、パケット全体
              が、カーネルからコピーされます (2.0[.x] のパケッ ト
              捕 捉機構は、パケットの一部をユーザランドへコピーす
              るように依頼されると、パケットの正しい長さを報告 し
              ま せん。このため、ほとんどの IP パケットが tcpdump
              でエラーとなってしまいます)。

       2.2 以降のカーネルにアップグレードすることをお勧めします。

       IP  フラグメントを再構成するか、もしくは少なくとも上位プロ
       トコルの正しいデータサイズを計算するように設計しなおす必要
       があります。

       ネームサーバについての逆引きについては、正しくダンプされま
       せん。実際の要求ではなく、(empty) クエスチョンセク ショ ン
       うなパケットを偶然に受け入れてしまうことがあります。

       Token  Ring ヘッダ以外のフィールドに対するフィルタ式は、始
       点経路制御された Token Ring パケットを正しく扱わないことが
       あります。

       ip6 proto はヘッダチェーンを追跡すべきですが、現在のところ
       はそうなっていません。このために ip6 protochain が提供され
       ています。

       例 え ば tcp[0] といったトランスポート層ヘッダに対する演算
       は、 IPv6 パケットに対しては動作しません。 IPv4 パケットだ
       けを見ます。



                          3 January 2001               TCPDUMP(1)

ABELNET VPSサービス