diff --git a/ja_JP.eucJP/man/man1/cccp.1 b/ja_JP.eucJP/man/man1/cccp.1
index 2f363f40f9..a51f2cee65 100644
--- a/ja_JP.eucJP/man/man1/cccp.1
+++ b/ja_JP.eucJP/man/man1/cccp.1
@@ -1,644 +1,644 @@
 .\" %FreeBSD: src/contrib/gcc/cccp.1,v 1.3 1999/09/19 08:18:18 obrien Exp %
 .\" Copyright (c) 1991, 1992, 1993 Free Software Foundation	-*- nroff -*-
 .\" See section COPYING for conditions for redistribution
 .\"
 .\" jpman %Id: cccp.1,v 1.2 1997/05/12 00:19:12 jsakai Stab %
 .\"
 .TH cpp 1 "April 30, 1993" "FreeBSD" "GNU Tools"
 .SH 名称
 cpp \- GNU-C 互換のコンパイラプリプロセッサ
 .SH 書式
 .hy 0
 .na
 .TP
 .B cpp
 .RB "[\|" \-$ "\|]"
 .RB "[\|" \-A \c
 .I predicate\c
 .RB [ (\c
 .I value\c
 .BR ) ]\|]
 .RB "[\|" \-C "\|]" 
 .RB "[\|" \-D \c
 .I name\c
 .RB [ =\c
 .I definition\c
 \&]\|]
 .RB "[\|" \-dD "\|]"
 .RB "[\|" \-dM "\|]"
 .RB "[\|" "\-I\ "\c
 .I directory\c
 \&\|]
 .RB "[\|" \-H "\|]"
 .RB "[\|" \-I\- "\|]" 
 .RB "[\|" "\-imacros\ "\c
 .I file\c
 \&\|]
 .RB "[\|" "\-include\ "\c
 .I file\c
 \&\|]
 .RB "[\|" "\-idirafter\ "\c
 .I dir\c
 \&\|]
 .RB "[\|" "\-iprefix\ "\c
 .I prefix\c
 \&\|]
 .RB "[\|" "\-iwithprefix\ "\c
 .I dir\c
 \&\|]
 .RB "[\|" \-lang\-c "\|]"
 .RB "[\|" \-lang\-c++ "\|]"
 .RB "[\|" \-lang\-objc "\|]"
 .RB "[\|" \-lang\-objc++ "\|]"
 .RB "[\|" \-lint "\|]"
 .RB "[\|" \-M\  [ \-MG "\|]]"
 .RB "[\|" \-MM\  [ \-MG "\|]]"
 .RB "[\|" \-MD\  \c
 .I file\ \c
 \&\|]
 .RB "[\|" \-MMD\  \c
 .I file\ \c
 \&\|]
 .RB "[\|" \-nostdinc "\|]" 
 .RB "[\|" \-nostdinc++ "\|]" 
 .RB "[\|" \-P "\|]" 
 .RB "[\|" \-pedantic "\|]"
 .RB "[\|" \-pedantic\-errors "\|]"
 .RB "[\|" \-traditional "\|]" 
 .RB "[\|" \-trigraphs "\|]" 
 .RB "[\|" \-U \c
 .I name\c
 \&\|]
 .RB "[\|" \-undef "\|]"
 .RB "[\|" \-Wtrigraphs "\|]"
 .RB "[\|" \-Wcomment "\|]"
 .RB "[\|" \-Wall "\|]"
 .RB "[\|" \-Wtraditional "\|]"
 .br
 .RB "[\|" \c
 .I infile\c
 .RB | \- "\|]" 
 .RB "[\|" \c
 .I outfile\c
 .RB | \- "\|]"  
 .ad b
 .hy 1
 .SH 解説
 C プリプロセッサは、
 実際のコンパイルの前にプログラムを変換するために
 C コンパイラから自動的に利用される
 .I マクロプロセッサ\c
 です。
 長い記述を簡略してマクロとして定義することができるため、
 マクロプロセッサと呼ばれます。
 
 C プリプロセッサは、以下の4つの機能を提供します。
 .TP
 \(bu
 ヘッダファイルを読み込みます。
 これは
 プログラムに組み込まれる
 (C 言語の)宣言の入ったファイルです。
 .TP
 \(bu
 C 言語の任意の部分の省略形として \c
 .I マクロ\c
 \&を定義し、C プリプロセッサがプログラム内の全てのマクロを
 その定義で置き換えます。
 .TP
 \(bu
 条件文の処理をします。専用のプリプロセッサコマンドを用いて、
 いろいろな条件にしたがってプログラムの一部を含めたり除外したりできます。
 .TP
 \(bu
 行番号の制御をします。
 ソースファイルと
 コンパイルされた中間ファイルとを組み合わせたり再アレンジしたりするプログラムを
 用いる場合、
 コンパイラにオリジナルのソースの何行目であるかを知らせるための、
 行番号制御のプリプロセッサコマンドを利用できます。
 .PP
 C プリプロセッサは、そのインプリメントによって細かな部分に違いが
 いくつかあります。GNU C プリプロセッサの完全なドキュメントは、
 .B info
 ファイルの `\|\c
 .B cpp.info\c
 \&\|', もしくは、マニュアルの
 .I The C Preprocessor\c
 \&を参照して下さい。
 この双方は `\|\c
 .B cpp.texinfo\c
 \&\|'から生成されます。GNU C プリプロセッサは ANSI Standard C のスーパセットと
 なっています。
 
 ANSI Standard C では、今日 C プログラムで一般的に用いられている多くの
 (無害な)構造が認められていません。
 この非互換性はユーザにとっては不便であり、そのため
 GNU C preprocessor ではこの記述をデフォルトで受け付けるように作られています。
 厳密にいえば、
 ANSI Standard C にするためには
 オプションとして `\|\c
 .B \-trigraphs\c
 \&\|', `\|\c
 .B \-undef\c
 \&\|', `\|\c
 .B \-pedantic\c
 \&\|'をつけなければなりません。
 しかし経験則から、厳密な ANSI Standard C にあわせてこうした設定を
 行なうと支障のある場合が多いことがわかっています。
 
 ほとんどの場合は、C プリプロセッサは明示的に実行する必要はありません。
 C コンパイラが自動的に実行してくれるからです。しかしながら、
 明示的にプリプロセッサを実行するのが有効なことが個々にはあります。
 
 C プリプロセッサ
 は、引数として \c
 .I infile\c
 \& と
 \c
 .I outfile\c
 \&の 2 つのファイル名を期待します。
 プリプロセッサは `\|\c
 .B #include\c
 \&\|'で指定したファイルと一緒に \c
 .I infile\c
 を読み込みます。
 入力ファイルの組み合わせで作られた出力は、
 全て \c
 .I outfile\c
 \&に書かれます。
 
 .I infile\c
 \& と \c
 .I outfile\c
 \& の指定に `\|\c
 .B \-\c
 \&\|'を使用することができます。\c
 .I infile\c
 \& が `\|\c
 .B \-\c
 \&\|' であれば\c
 \& 標準入力からデータを読み、\c
 .I outfile\c
 \& が `\|\c
 .B \-\c
 \&\|' であれば標準出力へ結果を書きます。もし \c
 .I outfile\c
 \& もしくは両方のファイル名が省略された場合、
 省略されたファイルの代わりに標準入力と標準出力が使われます。
 .SH オプション
 以下が C プリプロセッサが受け付けるオプションの一覧です。
 これらのオプションは、
 プリプロセッサがコンパイラから起動されている場合にも
 自動的に引き渡されるので、
 C プログラムをコンパイルする際にも指定することができます。
 .TP
 .B \-P
 `\|\c
 .B #\c
 \&\|'-行番号 
 という行番号情報をプリプロセッサの出力に含めません。
 これは、C 以外の言語で行番号情報が含まれているとエラーを起こす言語を
 処理する場合に有用でしょう。
 .TP
 .B \-C
 コメントを削除せず、そのまま出力ファイルに含めます。
 マクロ呼び出しの引数に現れるコメントはマクロ呼び出しの展開後にコピーされます。
 .TP
 .B -traditional
 ANSI ではなく、旧形式の C の文法として解釈します。
 .TP
 .B -trigraphs
 ANSI標準のトリグラフ(trigraph)構文を処理します。
 これは ANSI C で 1 文字を表示すると定められた `\|\c
 .B ??\c
 \&\|' で始まる 3 文字の並びです。例えば、`\|\c
 .B ??/\c
 \&\|' は `\|\c
 .BR "\e" "\|'"
 を表しますので、`\|\c
 .B '??/n'\c
 \&\|' は改行文字の文字定数となります。
 厳密に言えば、GNU C プリプロセッサの `\|\c
 .B \-trigraphs\c
 \&\|' オプションは ANSI C 標準を完全にはサポートしません。
 が、普通のユーザならばその違いに気づく事は稀でしょう。
 
-トリグラフについで、これ以上知りたいとは思わないでしょ?
+トリグラフについて、これ以上知りたいとは思わないでしょ?
 .TP
 .B \-pedantic
 `\|\c
 .B #else\c
 \&\|' や `\|\c
 .B #endif\c
 \&\|' の後にコメント以外のテキストがつくといった場合に、
 ANSI C 標準で求められる警告を出力します。
 .TP
 .B \-pedantic\-errors
 `\|\c
 .B \-pedantic\c
 \&\|' に似ていますが、警告ではなくエラーにします。
 .TP
 .B \-Wtrigraphs
 トリグラフがあると警告を出力します(ただし、トリグラフの処理は行います)。
 .TP
 .B \-Wcomment
 .TP
 .B \-Wcomments
 コメント開始シーケンスである `\|\c
 .B /*\c
 \&\|' がコメント中に存在したならば警告を発生します
 (両形式は同じ効果を持ちます)。
 .TP
 .B \-Wall
 `\|\c
 .B \-Wtrigraphs\c
 \&\|' と `\|\c
 .B \-Wcomment\c
 \&\|' (ただし
 `\|\c
 .B \-Wtraditional\c
 \&\|' は除く) を指定したのと同じです。
 .TP
 .B \-Wtraditional
 ANSI と伝統派の C とで異なる振る舞いをとる構文が出現した場合に
 警告を発します。
 .TP
 .BI "\-I " directory\c
 \& 
 ディレクトリ \c
 .I directory\c
 \& をヘッダファイルを検索するディレクトリリストの末尾に追加します。
 このオプションは、指定したディレクトリが
 システムのヘッダファイルが格納されているディレクトリよりも先に
 検索されるので、ユーザ自身の作成したバージョンで
 システムが提供するヘッダファイルを上書きさせることもできます。
 1 つ以上の `\|\c
 .B \-I\c
 \&\|' オプションを使用する場合、ディレクトリは左から右の順番で検索され、
 標準のシステムヘッダファイルはその後になります。
 .TP
 .B \-I\-
 `\|\c
 .B \-I\-\c
 \&\|' オプションよりも前に指定された `\|\c
 .B \-I\c
 \&\|' オプションで与えられたディレクトリは、`\|\c
 .B #include \c
 \&"\c
 .I file\c
 \&"\c
 \&\|' のインクルード文の場合にのみ検索されます。`\|\c
 .B #include <\c
 .I file\c
 \&>\c
 \&\|' では検索されません。
 
 オプション `\|\c
 .B \-I\-\c
 \&\|' の後のオプション `\|\c
 .B \-I\c
 \&\|' に追加のディレクトリが指定された場合、それらのディレクトリは
 全ての `\|\c
 .B #include\c
 \&\|' 文で検索されます。
 
 付け加えて言うならば、`\|\c
 .B \-I\-\c
 \&\|' オプションを指定すると、カレントディレクトリは `\|\c
 .B #include \c
 .I \&"file\c
 \&"\c
 \&\|' 文に対する最初の検索ディレクトリではなくなります。
 それゆえ、カレントディレクトリは明示的に `\|\c
 .B \-I.\c
 \&\|' として指定された場合にのみ検索されることになります。
 `\|\c
 .B \-I\-\c
 \&\|' と `\|\c
 .B \-I.\c
 \&\|' を双方とも指定することで、どのディレクトリがカレントディレクトリ
 の前に、あるいは後に検索されるかを厳密に指定することができます。
 .TP
 .B \-nostdinc
 ヘッダファイルの検索に標準システムディレクトリを用いません。`\|\c
 .B \-I\c
 \&\|' オプションで指定したディレクトリ(と、もし適切であるならば
 カレントディレクトリ)が検索されます。
 .TP
 .B \-nostdinc++
 ヘッダファイルの検索に C++ 仕様の標準ディレクトリを用いません。
 が、その他の標準ディレクトリは検索します。
 (このオプションは libg++ の構築時に用いられます。)
 .TP
 .BI "\-D " "name"\c
 \&
 \c
 .I name\c
 \& を既定義のマクロとして、`\|\c
 .B 1\c
 \&\|' に定義します。
 .TP
 .BI "\-D " "name" = definition
 \&
 \c
 .I name\c
 \& をマクロとして\c
 .I definition\c
 \& に定義します。\c
 .I definition\c
 \& の内容に制限はありませが、プリプロセッサをシェルやシェルに類似した
 プログラムから起動している場合、シェルの文法上意味を持つスペース
 などの文字を保護するため、そのシェルのクォート文法を使用する必要が
 あります。もし、1 つの
 .I name\c
 \& に対して複数の `\|\c
 .B \-D\c
 \&\|' を指定したならば、もっとも右側の定義が有効となります。
 .TP
 .BI "\-U " "name"\c
 \&\c
 .I name\c
 \& を定義しません。同一の \c
 .I name\c
 \&  に対して `\|\c
 .B \-U\c
 \&\|' と `\|\c
 .B \-D\c
 \&\|' の双方が指定された場合、`\|\c
 .B \-U\c
 \&\|' が `\|\c
 .B \-D\c
 \&\|' に優先し、 \c
 .I name\c
 \&  は定義されません。
 .TP
 .B \-undef
 非標準のマクロを一切定義しません。
 .TP
 .BI "\-A " "name(" value )
 (\c
 .B #assert\c
 \& コマンドと同じ方法で) 
 述語  \c
 .I name\c
 \& にトークンリスト \c
 .I value\c
 \& をアサートします。シェルのコマンドライン上では括弧を
 エスケープするなりクォートすることを忘れないで下さい。
 
 既定義のアサーション全てを取り消すのに、`\|\c
 .B \-A-\c
 \&\|' を使えます。これはまた、既定義のマクロ全てを無効にします。
 .TP
 .B \-dM
 プリプロセッサの結果を出力する代わりに、
 プリプロセッサの実行中に定義された、既定義のものも含む全てのマクロの
 `\|\c
 .B #define\c
 \&\|' コマンドのリストを出力します。
 これは、使用しているプリプロセッサのそのバージョンで、
 どんなマクロが既定義であるかを知る方法を提供してくれます。
 それには、空のファイル `\|\c
 .B foo.h\c
 \&\|' をこのオプションで処理してみればよいのです。
 .sp
 .br
 touch\ foo.h;\ cpp\ \-dM\ foo.h
 .br
 .sp
 はすべての既定義マクロの値を見せてくれるでしょう。
 .TP
 .B \-dD
 `\|\c
 .B \-dM\c
 \&\|' に似ていますが、2 つの相違点があります。これは既定義マクロを
 出力\c
 .I しません\c
 \&。また、`\|\c
 .B #define\c
 \&\|' コマンドとプリプロセス結果の\c
 .I 双方\c
 \& を出力します。これらの出力は両方とも標準出力に行われます。
 .PP
 .TP
 .BR \-M\  [ \-MG ]
 プリプロセスの結果を出力する代わりに、main のソースファイルの依存性を
 記述する\c
 .B make\c
 \& 規則を出力します。
 プリプロセッサはソースファイルのオブジェクトファイル名、コロン、
 そのすべてのインクルードファイル名から成る\c
 .B make\c
 \& 規則を出力します。複数のインクルードファイルがある場合、規則は`\|\c
 .B \\\\\c
 \&\|'-改行で複数行に区切られます。
 
 `\|\c
 .B \-MG\c
 \&\|' は、見つけられなかったヘッダファイルは(コンパイルの途中で)生成され、
 ソースファイルと同じディレクトリに存在するものとして扱います。`\|\c
 .B \-M\c
 \&\|' と共に指定しなければなりません。
 
 この機能は自動的に Makefile を更新するのに使います。
 .TP
 .BR \-MM\  [ \-MG ]
 これは `\|\c
 .B \-M\c
 \&\|' に似ていますが、`\|\c
 .B #include
 "\c
 .I file\c
 \&"\c
 \&\|' でインクルードされるファイルのみを扱う点が異なります。`\|\c
 .B #include
 <\c
 .I file\c
 \&>\c
 \&\|' でインクルードされるシステムヘッダファイルは無視されます。
 .TP
 .BI \-MD\  file
 これも `\|\c
 .B \-M\c
 \&\|' に似ていますが、依存情報が`\|\c
 .I file\c
 \&\|' に書き出されます。\(em\&`\|\c
 .B \-MD\c
 \&\|' を指定したファイルの処理もこれに加えて行われ、`\|\c
 .B \-M\c
 \&\|' のように通常の処理を抑制することはありません。
 
 gcc を実行する場合は `\|\c
 .I file\c
 \&\|' 引数を指定してはいけません。gcc は、入力ファイル名の末尾の
 `\|\c
 .B .c\c
 \&\|' を `\|\c
 .B .d\c
 \&\|' で置き換えたファイル名を出力に用いるからです。
 
 Mach では、`\|\c
 .B make\c
 \&\|' コマンドで便利なように複数のファイルを 1 つの依存規則ファイルに
 まとめるユーティリティ \c
 .B md\c
 \& が利用できます。
 .TP
 .BI \-MMD\  file
 `\|\c
 .B \-MD\c
 \&\|' に似ていますが、ユーザのヘッダファイルのみを扱い、システムヘッダは
 無視する点が異なります。
 .TP
 .B \-H
 通常の動作に加えて、
 使用されたヘッダファイルのファイル名を出力します。
 .TP
 .BI "\-imacros " "file"\c
 \&
 ファイル  \c
 .I file\c
 \& を入力として処理しますが、
 標準の入力ファイルを処理する前にその結果の出力を破棄します。
 .I file\c
 \& によって生成される出力は捨てられるため、`\|\c
 .B \-imacros \c
 .I file\c
 \&\c
 \&\|' の処理結果の影響は、\c
 .I file\c
 \& 中に記述されたマクロがメインの入力ファイル中で使用可能になることだけです。
 プリプロセッサは、`\|\c
 .B \-imacros\c
 .I file\c
 \&\|' を処理する前に、
 コマンドラインから与えられた全ての `\|\c
 .B \-D\c
 \&\|' や `\|\c
 .B \-U\c
 \&\|' オプションを評価します。
 .TP
 .BI "\-include " "file"\c
 \&
 ファイル  \c
 .I file\c
 \& を、標準の入力ファイルの前に処理し、その結果出力をインクルードします。
 .TP
 .BI "\-idirafter " "dir"
 ディレクトリ \c
 .I dir\c
 \& を第 2 インクルードパスに加えます。第 2 インクルードパス中の
 ディレクトリは、メインインクルードパス (オプション
 `\|\c
 .B \-I\c
 \&\|' によって追加されます) 中にヘッダファイルを探した結果
 発見できなかった場合に検索されます。
 .TP
 .BI "\-iprefix " "prefix"
 \c
 .I prefix\c
 \& を、その後に続く `\|\c
 .B \-iwithprefix\c
 \&\|'
 オプション用のプレフィックスとして使用します。
 .TP
 .BI "\-iwithprefix " "dir"
 ディレクトリを第 2 インクルードパスに追加します。ディレクトリ名は \c
 .I prefix\c
 \& と \c
 .I dir\c
 \& を連結することによって得られます。ここで \c
 .I prefix
 は `\|\c
 .B \-iprefix\c
 \&\|' オプションによって指定されたものです。
 .TP
 .B \-lang-c
 .TP
 .B \-lang-c++
 .TP
 .B \-lang-objc
 .TP
 .B \-lang-objc++
 ソースの言語を指定します。`\|\c
 .B \-lang-c++\c
 \&\|' は、プリプロセッサに C++ のコメント文と、C++ 用の追加の
 デフォルトインクルードディレクトリを処理させ、`\|\c
 .B \-lang-objc\c
 \&\|' は、Objective C の `\|\c
 .B #import\c
 \&\|' ディレクティブを使用可能にします。`\|\c
 .B \-lang-c\c
 \&\|' は明示的にこれらの機能の切り離しを指定し、`\|\c
 .B \-lang-objc++\c
 \&\|' は双方を利用可能にします。
 
 これらのオプションはコンパイラドライバ \c
 .B gcc\c
 \& によって生成されますが、`\|\c
 .B gcc\c
 \&\|' のコマンドラインから引き渡すことはできません。
 .TP
 .B \-lint
 コメント中に埋め込まれた、プログラムチェッカ  \c
 .B lint\c
 \& のコマンドを見つけ出し、それらの前に  `\|\c
 .B #pragma lint\c
 \&\|' を埋め込みます。例えば、コメント  `\|\c
 .B /* NOTREACHED */\c
 \&\|' は `\|\c
 .B #pragma lint
 NOTREACHED\c
 \&\|' になります。
 
 このオプションは直接 \c
 .B cpp\c
 \& を呼び出す場合にのみ使えます。\c
 .B gcc\c
 \& は、コマンドラインからこのオプションを引き渡しません。
 .TP
 .B \-$
 識別子中での `\|\c
 .B $\c
 \&\|' の使用を禁止します。
 これは、標準が修正される以前は、C 標準への厳密な準拠のためにありました。
 
 本オプションは、
 .B cpp
 を直接呼ぶときのみ使用可能です。
 .B gcc
 はコマンド行からこれを渡しません。
 .SH 関連項目
 .B info\c
 \&;
 .I The C Preprocessor\c
 , Richard M. Stallman.
 中のエントリ
 .RB "`\|" cpp "\|'"
 .br
 .BR gcc "(" 1 ");"
 .B info\c
 \&;
 .I 
 Using and Porting GNU CC (for version 2.0)\c
 , Richard M. Stallman.
 中のエントリ
 .RB "`\|" gcc "\|'"
 .SH COPYING
 Copyright (c) 1991, 1992, 1993 Free Software Foundation, Inc.
 .PP
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
 are preserved on all copies.
 .PP
 Permission is granted to copy and distribute modified versions of this
 manual under the conditions for verbatim copying, provided that the
 entire resulting derived work is distributed under the terms of a
 permission notice identical to this one.
 .PP
 Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
 versions, except that this permission notice may be included in
 translations approved by the Free Software Foundation instead of in
 the original English.
diff --git a/ja_JP.eucJP/man/man1/rtprio.1 b/ja_JP.eucJP/man/man1/rtprio.1
index e4954fd7f2..01d1761525 100644
--- a/ja_JP.eucJP/man/man1/rtprio.1
+++ b/ja_JP.eucJP/man/man1/rtprio.1
@@ -1,201 +1,201 @@
 .\"
 .\" Copyright (c) 1994, Henrik Vestergaard Draboel
 .\" All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"	This product includes software developed by Henrik Vestergaard Draboel.
 .\" 4. The name of the author may not be used to endorse or promote products
 .\"    derived from this software without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\" %FreeBSD: src/usr.sbin/rtprio/rtprio.1,v 1.19 2000/03/01 14:07:43 sheldonh Exp %
 .\"
 .\" jpman %Id: rtprio.1,v 1.3 1997/09/23 16:41:42 horikawa Stab %
 .\"
 .Dd July 23, 1994
 .Dt RTPRIO 1
 .Os 
 .Sh 名称
 .Nm rtprio ,
 .Nm idprio
 .Nd リアルタイム/アイドルタイムスケジューリング優先度の実行・確認・修正
 .Sh 書式
 .Nm [id|rt]prio
 .Nm [id|rt]prio 
 .Ar [-]pid
 .Nm [id|rt]prio 
 .Ar priority
 .Ar command
 .Op args
 .Nm [id|rt]prio 
 .Ar priority
 .Ar -pid
 .Nm [id|rt]prio 
 .Fl t
 .Ar command
 .Op args
 .Nm [id|rt]prio 
 .Fl t
 .Ar -pid
 .Sh 解説
 .Nm
 はリアルタイムプロセススケジューリングに使用します。
 .Pp
 .Nm idprio
 はアイドルタイムプロセススケジューリングに使用し、
 .Nm
 と同じオプションにて使用します。
 .Pp
 リアルタイム優先度のプロセスは優先度低下対象とはならず、
 同じもしくはそれ以上のリアルタイム優先度のプロセスのみに横取りされます。
 .Pp
 アイドル優先度のプロセスは、
 実行可能な他のプロセスが存在せず、
 優先度が同じもしくはより高い実行可能なアイドル優先度プロセスが存在しない
 場合のみ実行します。
 .Pp
 .Nm
 と
 .Nm idprio 
 を引数無しで実行すると、現在のプロセスのリアルタイム優先度を表示します。
 .Pp
 .Nm
 を引数 1 つと共に実行すると、指定した
 .Ar pid
 のリアルタイム優先度を返します。
 .Pp
 .Ar priority
 を指定すると、プロセスまたはプログラムをリアルタイム優先度にて実行します。
 .Fl t
 を指定すると、プロセスまたはプログラムを通常のプロセス
 (非リアルタイムプロセス) として実行します。
 .Pp
 .Ar -pid
 を指定すると、
 .Ar pid
 をプロセス識別子として持つプロセスを修正します。
 そうではなく、
 .Ar command 
 を指定すると、プログラムを引数付きで実行します。
 .Pp
-.Ar Priority
+.Ar priority
 は 0 から RTP_PRIO_MAX (通常 31) の整数値です。
 0 は最高の優先度です。
 .Pp
 .Ar pid
 に 0 を指定すると "現在のプロセス" を意味します。
 .Pp
 root のみがリアルタイム優先度およびアイドル優先度を設定可能です。
 .Sh 診断
 .Nm
 がコマンドを実行した場合、このコマンドの終了値が終了値となります。
 その他の場合、
 .Nm
 は成功時には 0 を、エラー時には 1 を終了値とします。
 .Sh 使用例
 現在のプロセスのリアルタイム優先度を見ます:
 .Bd -literal -offset indent -compact
 .Sy "rtprio"
 .Ed
 .Pp
 プロセス
 .Em 1423
 のリアルタイム優先度を見ます:
 .Bd -literal -offset indent -compact
 .Sy "rtprio 1423"
 .Ed
 .Pp
 .Xr cron 8
 を最低のリアルタイム優先度にて実行します:
 .Bd -literal -offset indent -compact
 .Sy "rtprio 31 cron"
 .Ed
 .Pp
 プロセス
 .Em 1423
 のリアルタイム優先度を
 .Em 16
 に変更します:
 .Bd -literal -offset indent -compact
 .Sy "rtprio 16 -1423"
 .Ed
 .Pp
 .Xr tcpdump 1
 を非リアルタイム優先度にて実行します:
 .Bd -literal -offset indent -compact
 .Sy "rtprio -t tcpdump"
 .Ed
 .Pp
 リアルタイム優先度のプロセス
 .Em 1423
 を
 .Dv RTP_PRIO_NORMAL
 (非リアルタイム/通常の優先度) に変更します:
 .Bd -literal -offset indent -compact
 .Sy "rtprio -t -1423"
 .Ed
 .Pp
 他のマシンの使用の邪魔をせずに make depend します:
 .Bd -literal -offset indent -compact
 .Sy "idprio 31 make depend"
 .Ed
 .Sh 関連項目
 .Xr nice 1 ,
 .Xr ps 1 ,
 .Xr rtprio 2 ,
 .Xr setpriority 2 ,
 .Xr nice 3 ,
 .Xr renice 8
 .Sh 歴史
 .Nm
 は
 .Fx 2.0
 から登場しましたが、HP-UX のものに似たバージョンでした。
 .Sh 警告
 CPU を大量消費するプロセスをリアルタイム優先度で実行すると
 システムを操作できなくなります。
 .Sh バグ
 プロセス 0 (swapper) のリアルタイム優先度を設定及び確認する方法は有りません (
 .Xr ps 1
 を参照)。
 .Pp
 .Bx Free
 ではプロセスのページがメモリ中に存在することを保証できないため、
 プロセスがページインのために停止することが有ります (
 .Xr mprotect 2 ,
 .Xr madvise 2
 参照)。
 .Pp
 .Bx Free
 では、今のところシステムコール内で実行権を横取りされることはありません。
 非リアルタイムプロセスが実行中であるために
 リアルタイムプロセスに実行権が割り当てられないことや、
 アイドルプロセスが実行中であるために
 通常優先度プロセスに実行権が割り当てられないことがあります。
 .Sh 作者
 .An Henrik Vestergaard Draboel Aq hvd@terry.ping.dk
 はオリジナルの作者です。
 .An David Greenman
 が
 .Bx Free
 への実装時に、ほとんどを書き直しました。
diff --git a/ja_JP.eucJP/man/man1/tcpdump.1 b/ja_JP.eucJP/man/man1/tcpdump.1
index 917e23ff3d..6175a54ba8 100644
--- a/ja_JP.eucJP/man/man1/tcpdump.1
+++ b/ja_JP.eucJP/man/man1/tcpdump.1
@@ -1,1464 +1,1464 @@
 .\" @(#) %Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.72.2.2 2000/01/29 16:42:03 itojun Exp % (LBL)
 .\"
 .\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
 .\"	The Regents of the University of California.  All rights reserved.
 .\" All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that: (1) source code distributions
 .\" retain the above copyright notice and this paragraph in its entirety, (2)
 .\" distributions including binary code include the above copyright notice and
 .\" this paragraph in its entirety in the documentation or other materials
 .\" provided with the distribution, and (3) all advertising materials mentioning
 .\" features or use of this software display the following acknowledgement:
 .\" ``This product includes software developed by the University of California,
 .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
 .\" the University nor the names of its contributors may be used to endorse
 .\" or promote products derived from this software without specific prior
 .\" written permission.
 .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
 .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 .\"
 .\" %FreeBSD: src/contrib/tcpdump/tcpdump.1,v 1.8 2000/01/30 01:00:55 fenner Exp %
 .\"
 .\" jpman %Id: tcpdump.1,v 1.3 1997/05/23 22:18:59 yugawa Stab %
 .TH TCPDUMP 1  "30 June 1997"
 .SH 名称
-tcpdump \- ネットワーク上のトラフィックデータをダンプします
+tcpdump \- ネットワーク上のトラフィックデータのダンプ
 .SH 書式
 .na
 .B tcpdump
 [
 .B \-adeflnNOpqRStvxX
 ] [
 .B \-c
 .I count
 ] [
 .B \-F
 .I file
 ]
 .br
 .ti +8
 [
 .B \-i
 .I interface
 ]
 [
 .B \-m
 .I module
 ]
 [
 .B \-r
 .I file
 ]
 [
 .B \-s
 .I snaplen
 ]
 .br
 .ti +8
 .br
 .ti +8
 [
 .B \-T
 .I type
 ]
 [
 .B \-w
 .I file
 ]
 .br
 .ti +8
 [
 .I expression
 ]
 .br
 .ad
 .SH 解説
 .LP
 \fItcpdump\fP は、オプションで指定されたネットワークインタフェース上で
 取得可能なパケットのヘッダのうち \fIexpression\fP にマッチするものを出力
 します。
 .LP
 .B SunOS 上の nit ないし bpf の場合:
 .I tcpdump
 を実行するには、
 .I /dev/nit
 ないし
 .IR /dev/bpf*
 への読み込みアクセス権が必要です。
 .B Solaris 上の dlpi の場合:
 .IR /dev/le
 等のネットワーク仮想デバイスへの読み込みアクセス権が必要です。
 .B HP-UX 上の dlpi の場合:
 root か root に setuid されてインストールされている場合のみ実行可能です。
 .B IRIX 上の snoop の場合:
 root か root に setuid されてインストールされている場合のみ実行可能です。
 .B Linux の場合:
 root か root に setuid されてインストールされている場合のみ実行可能です。
 .B Ultrix および Digital UNIX の場合:
 スーパユーザが、
 .IR pfconfig (8)
 を用いて promiscuous-mode での操作を許可していれば、どのユーザも
 .BR tcpdump
 を起動できます。
 .B BSD の場合:
 .IR /dev/bpf*
 への読み込みアクセス権が必要です。
 .SH オプション
 .TP
 .B \-a
 ネットワークアドレスとブロードキャストアドレスを名前に変換しようとします。
 .TP
 .B \-c
 \fIcount\fP で指定した数のパケットを受信した後に終了します。
 .TP
 .B \-d
 解釈されたパケットマッチングコードを読みやすい形に整形した後、
 標準出力にダンプして停止します。
 .TP
 .B \-dd
 .B C
 プログラムの断片の形でパケットマッチングコードをダンプします。
 .TP
 .B \-ddd
 (先頭に個数を付加した) 十進数の形でパケットマッチングコードをダンプします。
 .TP
 .B \-e
 各ダンプ行ごとに、リンクレベルのヘッダを出力します。
 .TP
 .B \-f
 外部ホストの IP アドレスについては、シンボルでなく数値で表示します。
 (本オプションは、Sun の yp サーバに重大な障害が発生するのを回避するこ
 とを意図しています。\(em 通常は、Sun の yp サーバは、ローカルに存在しない
 IP アドレスを永久に変換しつづけてハングします。)
 .TP
 .B \-F
 フィルタの表現として、\fIfile\fP に記述してある内容を用います。
 コマンドラインで指定された追加表現は、無視されます。
 .TP
 .B \-i
 \fIinterface\fP で指定されたインタフェースを監視します。
 指定されない場合には、\fItcpdump\fP はシステムインタフェースリストの中で
 最も小さい番号の稼働中のものを検索し、監視するインタフェースとして設定
 します (ループバックインタフェースは検索しません)。
 この動作は、最初にインタフェースが選択された時点で終了します。
 .TP
 .B \-l
 標準出力を行バッファリングにします。データを捕捉しつつ、
 そのデータを見たい場合には、本オプションは有効です。例えば
 .br
 ``tcpdump\ \ \-l\ \ |\ \ tee dat'' や
 ``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''
 のように使用します。
 .TP
 .B \-n
 アドレス (IP アドレスやポート番号など) を名前に変換しません。
 .TP
 .B \-N
 ホスト名のうち、ドメイン名の表示をしません。例えば、本オプションを
 指定すると、``nic.ddn.mil'' とは表示されず、かわりに ``nic'' とだけ表示し
 ます。
 .TP
 .B \-m
 SMI MIB モジュールの定義を、ファイル \fImodule\fR からロードします。
 複数の MIB モジュールを tcpdump にロードするために、
 本オプションを複数回使用可能です。
 .TP
 .B \-O
 パケットマッチングコードのオプティマイザを動かしません。本オプションは、
 オプティマイザ中のバグを疑う場合にのみ有効なものです。
 .TP
 .B \-p
 ネットワークインタフェースを、promiscuous mode に設定しません。
 ネットワークインタフェースは、何らかの理由により promiscuous mode に設定
 されることもあり得るということに注意してください。ゆえに `-p'
 オプションは、`ether host {local-hw-addr} or ether broadcast'
 の短縮形として使うことは出来ません。
 .TP
 .B \-q
 素早い (静かな?) 出力を行ないます。出力する行を短くするために、通常出力
 されるプロトコル情報の一部は出力されません。
 .TP
 .B \-r
 パケットを、\fIfile\fR で指定したファイル  (-w オプションで作成されます) か
 ら読み込みます。\fIfile\fR として``-''が指定された場合は標準入力が用いら
 れます。
 .TP
 .B \-s
 デフォルトの 68 バイト (SunOS の NIT では最小値は実際には 96) ではなくて、
 \fIsnaplen\fP だけのデータを各パケットから取得します。68 バイトという
 データ長は、IP, ICMP, TCP, UDP のパケットを取得する分には十分ですが、
 ネームサーバや NFS のパケットについてはプロトコル情報が切り詰められるこ
 とがあります (これについては、以後の説明を参照して下さい)。
 スナップショットが限られた量しかとれずに切り
 詰められたパケットは、出力に ``[|\fIproto\fP]'' という文字列がいっしょ
 に表示されます。 \fIproto\fP は、切り詰めが行われたプロトコルレベルの名
 前です。大きなスナップショットをとる場合には、それだけパケット処理の時
 間がかかるということと、パケットバッファリング用のバッファの量が減ると
 いうことに注意してください。これにより、パケットが消失するかもしれませ
 ん。\fIsnaplen\fP の大きさを、必要なプロトコル情報を取得できる最小の値に
 とどめるようにしてください。
 .TP
 .B \-T
 "\fIexpression\fP" により選択されたパケットを強制的に \fItype\fR で
 指定されたタイプと解釈します。有効なタイプは、
 \fBrpc\fR (リモートプロシージャコール)
 \fBrtp\fR (リアルタイムアプリケーションプロトコル)
 \fBrtcp\fR (リアルタイムアプリケーション制御プロトコル)
 \fBsnmp\fR (シンプルネットワークマネージメントプロトコル)
 \fBvat\fR (ビジュアルオーディオツール)
 \fBwb\fR (ディストリビューテッドホワイトボード)
 です。
 .TP
 .B \-R
 ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に基いているものと仮定します。
 指定すると、\fItcpdump\fP はリレー防止フィールドを表示しません。
 ESP/AH 仕様にはプロトコルバージョンフィールドがありませんので、
 \fItcpdump\fP は ESP/AH プロトコルのバージョンを推定できません、
 .TP
 .B \-S
 TCP シーケンス番号を相対番号ではなく、絶対番号で出力します。
 .TP
 .B \-t
 各ダンプ行のタイムスタンプを出力しません。
 .TP
 .B \-tt
 各行毎にタイムスタンプを人間が読みやすい形に変換せずに出力します。
 .TP
 .B \-v
 (少しではありますが) 出力情報を増やします。例えば、IP パケット中の
 TTL や、サービス情報の型を出力します。
 .TP
 .B \-vv
 さらに多くの情報を出力します。例えば、NFS の返答パケットの追加
 フィールドを出力します。
 .TP
 .B \-vvv
 もっと多くの情報を出力します。例えば、telnet \fBSB\fP ... \fBSE\fP
 オプションが完全に表示されます。
 .B \-X
 付きでは、telnet オプションが 16 進数で表示されます。
 .TP
 .B \-w
 受信した生パケットを、解析したり画面に出力したりせずに \fIfile\fR で指定
 したファイルに出力します。本オプションを用いて取得したパケットは \-r
 オプションを用いることで情報を見ることができます。\fIfile\fR で指定す
 るファイル名が ``-'' の場合には、標準出力を用います。
 .TP
 .B \-x
 リンクレベルヘッダを除いた各パケットの内容を 16 進出力します。
 パケットサイズが
 .I snaplen
 バイトより小さい場合にはパケットの全部の内容を、それ以外の場合には、
 .I snaplen
 バイト分のデータをパケットごとに出力します。
 .TP
 .B \-X
 16 進出力時に、ASCII もまた表示します。
 .B \-x
 もまた指定されると、パケットが 16 進数と ASCII の組み合わせで表示されます。
 新規プロトコルを解析するのに非常に便利です。
 .B \-x
 が指定されないと、
 一部のパケットの一部が16 進数と ASCII の組み合わせで表示されます。
 .IP "\fI expression\fP"
 .RS
 ダンプするパケットを選択します。\fIexpression\ が指定されない場合には、
 ネットワーク上のすべてのパケットがダンプ対象になります。それ以外の場
 合には、\fIexpression\fP の条件が真になるパケットのみダンプします。
 .LP
 \fIexpression\fP は、1 つ以上の
 .I プリミティブ
 から成り立ちます。
 プリミティブは通常 1 つ以上の限定子のついた
 .I id
 (名前もしくは番号) から成り立ちます。限定子は、3 種類あります。
 .IP \fI型\fP
 限定子は id 名や番号が参照するものの種類を指します。型には
 .BR host 、
 .B net 、
 .B port 
 があります。例えば、`host foo', `net 128.3', `port 20' のように用います。
 型限定子が指定されない場合には、
 .B host
 が指定されたものとみなされます。
 .IP \fI方向\fP
 限定子は、
 パケットが
 .I id
 へ出ていく方向か、
 .I id
 から来る方向か、
 もしくはその両方かという、特定の転送方向を指定します。
 指定可能な方向は、
 .BR src、
 .BR dst、
 .B "src or dst"、
 .BR "src and dst"
 の 4 つです。
 例えば、`src foo'、 `dst net 128.3'、 `src or dst port ftp-data' のように
 指定します。もし方向限定子が指定されない場合には、
 .B "src or dst"
 が指定されたものとみなします。
 `null' リンクレイヤ
 (つまり、slip などポイント・トゥ・ポイント・プロトコル)
 では、
 必要な方向を指定するのに
 .B inbound
 や
 .B outbound
 限定子を用いる事ができます。
 .IP \fIプロトコル\fP
 限定子は、特定のプロトコルに一致するパケットのみに制限します。
 プロトコルとして指定可能なものは、
 .BR ether,
 .BR fddi,
 .BR ip,
 .BR ip6 ,
 .BR arp,
 .BR rarp,
 .BR decnet,
 .BR lat,
 .BR sca,
 .BR moprc,
 .BR mopdl,
 .BR iso,
 .BR esis,
 .BR isis,
 .BR icmp ,
 .BR icmp6 ,
 .B tcp,
 .BR 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' と同義です。
 .LP
 [`fddi' は実際には `ether' の別名になっています。解析ではこれらを``特定の
 ネットワークインタフェースで使われるデータリンクレベル''を意味するもの
 として同様に扱います。FDDI ヘッダはイーサネットに似た送信元と宛先
 アドレスを含み、そしてしばしばイーサネットに似たパケット型を含むので、
 イーサネットのフィールドと同じように FDDI のフィールドをフィルタリング
 できます。FDDI ヘッダは他のフィールドも含みますが、フィルタ表現の中で
 明示的にそれらを指定することはできません。]
 .LP
 上記に追加して、いくつかの特別な`プリミティブ'キーワードがあります。
 これらのキーワードは
 .BR gateway,
 .BR broadcast,
 .BR less,
 .B greater,
 と算術演算表現
 です。これらの後ろにパターンが続く事はありません。
 プリミティブキーワードについては後述します。
 .LP
 より複雑なフィルタの表現は、プリミティブの結合に
 .BR and,
 .B or,
 .B 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'
 と同じ意味です。
 .LP
 許されるプリミティブは、以下の通りです。
 .IP "\fBdst host \fIhost\fR"
 IPv4/v6 パケットの宛先フィールドが \fIhost\fP で指定したものの場合に、
 真となります。
 \fIhost\fP は、ホスト名もしくは IP アドレスです。
 .IP "\fBsrc host \fIhost\fR"
 IPv4/v6 パケットの送信元フィールドが \fIhost\fP で指定したものの場合に、
 真となります。
 .IP "\fBhost \fIhost\fP
 IPv4/v6 パケットの送信元フィールドもしくは宛先フィールドが 
 \fIhost\fP で指定したものの場合に、
 真となります。
 上記の host プリミティブの表現には、
 \fBip\fP, \fBarp\fP, \fBrarp\fP, \fBip6\fP を
 以下のように付加することが可能です。
 .in +.5i
 .nf
 \fBip host \fIhost\fR
 .fi
 .in -.5i
 という表記は、
 .in +.5i
 .nf
 \fBether proto \fI\\ip\fB and host \fIhost\fR
 .fi
 .in -.5i
 と同じ意味です。
 \fIhost\fR が複数の IP アドレスを持つホスト名であった場合、それぞれのアドレス
 について照合を検査します。
 .IP "\fBether dst \fIehost\fP
 イーサネットパケットの宛先アドレスが \fIehost\fP だった場合に、真となります。
 \fIehost\fP
 は、/etc/ethers に記述された名前もしくはイーサネットアドレスの値が用いられます
 (イーサネットアドレスの形式については、
 .IR ethers (3N)
 を参照)。
 .IP "\fBether src \fIehost\fP
 イーサネットパケットの送信元アドレスが \fIehost\fP だった場合に、真となります。
 .IP "\fBether host \fIehost\fP
 イーサネットパケットの送信元アドレスもしくは宛先アドレスが \fIehost\fP だった
 場合に、真となります。
 .IP "\fBgateway\fP \fIhost\fP
 パケットが \fIhost\fP で指定したアドレスのマシンをゲートウェイとしている場合に
 真となります。言い替えると、送信元もしくは宛先のイーサネットアドレスが
 \fIhost\fP であり、送信元と宛先のどちらの IP アドレスも \fIhost\fP でない
 ということです。
 \fIhost\fP は /etc/hosts ファイルと /etc/ethers の両方で定義されている名前を
 指定する必要があります (等価な表現は、
 .in +.5i
 .nf
 \fBether host \fIehost \fBand not host \fIhost\fR
 .fi
 .in -.5i
 です。この場合 \fIhost / ehost\fP のどちらにも名前もしくは値を用いることが
 可能になります。)
 この構文は、現在のところ、IPv6 が有効な構成では動作しません。
 .IP "\fBdst net \fInet\fR"
 パケットの宛先 IPv4/v6 アドレスが、
 \fInet\fP で指定されたネットワークに属するものである場合に、
 真となります。
 \fInet\fP は、アドレス値もしくは /etc/networks で
 定義されたネットワーク名のいずれかを指定可能です (詳しくは、\fInetworks(4)\fP
 を参照)。
 .IP "\fBsrc net \fInet\fR"
 パケットの送信元 IPv4/v6 アドレスが、
 \fInet\fP で指定されたネットワークに属するものである場合に、真となります。
 .IP "\fBnet \fInet\fR"
 送信元 IPv4/v6 アドレスもしくは宛先 IPv4/v6 アドレスが \fInet\fP で指定された
 ネットワークに属するものである場合に、真となります。
 .IP "\fBnet \fInet\fR \fBmask \fImask\fR"
 IP アドレスが、指定された \fInet\fR および netmask の値で決まる
 ネットワークに属するものである場合に、真となります。
 \fBsrc\fR や \fBdst\fR を指定する事も可能です。
 この構文は IPv6 \fInet\fR では正当でないことに注意してください。
 .IP "\fBnet \fInet\fR/\fIlen\fR"
 IPv4/v6 アドレスが、
 指定された \fInet\fR および \fIlen\fR のビット長のネットマスクで
 決まるネットワークに属するものである場合に、真となります。
 \fBsrc\fR や \fBdst\fR を指定する事も可能です。
 .IP "\fBdst port \fIport\fR"
 パケットが ip/tcp, ip/udp, ip6/tcp, ip6/udp のいずれかであり、宛先
 ポート番号が \fIport\fP の場合に、真となります。
 \fIport\fP で指定されるポート番号は、値もしくは /etc/services で定義
 されているサービス名で指定可能です (
 .IR tcp (4P)
 や
 .IR udp (4P)
 を参照)。
 ポート番号がサービス名にて指定された場合、
 ポート番号とプロトコルの両方がチェック
 対象になります。ポート番号や、あいまいなサービス名が指定された場合には、
 ポート番号のみがチェック対象となります(例えば、\fBdst port 513\fR は、
 tcp/login と udp/who の両方を出力し、\fBport domain\fR は、tcp/domain 
 と udp/domain の両方を出力します)。
 .IP "\fBsrc port \fIport\fR"
 パケットが \fIport\fP で指定した送信元ポート番号を保持している場合に
 真となります。
 .IP "\fBport \fIport\fR"
 パケットの送信元ポート番号もしくは宛先ポート番号が \fIport\fP の場合に、
 真となります。
 上記のポート番号の指定については、すべてキーワード \fBtcp\fP もし
 くは \fBudp\fP を用いて、ある程度候補を絞り込むことが可能です。例えば、
 .in +.5i
 .nf
 \fBtcp src port \fIport\fR
 .fi
 .in -.5i
 と指定した場合には、tcp パケットのみが条件一致の評価対象となります。
 .IP "\fBless \fIlength\fR"
 パケットが \fIlength\fP で指定した長さ以下の場合、真となります。
 これは、
 .in +.5i
 .nf
 \fBlen <= \fIlength\fR
 .fi
 .in -.5i
 の指定と等価です。
 .IP "\fBgreater \fIlength\fR"
 パケットが \fIlength\fP で指定した長さ以上の場合、真となります。
 これは、
 .in +.5i
 .nf
 \fBlen >= \fIlength\fR
 .fi
 .in -.5i
 と等価です。
 .IP "\fBip proto \fIprotocol\fR"
 パケットが \fIprotocol\fP で指定したプロトコル型の IP パケット (
 詳細は
 .IR ip (4P)
 を参照) の場合に、真となります。
 \fIprotocol\fP は、数字もしくは
 \fIicmp\fP, \fIigrp\fP, \fIudp\fP, \fInd\fP, \fItcp\fP
 のいずれかの名前が指定可能です。\fItcp\fP, \fIudp\fP, \fIicmp\fP の
 各識別子はキーワードでもであり、バックスラッシュ (\\)(C-shell では \\\\) を用
 いてエスケープしなければならないことに注意してください。
 このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。
 .IP "\fBip6 proto \fIprotocol\fR"
 パケットがプロトコルタイプ \fIprotocol\fP の IPv6 パケットである場合に、
 真となります。
 このプリミティブはプロトコルヘッダチェーンを追跡しないことに注意してください。
 .IP "\fBip6 protochain \fIprotocol\fR"
 パケットが IPv6 パケットであり、
 プロトコルヘッダチェーン中にタイプ \fIprotocol\fR のプロトコルヘッダが
 含まれるばあい に、真となります。
 例えば
 .in +.5i
 .nf
 \fBip6 protochain 6\fR
 .fi
 .in -.5i
 は、TCP プロトコルヘッダがプロトコルヘッダチェーン中に含まれる
 任意のパケットにマッチします。
 パケット中には、IPv6 ヘッダと TCP ヘッダの間に、
 例えば、認証ヘッダ、ルーティングヘッダ、ホップ毎のオプションヘッダが
 含まれ得ます。
 このプリミティブが出力する BPF コードは、
 複雑であり \fItcpdump\fP 中の BPF 最適化コードでは最適化できません。
 よって、この動作はいくぶん遅いです。
 .IP "\fBip protochain \fIprotocol\fR"
 Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
 .IP "\fBether broadcast\fR"
 パケットがイーサネットブロードキャストパケットの場合に、真となります。
 \fIether\fP キーワードは、省略可能です。
 .IP "\fBip broadcast\fR"
 パケットが IP ブロードキャストパケットの場合に、真となります。オール 1 と
 オール 0 の二つの形式のブロードキャストアドレスを検査し、そして
 ローカルサブネットマスクを調べます。
 .IP "\fBether multicast\fR"
 パケットがイーサネットマルチキャストパケットの場合に、真となります。
 \fIether\fP キーワードは、省略可能です。
 なお、この指定は、`\fBether[0] & 1 != 0\fP' の短縮系です。
 .IP "\fBip multicast\fR"
 パケットが IP マルチキャストパケットの場合に、真となります。
 .IP "\fBip6 multicast\fR"
 パケットが IPv6 マルチキャストパケットの場合に、真となります。
 .IP  "\fBether proto \fIprotocol\fR"
 パケットが \fIprotocol\fR で指定した ether 型の場合に、真になります。
 \fIprotocol\fP は、数字もしくは 
 \fIip\fP, \fIip6\fP, \fIarp\fP, \fIrarp\fP のような
 名前を指定可能です。
 これらの識別子はキーワードでもあり、バックスラッシュ (\\) でエスケープし
 なければならないことに注意してください。
 [FDDI の場合 (例えば `\fBfddi protocol arp\fR')、プロトコルの識別は
 IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。通常これは FDDI
 ヘッダの上の層にあります。\fItcpdump\fP は、プロトコル識別子で
 フィルタリングするときは、すべての FDDI パケットは LLC ヘッダを含み、
 かつその LLC ヘッダがいわゆる SNAP 形式であると仮定します。]
 .IP "\fBdecnet src \fIhost\fR"
 DECNET パケットの送信元アドレスが
 .IR host
 の場合に、真となります。これは ``10.123'' という形式のアドレスでも DECNET の
 ホスト名でも構いません。[DECNET のホスト名は DECNET を動かすように設定され
 た Ultrix システムのみでサポートされます。]
 .IP "\fBdecnet dst \fIhost\fR"
 DECNET パケットの宛先アドレスが
 .IR host
 の場合に、真となります。
 .IP "\fBdecnet host \fIhost\fR"
 DECNET パケットの送信元あるいは宛先アドレスが
 .IR host
 の場合に、真となります。
 .IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBdecnet\fR, \fBiso\fR"
 .in +.5i
 .nf
 \fBip proto \fIp\fR\fB または ip6 proto \fIp\fR
 .fi
 .in -.5i
 の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
 .IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
 .in +.5i
 .nf
 \fBether proto \fIp\fR
 .fi
 .in -.5i
 の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
 \fItcpdump\fP は今のところこれらのプロトコルを解釈できない事に注意して
 ください。
 .IP  "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
 .in +.5i
 .nf
 \fBip proto \fIp\fR
 .fi
 .in -.5i
 の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
 .IP "\fBesis\fR, \fBisis\fR"
 .in +.5i
 .nf
 \fBiso proto \fIp\fR
 .fi
 .in -.5i
 の短縮形です。\fIp\fR の部分には、上記のいずれかのプロトコル名が入ります。
 \fItcpdump\fR はこれらのプロトコルを完全には解釈できない事に注意して
 ください。
 .IP  "\fIexpr relop expr\fR"
 \fIrelop\fRは、>, <, >=, <=, =, != のいずれかであり、\fIexpr\fR の部分に
 は、(標準 C 言語の構文で表現された) 整数定数や通常の二項演算子 [+, -, *, /,
 &, |]、length 演算子、そして特殊なパケットデータへのアクセス演算子などか
 らなる算術表現が入って、その関係が成立する場合に、真となります。
 パケット内部のデータにアクセスするためには、以下の構文を用います。
 .in +.5i
 .nf
 \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
 .fi
 .in -.5i
 \fIproto\fRは、\fBether, fddi, ip, arp, rarp, tcp, udp, icmp, ip6\fR 
 のいずれかであり、インデックス操作を行うプロトコル層を指示
 します。
 \fItcp, udp\fR および他の上位層プロトコルタイプは、
 IPv4 のみに適用され、IPv6 には適用されないことに注意してください
 (これは将来修正されます)。
 指示したプロトコル層からの相対バイトオフセットは、\fIexpr\fR で指定します。
 \fIsize\fR は省略可能で、取得するフィールドのデータ長を表します。
 データ長としては、1,2,4 のいずれかを指定することが可能であり、デフォルトでは
 1 が指定されたものとみなされます。
 キーワード \fBlen\fP で示されるデータ長演算子は、パケット長を与えます。
 
 例えば、`\fBether[0] & 1 != 0\fP' は、全てのマルチキャストパケットを捕捉します。
 `\fBip[0] & 0xf != 5\fP' という表現は、すべてのオプション付きIPパケットを捕捉す
 ることを意味します。`\fBip[6:2] & 0x1fff = 0\fP' という表現は、フラグメントのな
 いデータグラムパケット、もしくはフラグメント化されたデータグラムのうち
 最初のフラグメントを捕捉します。
 この検査は、\fBtcp\fP および \fBudp\fP のインデックス操作においては、暗黙のうち
 に適用されます。
 例えば、\fBtcp[0]\fP は常に TCP ヘッダの先頭バイトを指し、
 決して各フラグメントの先頭バイトを指すものではありません。
 .LP
 プリミティブは、以下のように組み合わせることが可能です。
 .IP
 括弧で括られた一連のプリミティブや演算子
 (括弧はシェルの特殊文字なのでエスケープする必要があります)。
 .IP
 否定 (`\fB!\fP' or `\fBnot\fP').
 .IP
 論理積 (`\fB&&\fP' or `\fBand\fP').
 .IP
 論理和 (`\fB||\fP' or `\fBor\fP').
 .LP
 否定は、最も高い演算優先度を持ちます。論理和と論理積は、同じ演算優先度を持ち、
 左から右へ評価されます。論理積の場合には、単に識別子を並べるのではなく、
 明示的に \fBand\fR を使用しなければならないことに注意して下さい。
 .LP
 キーワードなしで識別子が与えられている場合には、最も最近用いられたキーワードが
 付加されているものと仮定されます。
 例えば、
 .in +.5i
 .nf
 \fBnot host vs and ace\fR
 .fi
 .in -.5i
 は、
 .in +.5i
 .nf
 \fBnot host vs and host ace\fR
 .fi
 .in -.5i
 の短縮形ですが、
 .in +.5i
 .nf
 \fBnot ( host vs or ace )\fR
 .fi
 .in -.5i
 と混同してしまいがちなので気をつけましょう。
 .LP
 引数 expression は、単一の引数としても複数の引数としても、どちらか便利な
 方で、tcpdump に渡すことができます。
 一般的に、引数がシェルのメタキャラクタを含む場合、その引数をクォート
 された単一の引数としてプログラムに渡す方が容易です。
 複数の引数は、解析される前にスペースで連結されます。
 .SH 使用例
 .LP
 \fIsundown\fP に到達する、もしくはそこから送信されるパケットのすべてを
 表示する場合には、以下のように実行します。
 .RS
 .nf
 \fBtcpdump host sundown\fP
 .fi
 .RE
 .LP
 \fIhelios\fR と、\fIhot\fR もしくは \fIace\fR の間のトラフィックを表示する
 場合には、以下のように実行します。
 .RS
 .nf
 \fBtcpdump host helios and \\( hot or ace \\)\fP
 .fi
 .RE
 .LP
 \fIace\fR と、\fIhelios\fR 以外のホストとの間でやりとりされるすべての
 IP パケットを表示する場合には、以下のように実行します。
 .RS
 .nf
 \fBtcpdump ip host ace and not helios\fP
 .fi
 .RE
 .LP
 ローカルなホストと Berkeley のホストとの間でやりとりされるすべての
 トラフィックを表示する場合には、以下のように実行します。
 .RS
 .nf
 .B
 tcpdump net ucb-ether
 .fi
 .RE
 .LP
 インターネットゲートウェイ \fIsnup\fP を通過するすべての ftp
 トラフィックを表示する場合には、以下のように実行します
 (シェルが括弧を誤って解釈しないよう、フィルタを表現する引数がクォートさ
 れていることに注意して下さい)。
 .RS
 .nf
 .B
 tcpdump 'gateway snup and (port ftp or ftp-data)'
 .fi
 .RE
 .LP
 送信元アドレスと宛先アドレスの両方がローカルネットワーク内のホスト
 のものでないトラフィックについて表示する場合には、以下のように実行しま
 す
 (実行するホストが他のネットワークに対するゲートウェイの場合、そのホスト
 が属すローカルネットワークでは、このコマンドは成功しないでしょう)。
 .RS
 .nf
 .B
 tcpdump ip and not net \fIlocalnet\fP
 .fi
 .RE
 .LP
 ローカルネットワーク外のホストとの通信において、TCP による各通信単位
 のスタートパケットとエンドパケット (SYN と FIN パケット) を表示するには、以
 下のように実行します。
 .RS
 .nf
 .B
 tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
 .fi
 .RE
 .LP
 ゲートウェイ \fIsnup\fP を中継される IP パケットのうち、576 バイトより大きいもの
 を表示するには、以下のように実行します。
 .RS
 .nf
 .B
 tcpdump 'gateway snup and ip[2:2] > 576'
 .fi
 .RE
 .LP
 イーサネット上でブロードキャストもしくはマルチキャストを経由して送られる
 もの以外の IP ブロードキャストもしくはマルチキャストパケットを表示するには、
 以下のように実行します。
 .RS
 .nf
 .B
 tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
 .fi
 .RE
 .LP
 echo 要求/応答以外 (つまり ping パケット以外) の全ての ICMP パケットを
 表示するには、以下のように実行します。
 .RS
 .nf
 .B
 tcpdump 'icmp[0] != 8 and icmp[0] != 0'
 .fi
 .RE
 .SH 出力形式
 .LP
 \fItcpdump\fP の出力は、プロトコル依存です。以下の説明では、簡単な
 パラメータの記述と、おおよそのフォーマットの説明を行ないます。
 .de HD
 .sp 1.5
 .B
 ..
 .HD
 リンクレベルヘッダ
 .LP
 もし '-e' オプションが指定されると、リンクレベルヘッダが出力されます。
 イーサネットにおいては、送信元と宛先のアドレス、プロトコル、そして
 パケット長が出力されます。
 .LP
 FDDI ネットワークにおいては、'-e' オプションが指定されると \fItcpdump\fP
 は、`フレーム制御'フィールド、発信元と宛先アドレス、そしてパケット長を
 出力します。`フレーム制御'フィールドはパケットの残りの部分の解釈を決定
 します。(IP データグラムを含むような) 通常のパケットは `async' パケットで、
 0 から 7 の間の優先順位を持ちます。例えば、`\fBasync4\fR' です。こうした
 パケットは IEEE802.2 の論理リンク制御 (LLC) パケットを含むと仮定されます。
 LLC ヘッダは、それが ISO データグラムでない場合やいわゆる SNAP パケットのと
 きには出力されます。
 .LP
 \fI (注意:以下の記述は、利用者が RFC1144 に記述されている SLIP 圧縮
 アルゴリズムについての知識がある前提で書いています。)\fP
 .LP
 SLIP によるリンクにおいては、方向指示子 (``I'' が入力方向、``O''
 が出力方向)、パケット型、そして圧縮情報が出力されます。
 パケット型は、最初に出力されます。パケット型には \fIip\fP、\fIutcp\fP、そして
 \fIctcp\fP の 3 つがあります。
 \fIip\fR 型パケットの場合、上記以上のリンク情報は表示されません。
 TCP パケットの場合には、コネクション識別子がパケット型に続いて出力されます。
 パケットが圧縮されている場合、符号化されたヘッダが出力されます。
 特殊な場合は \fB*S+\fIn\fR や \fB*SA+\fIn\fR のように出力されます。ここ
 で \fIn\fR は、シーケンス番号 (もしくはシーケンス番号および ack) が変更された回
 数です。特殊な場合でなければ、0 回以上の変更について出力されます。
 変更は、U (緊急 (urgent) ポインタ)、W (ウィンドウ)、A (ack)、S (シーケンス番号)、
 そして I (パケット ID) で示され、変動量 (+n or -n)
 もしくは新しい値 (=n) が続きます。
 最後に、パケット内のデータの総量および圧縮ヘッダ長が出力されます。
 .LP
 例えば、以下の行は、出力方向の圧縮 TCP パケットを、暗黙のコネクション識別子
 とともに表示しています。ack は 6 変わり、シーケンス番号は 49 変わり、パケット
 ID は 6 変わっています。3 バイトのデータと6 バイトの圧縮ヘッダが存在します。
 .RS
 .nf
 \fBO ctcp * A+6 S+49 I+6 3 (6)\fP
 .fi
 .RE
 .HD
 ARP/RARP パケット
 .LP
 arp/rarp パケットの出力は、要求型とその引数を示してい
 ます。出力形式は、その出力のみで理解可能なように作られています。
 以下に、ホスト \fIrtsg\fP からホスト \fIcsam\fP への `rlogin' 開始時の
 パケットの実例を示します。
 .RS
 .nf
 .sp .5
 \f(CWarp who-has csam tell rtsg
 arp reply csam is-at CSAM\fP
 .sp .5
 .fi
 .RE
 1行目は、ホスト rtsg が、ホスト csam のイーサネットアドレスを問い合わせる
 目的で arp パケットを送信していることを意味します。ホスト csam は、自分自身
 のイーサネットアドレスを返答しています (この例では、イーサネットアドレス
 は大文字で、インターネットアドレス部は小文字で表記しています)。
 .LP
 \fBtcpdump \-n\fP として起動した場合には、少し冗長になります。
 .RS
 .nf
 .sp .5
 \f(CWarp 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\fP
 .fi
 .RE
 .LP
 \fBtcpdump \-e\fP として起動した場合には、最初のパケットはブロードキャスト
 パケットであり、次のパケットはポイントツーポイントのパケットであることが
 わかります。
 .RS
 .nf
 .sp .5
 \f(CWRTSG Broadcast 0806  64: arp who-has csam tell rtsg
 CSAM RTSG 0806  64: arp reply csam is-at CSAM\fP
 .sp .5
 .fi
 .RE
 最初のパケットについては、送信元のイーサネットアドレスは RTSG であり、
 宛先はイーサネットブロードキャストアドレス、型フィールドには 16 進数の値
 0806 (ETHER_ARP を意味します) が格納されており、総パケット長は 64 バイトである
 と表示しています。
 .HD
 TCP パケット
 .LP
 \fI(注意:以下の記述は、RFC793 に記述されている TCP プロトコルについての知識
 があることを前提に記述されています。この知識がない場合、本記述と tcpdump の
 いずれもあなたには役に立たないでしょう。)\fP
 .LP
 TCP プロトコル行の一般的な形式は、以下の通りです。
 .RS
 .nf
 .sp .5
 \fIsrc > dst: flags data-seqno ack window urgent options\fP
 .sp .5
 .fi
 .RE
 \fIsrc\fP と \fIdst\fP は、それぞれ送信元と宛先の IP アドレスと
 ポート番号です。\fIflags\fP の部分には、S (SYN), F (FIN), P (PUSH), R (RST)
 の組み合わせ、もしくは単なる `.' (フラグなし) が入ります。
 \fIdata-seqno\fP は、このパケット内のデータがシーケンス空間のどの部分に
 あたるかを示します (以下の例を参照して下さい)。
 \fIack\fP は、本コネクション上を逆方向に次に流れるデータパケットの
 シーケンス番号です。
 \fIwindow\fP は、本コネクションの逆方向のパケットを格納するバッファサイズ
 です。
 \fIurg\fP は、パケット中に `urgent' (緊急) データが格納されていることを示しま
 す。
 \fIoptions\fP は、例えば <mss 1024> のように、アングルブラケット (大小記号) で
 括られた tcp オプションです。
 .LP
 \fIsrc、dst\fP、そして \fIflags\fP は、常に表示されます。他のフィールドは、
 パケットの TCP ヘッダに依存し、表示できる場合だけ表示されます。
 .LP
 以下の例は、ホスト \fIrtsg\fP からホスト \fIcsam\fP への rlogin
 開設時のシーケンスの一部です。
 .RS
 .nf
 .sp .5
 \s-2\f(CWrtsg.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\fP\s+2
 .sp .5
 .fi
 .RE
 最初の行は、ホスト rtsg の TCP ポート 1023 番からホスト csam の \fIlogin\fP
 ポートに対してパケットを送信していることを意味します。\fBS\fP は、
 パケットの \fISYN\fP フラグが設定されていることを意味します。
 パケットのシーケンス番号は 768512 番であり、データは含みません。
 (表記は `first:last(nbytes)' であり、これは`シーケンス番号 \fIfirst\fP か
 ら \fIlast\fP までの \fIlast\fP を含まない \fInbytes\fP のユーザデータという
 こと'を意味しています。)
 このパケット中に ack はなく、有効な受信ウィンドウの大きさは 4096 バイトで
 あり、1024 バイトの最大セグメントサイズ要求を行なうオプションが付加され
 ています。
 .LP
 csam は、rtsg から送られたパケットと類似したパケットを送り返しますが、
 rtsg の送った SYN に対する ack が含まれるところが異なり
 ます。続いて、rtsg は csam の SYN に対する ack を返します。
 `.' は、S (SYN), F (FIN), P (PUSH), R (RST) のいずれのフラグも
 立っていないことを意味します。
 パケットはデータを含まないため、データシーケンス番号は入りません。
 ack シーケンス番号が小さい整数 (1) であることに注意して下さい。
 \fBtcpdump\fP は、初めて TCP の`通信'を検出すると、パケットから取得した
 シーケンス番号を表示します。通信のその後のパケットについては、現在の
 パケットシーケンス番号と、この最初のシーケンス番号の間の差を表示します。
 このことは、最初に取得した以降のシーケンス番号は、通信データストリーム
 の相対位置として解釈できることを意味します (最初の各方向のデータバイト
 は 1 です)。`-S' は、本機能を無効にし、元のシーケンス番号を表示します。
 .LP
 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 バイトデータを送信しています。
 .LP
 スナップショットが小さ過ぎて \fBtcpdump\fP が 
 TCP ヘッダ全体を捕えなかった場合、
 可能な限りのヘッダを解釈し、``[|\fItcp\fP]'' を表示して
 残りを解釈できなかったことを示します。
 (短か過ぎるまたはヘッダを越えてしまうといった) 不正なオプションを
 ヘッダが持つ場合には、tcpdump は ``[\fIbad opt\fP]'' を表示して
 残りのオプションを解釈しません (どこから開始したら良いのか分からないからです)。
 ヘッダ長によりオプションが存在することが分かるが、
 IP データグラム長がオプションがそこにあるために十分な長さではない場合に、
 tcpdump は ``[\fIbad hdr length\fP]'' を表示します。
 .HD
 .B
 UDP パケット
 .LP
 UDP フォーマットは、以下の rwho パケットで例示します。
 .RS
 .nf
 .sp .5
 \f(CWactinide.who > broadcast.who: udp 84\fP
 .sp .5
 .fi
 .RE
 これは、ホスト \fIactinide\fP の \fIwho\fP ポートが UDP データグラムを
 インターネットブロードキャストアドレスであるホスト \fIbroadcast\fP の
 \fIwho\fP ポートに対して送信していることを意味します。本パケットは、
 84 バイトのユーザデータを含みます。
 .LP
 いくつかの UDP サービスは(送信元もしくは宛先のポート番号から)種
 類の判断が可能で、さらに上位レベルのプロトコル情報が出力されます。
 ドメインネームサービス要求 (RFC1034/1035)、そして、Sun RPC 呼びだし
 (RFC1050) を用いた NFS サービスなどがこの条件に該当します。
 .HD
 UDP ネームサーバ要求
 .LP
 \fI(注意:以下の記述は、RFC1035 に記述されている
 ドメインサービスプロトコルの知識があることを前提に書かれています。もしこ
 れらの知識がない場合には、以下の記述は未知の言語で書かれているかのよう
 に見えるでしょう。)\fP
 .LP
 ネームサーバ要求は、以下のような表示になります。
 .RS
 .nf
 .sp .5
 \fIsrc > dst: id op? flags qtype qclass name (len)\fP
 .sp .5
 \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP
 .sp .5
 .fi
 .RE
 ホスト \fIh2opolo\fP は、\fIhelios\fP 上のドメインサーバに対して
 \fIucbvax.berkeley.edu\fP のホスト名に対応するアドレスレコード (qtype=A)
 を問い合わせています。
 問い合わせの ID は `3' であり、`+' は\fI再帰要求\fPフラグが設定されて
 いることを意味します。問い合わせの長さは 37 バイトであり、この中に UDP および
 IP のプロトコルヘッダの長さは含みません。質問操作は普通の操作 (\fIQuery\fP)
 であり、op フィールドは省略されます。op が他のいずれかであった場合、
 その op は `3' と `+' の間に表示されます。
 これと同様に、qclass は普通のもの (\fIC_IN\fP) であり、省略されます。
 他の qclass が入った場合、`A' の直後に表示されます。
 .LP
 少数の変則的なパケットは検査され、カギカッコで囲まれた付加
 フィールドにその結果が表示されます。query が返答、ネームサーバ
 もしくはオーソリティセクションを含む場合、
 .IR ancount ,
 .IR nscount ,
 もしくは
 .I arcount
 が、`[\fIn\fPa]'、 `[\fIn\fPn]' 、もしくは `[\fIn\fPau]' のような形式で
 表示されます。\fIn\fP は、それぞれの個数です。
 応答ビットのいずれかが設定されている (AA, RA, rcode のいずれか) 場合、
 もしくは`0 でなければならない'ビットが 2 バイト目と 3 バイト目に設定されてい
 る場合には、`[b2&3=\fIx\fP]' が出力されます。\fIx\fP は、ヘッダの 2 バイト
 目および 3 バイト目の値を 16 進で表したものです。
 .HD
 UDP ネームサーバ応答
 .LP
 ネームサーバ応答の形式は、以下の通りです。
 .RS
 .nf
 .sp .5
 \fIsrc > dst:  id op rcode flags a/n/au type class data (len)\fP
 .sp .5
 \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
 helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP
 .sp .5
 .fi
 .RE
 最初の例は、\fIh2opolo\fP からの質問 ID 3 の要求に対し、\fIhelios\fP が
 3 つのアンサーレコード、3 つのネームサーバレコード、そして 7 つの
 オーソリティレコードを持っているパケットで返答しているというものです。
 最初のアンサーレコードは、タイプ A (アドレス) であり、そのデータは
 IP アドレス 128.32.137.3 です。UDP と IP のヘッダを除いた総サイズは
 273 バイトです。
 A レコードのクラス (C_IN) と同様に, op (Query) および応答コード
 (NoError) は、省略されます。
 .LP
 2 つめの例は、\fIhelios\fP が質問 ID 2 の要求に対し、存在しない
 ドメイン (NXDomain) という返答コードとともに、0 個のアンサーレコード、1 つ
 のネームサーバレコード、そして 0 個のオーソリティレコードを含んだ
 レスポンスを返しています。`*' は、\fIauthoritative answer\fP ビットが設定され
 ていることを示します。
 アンサーレコードがないため、型、クラス、データは出力されません。
 .LP
 出力される可能性のある他のフラグキャラクタは、`\-' (再帰利用,RA,が 
 設定されていない)および `|' (メッセージ切捨て, TC, が設定されている) です。
 `question' セクションに含まれるエントリがちょうど 1 つでない場合には、
 `[\fIn\fPq]' が出力されます。
 .LP
 ネームサーバ要求および応答は、大きくなる傾向にあり、デフォルトの
 \fIsnaplen\fP の値である 68 バイトの長さは、パケットを捕捉してその内容を
 表示するには十分でないかも知れないことに注意して下さい。
 もしネームサーバトラフィックの調査を真剣に
 行なおうとするならば、\fB\-s\fP オプションを用いて、\fIsnaplen\fP を増やし
 て下さい。自分の経験上、`\fB\-s 128\fP' で十分使い物になります。
 
 .HD
 SMB/CIFS のデコード
 .LP
 現在の 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) が書きました。
 
 .HD
 NFS 要求と応答
 .LP
 Sun NFS (Network File System) 要求および応答は、以下のように
 表示されます。
 .RS
 .nf
 .sp .5
 \fIsrc.xid > dst.nfs: len op args\fP
 \fIsrc.nfs > dst.xid: reply stat len op results\fP
 .sp .5
 \f(CW
 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
 \fP
 .sp .5
 .fi
 .RE
 最初の行では、ホスト \fIsushi\fP が ID\fI6709\fP のトランザクションを
 \fIwrl\fP に送信します (送信元ホストに続く数字はトランザクション ID
 であり、送信元ポート番号で\fIない\fPことに注意して下さい)。要求
 サイズは、UDP および IP ヘッダのサイズを除いて 112 バイトです。操作は、
 ファイルハンドル (\fIfh\fP) 21,24/10.731657119 に対する \fIreadlink\fP
 (シンボリックリンク読み込み) です。
 (この例のように運が良ければ、ファイルハンドルはデバイスのメジャー、
 マイナー番号のペアと、それに続く i ノード番号と世代番号と解釈することがで
 きます。)
 \fIwrl\fP はリンクの内容とともに `ok' と返答しています。
 .LP
 3 行めでは、\fIsushi\fP は \fIwrl\fP に対し、ファイルハンドル
 9,74/4096.6878 のディレクトリ中の `xcolors' ファイルの検索を要求していま
 す。出力されたデータは、操作の型に依存することに注意して下さい。本形式
 は、NFS のプロトコル仕様とともに読めば、それ自身を見れば分かるよう
 に意図して作成されています。
 .LP
 \-v (verbose, 冗長) フラグがある場合、追加情報が出力されます。
 例えば
 .RS
 .nf
 .sp .5
 \f(CW
 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
 \fP
 .sp .5
 .fi
 .RE
 (\-v は IP ヘッダの TTL, ID, そしてフラグメンテーションフィールドも出力し
 ますが、この例では省略しています。) 最初の行では、\fIsushi\fP は 
 \fIwrl\fP に対してファイル 21,11/12.195 のオフセット 24576 バイト目か
 ら 8192 バイトを読むように要求しています。\fIwrl\fP は `ok' と返答してい
 ます。2 行めに示したパケットは応答の最初のフラグメントなので、1472 
 バイトしかありません (その他のデータは継続するフラグメント中に続きます
 が、これらのフラグメントは NFS ヘッダも UDP ヘッダさえも持たないので、使わ
 れるフィルタリングの表現によっては出力されないでしょう)。\-v フラグがあ
 るのでいくつかのファイル属性 (ファイルデータに追加されて返されてくる) が
 出力されます。それらはファイルの型 (普通のファイルなら``REG'')、(8 進数
 表現の) ファイルモード、uid と gid、そしてファイルの大きさです。
 .LP
 \-v フラグが 2 回以上指定されると、さらに詳しい情報が出力されます。
 .LP
 NFS 要求は非常に大きなデータになるため、\fIsnaplen\fP を大きくし
 ないと詳しい出力は得られません。NFS トラフィックを監視するには、
 `\fB\-s 192\fP' と指定してみて下さい。
 .LP
 NFS 応答パケットは RPC 操作であることを明示的には示しません。その代わ
 り、\fItcpdump\fP は``最近の''要求を追跡して、トランザクション ID を用い
 て応答と照合します。応答が対応する要求のすぐ後に続かないと、解
 析することはできません。
 .HD
 AFS の要求と応答
 .LP
 Transarc AFS (Andrew File System) の要求と応答は次のように表示されます:
 .HD
 .RS
 .nf
 .sp .5
 \fIsrc.sport > dst.dport: rx packet-type\fP
 \fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
 \fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
 .sp .5
 \f(CW
 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
 \fP
 .sp .5
 .fi
 .RE
 最初の行では、ホスト elvis が RX パケットを pike に送っています。
 これは、fs (ファイルサーバ) サービスへの RX データパケットであり、
 RPC 呼び出しの開始です。
 この RPC 呼び出しはリネーム (改名) であり、
 古いディレクトリファイル ID 536876964/1/1 と古いファイル名 `.newsrc.new'、
 新しいディレクトリファイル ID 536876964/1/1 と新しいファイル名 `.newsrc' で
 呼び出しています。
 ホスト pike は、RPC 応答をリネーム呼び出しに対して返します
 (データパケットであり、アボートパケットではないため、これは成功しました)。
 .LP
 一般的には、AFS RPC の RPC 呼び出し名だけは最低限デコードされます。
 ほとんどの AFS RPC は、少ななくともいくらかの引数がデコードされます
 (一般的には「興味のある」引数のみであり、興味についてはある定義によります)。
 .LP
 書式は、自明となることを意図していますが、
 AFS および RX の動作に親しみのない方々にとっては有用ではないかもしれません。
 .LP
 -v (冗長) フラグを 2 度指定すると、追加情報を表示します。
 これは、RX 呼び出し ID、呼び出し番号、シーケンス番号、
 シリアル番号、RX パケットフラグといったものです。
 .LP
 更にもう 1 回 -v フラグを指定すると、
 セキュリティインデックスとサービス ID を表示します。
 .LP
 アボートパケットに対しては、エラーコードが表示されます。
 ただし、Ubik ビーコンパケットは例外です
 (Ubik プロトコルでは、アボートパケットは、肯定投票に使用されるからです)。
 .LP
 AFS 要求は非常に大きく、
 \fIsnaplen\fP を増やさなければ多くの引数が表示されないことに注意してください。
 AFS トラフィックを見るには `\fB-s 256\fP' を試してみてください。
 .LP
 AFS 応答パケットは、明示的には RPC 操作を識別しません。
 代りに \fItcpdump\fP が「最近の」要求の追跡を行い、
 応答に対応する要求のマッチングを、
 呼び出し番号とサービス ID を使用して行います。
 応答パケットが対応する要求パケットに近くないと、
 パーズできないかもしれません。
 
 .HD
 KIP Appletalk (DDP in UDP)
 .LP
 UDP データグラムでカプセル化された Appletalk DDP パケットは、カプセル化
 を解かれ、DDP パケットとしてダンプされます (全ての UDP ヘッダ情報は破棄
 されます)。
 ファイル
 .I /etc/atalk.names
 が、Appletalk ネットワークおよびノード番号を名前に変換するのに用い
 られます。
 本ファイルの内容は、以下のように記述されます。
 .RS
 .nf
 .sp .5
 \fInumber	name\fP
 
 \f(CW1.254		ether
 16.1		icsd-net
 1.254.110	ace\fP
 .sp .5
 .fi
 .RE
 最初の 2 行は、Appletalk ネットワーク名を決めています。3 行めは、
 特定のホストの名前を決めています (ホストは、3 オクテット目の有無で
 ネットワークと区別されます。ネットワーク番号は、2 オクテットの数字
 から、ホスト番号は 3 オクテットの数字から構成される必要があります。)
 数字と名前は、空白文字もしくはタブ文字で区切られます。この
 .I /etc/atalk.names
 ファイルは、空行もしくは、`#' 文字で始まるコメント行を含んでもかま
 いません。
 .LP
 Appletalk アドレスは、以下のように表示されます。
 .RS
 .nf
 .sp .5
 \fInet.host.port\fP
 
 \f(CW144.1.209.2 > icsd-net.112.220
 office.2 > icsd-net.112.220
 jssmag.149.235 > icsd-net.2\fP
 .sp .5
 .fi
 .RE
 (もし、この
 .I /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 では
 ノード名とネットワーク名を区別する方がよいことが分かります)。
 .LP
 NBP (name binding protocol) および ATP (Appletalk transaction protocol)
 パケットでは、その内容は解釈されます。
 他のプロトコルは、プロトコル名 (もしくは、プロトコルが登録されていない場
 合には、プロトコル番号) およびパケットサイズをダンプします。
 
 \fBNBP パケット\fP は、以下のような形式で表示されます。
 .RS
 .nf
 .sp .5
 \s-2\f(CWicsd-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\fP\s+2
 .sp .5
 .fi
 .RE
 最初の行は、レーザライタの名前検索要求であり、ネットワーク icsd のホスト
 112 から送られ、ネットワーク jssmag へとブロードキャストされています。
 検索のための nbp の ID は 190 です。
 次の行は jssmag.209 からの、この要求の応答 (同じ ID を持つことに注意して下さ
 い) で、 ポート 250 に登録された RM1140 という名前のレーザライタがあると答
 えています。
 3 行めは、同じ要求に対する他のホストからの応答で、
 ホスト techpit が、ポート 186 に登録されたレーザライタ "techpit" を持ってい
 ると答えています。
 
 \fBATP パケット\fP の形式は、以下のように表示されます。
 .RS
 .nf
 .sp .5
 \s-2\f(CWjssmag.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\fP\s+2
 .sp .5
 .fi
 .RE
 jssmag.209 は、ホスト helios に対し最大8個 ('<0-7>') までのパケットを
 要求することで、トランザクション ID 12266 を開始します。行の最後の 16 進数は、
 要求の中の`ユーザデータ'のフィールドの値です。
 .LP
 helios は、8 つの 512 バイトのパケットで応答しています。トランザクション ID
 の後につづく`:数'は、パケットシーケンス番号を、括弧中の数値は ATP ヘッダ
 を除いたパケット中のデータ量を示しています。パケットシーケンス 7 のところ
 の `*' は、EOM ビットが設定されていることを示しています。
 .LP
 jssmag.209 は、パケットシーケンス番号 3 と 5 のパケットの再送要求をしています。
 helios はそれらを再送し、その後 jssmag.209 はトランザクションを解放します。
 最後の行で、jssmag.209 は次の要求を開始します。この要求の表示
 で付加されている `*' は、XO (`exactly once') が設定されていないことを示します。
 
 .HD
 IP フラグメンテーション
 .LP
 フラグメントのあるインターネットデータグラムは、以下のように表示されます。
 .RS
 .nf
 .sp .5
 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
 .sp .5
 .fi
 .RE
 (最初の形式では、まだフラグメントがあることを示し、2 番めの形式は、
 これが最後のフラグメントであることを示しています。)
 .LP
-\fIId\fP は、フラグメント ID です。\fIsize\fP は、フラグメントサイズを
+\fIid\fP は、フラグメント ID です。\fIsize\fP は、フラグメントサイズを
 バイト単位であらわしたものです。ただし IP ヘッダサイズは含みません。
 \fIoffset\fP は、元のデータグラムでの本フラグメントのオフセットをバイト
 単位であらわしたものです。
 .LP
 フラグメント情報は、各フラグメントごとに表示されます。最初の
 フラグメントには、上位レベルのプロトコルヘッダが含まれるので、フラグ情
 報がプロトコル情報の後に表示されます。2 つ目以降のフラグメントについて
 は、上位レベルのプロトコルヘッダを含まないので、フラグ情報は送信元およ
 び宛先アドレスの後ろに表示されます。
 例えば、これは arizona.edu から lbl-rtsg.arpa への CSNET 接続での ftp 
-の様子の一部分ですが、どうやら 576 バイト以上ののデータグラムを扱えないよ
+の様子の一部分ですが、どうやら 576 バイト以上のデータグラムを扱えないよ
 うです。
 .RS
 .nf
 .sp .5
 \s-2\f(CWarizona.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\fP\s+2
 .sp .5
 .fi
 .RE
 注意すべきことがいくつかあります。まず最初に、2 行目は
 ポート番号を含みません。これは、TCP プロトコル情報は、最初のフラグメント
 に全て入っており、後のフラグメントを出力する時にはポート番号やシーケンス
 番号を知る術がないからです。
 次に、最初の行の TCP シーケンス情報は、パケットが 308 バイトのユーザデータ
 を持ってるかのように表示されますが、実際には 512 バイトのユーザデータを
 持っています (308 バイトが最初のフラグ分で、204 バイトが 2 番目のフラグ分で
 す)。シーケンススペースの穴をさがしたり、パケットの ack の対応が正しい
 かをこのデータで見ようとしてはいけません。
 .LP
 フラグメント不可フラグが設定されたパケットは、最後の部分に \fB(DF)\fP と
 印が付けられます。
 .HD
 タイムスタンプ
 .LP
 デフォルトでは、すべての出力行は最初にタイムスタンプが出力されます。
 タイムスタンプは、以下の形式で、現在のクロックタイムを表示します
 .RS
 .nf
 \fIhh:mm:ss.frac\fP
 .fi
 .RE
 そして、クロックの精度は、カーネルクロックの精度に依存します。
 タイムスタンプは、カーネルが最初にパケットを見つけた時間を反映します。
 イーサネットインタフェースがケーブルからパケットを取り出してカーネルが
 `新規パケット'割り込みを受け付けるまでのタイムラグなどは補正されません
 .SH 関連項目
 bpf(4), pcap(3)
 .SH 作者
 Van Jacobson,
 Craig Leres and
 Steven McCanne, all of the
 Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
 .LP
 .RS
 .I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
 .RE
 .LP
 IPv6/IPsec サポートは WIDE/KAME プロジェクトが追加しました。
 本プログラムは、特定の構成においては、
 Eric Young の SSLeay ライブラリを使用します。
 .SH バグ
 バグレポートは、tcpdump@ee.lbl.gov へ送って下さい。
 .LP
 NIT では、外に出ていくトラフィックを観察できません。BPF ならできます。
 後者を用いることを推奨します。
 .LP
 IP フラグメントを再構成するか、もしくは少なくとも上位プロトコルの正し
 いデータサイズを計算するように設計しなおす必要があります。
 .LP
 ネームサーバについての逆引きについては、正しくダンプされません。
 実際の要求ではなく、(empty) クエスチョンセクションが、
 アンサーセクションに出力されます。
 逆引きについてはそれ自体がバグであると信じ、tcpdump ではなく逆引きを要求する
 プログラムを修正するべきと考える人達もいます。
 .LP
 Apple Ethertalk DDP パケットは、KIP DDP パケットと同様に簡単にダンプ出来
 るようにしたいのですが、実際はそうではありません。
 もし我々が、Ethertalk の利用を奨めるために何かやろうという気になったとし
 ても (そうではないのですが)、LBL (Lawrence Berkeley Laboratory) のどの
 ネットワーク上にも Ethertalk を通すことは許されていませんから、そのコード
 の試験は出来ません。
 .LP
 夏時間との変更の時にパケットトレースを行うと、タイムスタンプは変更後の
 時刻とはずれてしまいます (時間変化は無視されます)。
 .LP
 FDDI ヘッダを操作するようなフィルタの表現においては、全ての 
 FDDI パケットはカプセル化された Ethernet パケットであると仮定します。
 これは、IP, ARP, DECNET フェーズ 4 については正しいですが、ISO の CLNS 等の
 プロトコルについては正しくありません。したがって、フィルタ表現に正しく
 マッチしないようなパケットを偶然に受け入れてしまうことがあります。
 .LP
 .BR "ip6 proto"
 はヘッダチェーンを追跡すべきですが、現在のところはそうなっていません。
 .BR tcp
 と
 .BR udp
 もまた、ヘッダチェーンを追跡すべきです。
 .LP
 例えば \fBtcp[0]\fP といったトランスポート層ヘッダに対する演算は、
 IPv6 パケットに対しては動作しません。
 IPv4 パケットだけを見ます。