os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

tcpdump 3.7.1 (rev 1.8.2.1->1.8.2.2)

Browse source 
Submitted by:	Yuko Sasaki <yuko@veltec.co.jp>
This commit is contained in:
Kazuo Horikawa 2002-08-26 00:59:14 +00:00
parent 2912a86246
commit 248d7926a0
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=14019
1 changed files with 248 additions and 73 deletions

321
ja_JP.eucJP/man/man1/tcpdump.1
View file

@ -1,4 +1,4 @@
.\" @(#) $Header: /home/ncvs/doc/ja_JP.eucJP/man/man1/tcpdump.1,v 1.17 2002-01-19 04:13:35 horikawa Exp $ (LBL)
.\" @(#) $Header: /home/ncvs/doc/ja_JP.eucJP/man/man1/tcpdump.1,v 1.18 2002-08-26 00:59:14 horikawa Exp $ (LBL)
.\"
.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
.\" The Regents of the University of California. All rights reserved.
@ -20,9 +20,11 @@
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.\" %FreeBSD: src/contrib/tcpdump/tcpdump.1,v 1.8.2.1 2001/07/26 22:30:02 fenner Exp %
.\" %FreeBSD: src/contrib/tcpdump/tcpdump.1,v 1.8.2.2 2002/07/05 11:29:59 fenner Exp %
.\"
.\" $FreeBSD$
.\"
.\"
.TH TCPDUMP 1 "3 January 2001"
.SH 名称
tcpdump \- ネットワーク上のトラフィックデータのダンプ
@ -30,10 +32,16 @@ tcpdump \-
.na
.B tcpdump
[
.B \-adeflnNOpqRStvxX
.B \-adeflnNOpqRStuvxX
] [
.B \-c
.I count
]
.br
.ti +8
[
.B \-C
.I file_size
] [
.B \-F
.I file
@ -52,14 +60,12 @@ tcpdump \-
.B \-r
.I file
]
.br
.ti +8
[
.B \-s
.I snaplen
]
.br
.ti +8
.br
.ti +8
[
.B \-T
.I type
@ -84,35 +90,117 @@ tcpdump \-
\fItcpdump\fP は、オプションで指定されたネットワークインタフェース上で
取得可能なパケットのヘッダのうち \fIexpression\fP にマッチするものを出力
します。
パケットデータを後で分析するためファイルに保存するよう、
.B \-w
フラグで実行することもできます。
また、
.B \-r
フラグで、ネットワークインタフェースからのパケットではなく、
ファイルに保存されたパケットから読み込むことができます。
すべての場合に、
.I expression
にマッチするパケットだけ、
.IR tcpdump
によって処理されます。
.LP
.B SunOS 上の nit ないし bpf の場合:
.I tcpdump
を実行するには、
は、
.B \-c
フラグで実行しない場合、SIGINT シグナル (
例えば、一般的な手法として
割り込み文字列である control-C
の入力) か
SIGTERM シグナル (一般的な手法として
.BR kill (1)
コマンド)
によって割り込みがあるまで、パケットを捕捉し続けます。
.B \-c
フラグで実行する場合は、
SIGINT シグナル や SIGTERM シグナルで割り込みされるか、
指定されたパケット数まで処理します。
.LP
.I tcpdump
がパケットの捕捉を終了したとき、以下の合計を
表示します。
.IP
packets ``received by filter''
(この意味は、
.IR tcpdump
を実行している OS に依存しますし、
おそらく OS のコンフィギュレーション方法にも依存するでしょう。
filter がコマンドラインで指定された場合、ある OS では
それが filter expression によって一致したかどうかに関わらず、
パケットを数えます。
また別の OS では、filter expression によって一致した場合のみ
.IR tcpdump
によって処理されたパケットだけを数えます。)
.IP
packets ``dropped by kernel''
(OS がアプリケーションにその情報を報告する場合には、
バッファスペースの不足により、
.I tcpdump
が走っている OS の
パケットキャプチャ制御機構から、落ちてしまったパケット
の数です。
それ以外の場合には、0 が表示されます。)
.LP
大抵の BSD のような SIGINFO シグナルがサポートされている
プラットホームでは、SIGINFO シグナル
(例えば、一般的な手法として
``状態'' 文字列である control-T
の入力)
を受信したとき、それらの合計を表示して、パケットの捕捉を
引き続き行います。
.LP
ネットワークインタフェースからパケットを読むには、
権限を必要とします。
.TP
.B SunOS 3.x、4.x 上の NIT ないし BPF の場合:
.I /dev/nit
ないし
.IR /dev/bpf*
への読み込みアクセス権が必要です。
.B Solaris 上の dlpi の場合:
.TP
.B Solaris 上の DLPI の場合:
.IR /dev/le
等のネットワーク仮想デバイスへの読み書きアクセス権が必要です。
.B HP-UX 上の dlpi の場合:
少なくとも Solaris のいくつかのバージョン上では、
.I tcpdump
が promiscuous-mode で捕捉するには、
この条件だけでは不十分です。
それらの Solaris のバージョンでは、root になる必要があります。
もしくは promiscuous-mode で捕捉するには root に
setuid されてインストールされている場合のみ
.I tcpdump
の実行が可能になります。
.TP
.B HP-UX 上の DLPI の場合:
使用者が root であるか、
プログラムが root に setuid されてインストールされている場合のみ実行可能です。
.I tcpdump
が root に setuid されてインストールされている場合のみ実行可能です。
.TP
.B IRIX 上の snoop の場合:
使用者が root であるか、
プログラムが root に setuid されてインストールされている場合のみ実行可能です。
.I tcpdump
が root に setuid されてインストールされている場合のみ実行可能です。
.TP
.B Linux の場合:
使用者が root であるか、
プログラムが root に setuid されてインストールされている場合のみ実行可能です。
.I tcpdump
が root に setuid されてインストールされている場合のみ実行可能です。
.TP
.B Ultrix および Digital UNIX の場合:
スーパユーザが、
.IR pfconfig (8)
を用いて promiscuous-mode での操作を許可していれば、どのユーザも
.BR tcpdump
を起動できます。
.IR tcpdump .
を使って、ネットワークトラフィックを捕捉できてしまいます。
.TP
.B BSD の場合:
.IR /dev/bpf*
への読み込みアクセス権が必要です。
.LP
保存されたパケットファイルを読むには、権限を必要としません。
.SH オプション
.TP
.B \-a
@ -121,6 +209,21 @@ tcpdump \-
.B \-c
\fIcount\fP で指定した数のパケットを受信した後に終了します。
.TP
.B \-C
保存ファイルに raw パケットを書き込む前に、
現在のファイルが \fIfile_size\fP より大きいかどうか
をチェックします。
もし大きいなら、現在の保存ファイルを閉じて新しいものを開きます。
付けられるファイル名は、最初の保存ファイルを除く
2 番目以降の保存ファイルから
.B \-w
フラグで指定されたファイル名の
後にそれぞれ番号がつきます。
その番号は、2 から始まり順に大きくなります。
\fIfile_size\fP の単位は 100 万バイト
(1,000,000 バイト。1,048,576 バイトの
ことではない) です。
.TP
.B \-d
解釈されたパケットマッチングコードを読みやすい形に整形した後、
標準出力にダンプして停止します。
@ -138,10 +241,10 @@ tcpdump \-
.B \-E
\fIalgo:secret\fP を、IPsec ESP パケットの解読に使用します。
アルゴリズムは
\fBdes-cbc\fP,
\fB3des-cbc\fP,
\fBblowfish-cbc\fP,
\fBrc3-cbc\fP,
\fBdes-cbc\fP,
\fB3des-cbc\fP,
\fBblowfish-cbc\fP,
\fBrc3-cbc\fP,
\fBcast128-cbc\fP,
\fBnone\fP
のいずれかです。
@ -187,6 +290,11 @@ IP
``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''
のように使用します。
.TP
.B \-m
SMI MIB モジュールの定義を、ファイル \fImodule\fR からロードします。
複数の MIB モジュールを \fItcpdump\fP にロードするために、
複数回このオプションを使用することができます。
.TP
.B \-n
アドレス (IP アドレスやポート番号など) を名前に変換しません。
.TP
@ -195,11 +303,6 @@ IP
指定すると、``nic.ddn.mil'' とは表示されず、かわりに ``nic'' とだけ表示し
ます。
.TP
.B \-m
SMI MIB モジュールの定義を、ファイル \fImodule\fR からロードします。
複数の MIB モジュールを \fItcpdump\fP にロードするために、
本オプションを複数回使用可能です。
.TP
.B \-O
パケットマッチングコードのオプティマイザを動かしません。本オプションは、
オプティマイザ中のバグを疑う場合にのみ有効なものです。
@ -215,11 +318,20 @@ SMI MIB
素早い (静かな?) 出力を行ないます。出力する行を短くするために、通常出力
されるプロトコル情報の一部は出力されません。
.TP
.B \-R
ESP/AH パケットが古い仕様 (RFC1825 から RFC1829) に基いているものと仮定します。
指定すると、\fItcpdump\fP はリレー防止フィールドを表示しません。
ESP/AH 仕様にはプロトコルバージョンフィールドがありませんので、
\fItcpdump\fP は ESP/AH プロトコルのバージョンを推定できません。
.TP
.B \-r
パケットを、\fIfile\fR で指定したファイル (-w オプションで作成されます) か
ら読み込みます。\fIfile\fR として``-''が指定された場合は標準入力が用いら
れます。
.TP
.B \-S
TCP シーケンス番号を相対番号ではなく、絶対番号で出力します。
.TP
.B \-s
デフォルトの 68 バイト (SunOS の NIT では最小値は実際には 96) ではなくて、
\fIsnaplen\fP だけのデータを各パケットから取得します。68 バイトという
@ -249,15 +361,6 @@ SMI MIB
\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
@ -269,6 +372,10 @@ TCP
.TP
.B \-tttt
各ダンプ行で、デフォルト書式でタイムスタンプを表示し、その前に日付を付けます。
.\"" (.TPが抜けてる） **********/
.TP
.B \-u
デコードされてない NFS 操作を出力します。
.TP
.B \-v
(少しではありますが) 出力情報を増やします。例えば、IP パケット中の
@ -278,7 +385,8 @@ TTL
.TP
.B \-vv
さらに多くの情報を出力します。例えば、NFS の返答パケットの追加
フィールドを出力します。
フィールドや完全にデコードされた SMB パケット
を出力します。
.TP
.B \-vvv
もっと多くの情報を出力します。例えば、telnet \fBSB\fP ... \fBSE\fP
@ -465,8 +573,14 @@ IPv4/v6
真となります。言い替えると、始点もしくは終点のイーサネットアドレスが
\fIhost\fP であり、始点と終点のどちらの IP アドレスも \fIhost\fP でない
ということです。
\fIhost\fP は /etc/hosts ファイルと /etc/ethers の両方で定義されている名前を
指定する必要があります (等価な表現は、
\fIhost\fP
マシンの host-name-to-IP-address (名前解決) 制御機構
(hosts ファイル、DNS、NIS など)
とマシンの host-name-to-Ethernet-address (イーサネット
アドレス解決) 制御機構
(/etc/ethers など)
から見つけられる名前である必要があります。
(同様な記述は、
.in +.5i
.nf
\fBether host \fIehost \fBand not host \fIhost\fR
@ -488,15 +602,15 @@ IPv4/v6
.IP "\fBnet \fInet\fR"
始点 IPv4/v6 アドレスもしくは終点 IPv4/v6 アドレスが \fInet\fP で指定された
ネットワークに属するものである場合に、真となります。
.IP "\fBnet \fInet\fR \fBmask \fImask\fR"
IP アドレスが、指定された \fInet\fR および netmask の値で決まる
.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
IP アドレスが、指定された \fInet\fR および \fInetmask\fR の値で決まる
ネットワークに属するものである場合に、真となります。
\fBsrc\fR や \fBdst\fR を指定する事も可能です。
この構文は IPv6 \fInet\fR では正当でないことに注意してください。
.IP "\fBnet \fInet\fR/\fIlen\fR"
IPv4/v6 アドレスが、
指定された \fInet\fR および \fIlen\fR のビット長のネットマスクで
決まるネットワークに属するものである場合に、真となります。
IPv4/v6 アドレスが、指定された \fIlen\fR
のビット長のネットマスクで \fInet\fR に属するネットワーク
の場合に、真となります。
\fBsrc\fR や \fBdst\fR を指定する事も可能です。
.IP "\fBdst port \fIport\fR"
パケットが ip/tcp, ip/udp, ip6/tcp, ip6/udp のいずれかであり、終点
@ -552,7 +666,7 @@ tcp/login
を参照) の場合に、真となります。
\fIprotocol\fP は、数字もしくは
\fIicmp\fP, \fIicmp6\fP, \fIigmp\fP, \fIigrp\fP, \fIpim\fP, \fIah\fP,
\fIesp\fP, \fIudp\fP, or \fItcp\fP
\fIesp\fP, \fIvrrp\fP, \fIudp\fP, \fItcp\fP
のいずれかの名前が指定可能です。\fItcp\fP, \fIudp\fP, \fIicmp\fP の
各識別子はキーワードでもであり、バックスラッシュ (\\)(C-shell では \\\\) を用
いてエスケープしなければならないことに注意してください。
@ -580,7 +694,8 @@ tcp/login
複雑であり \fItcpdump\fP 中の BPF 最適化コードでは最適化できません。
よって、この動作はいくぶん遅いです。
.IP "\fBip protochain \fIprotocol\fR"
Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
\fBip6 protochain \fIprotocol\fR と同様で、
IPv4 のものです。
.IP "\fBether broadcast\fR"
パケットがイーサネットブロードキャストパケットの場合に、真となります。
\fIether\fP キーワードは、省略可能です。
@ -601,16 +716,62 @@ Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
\fIprotocol\fP は、数字もしくは
\fIip\fP, \fIip6\fP, \fIarp\fP, \fIrarp\fP, \fIatalk\fP, \fIaarp\fP,
\fIdecnet\fP, \fIsca\fP, \fIlat\fP, \fImopdl\fP, \fImoprc\fP,
\fIiso\fP
\fIiso\fP, \fIstp\fP, \fIipx\fP, \fInetbeui\fP
のいずれかの名前を指定可能です。
これらの識別子はキーワードでもあり、バックスラッシュ (\\) でエスケープし
なければならないことに注意してください。
[FDDI の場合 (例えば `\fBfddi protocol arp\fR')、プロトコルの識別は
IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。通常これは FDDI
ヘッダの上の層にあります。\fItcpdump\fP は、プロトコル識別子で
フィルタリングするときは、すべての FDDI パケットは LLC ヘッダを含み、
かつその LLC ヘッダがいわゆる SNAP 形式であると仮定します。
Token Ring も同様です。]
.IP
[FDDI (例えば `\fBfddi protocol arp\fR') や Token Ring (
例えば`\fBtr protocol arp\fR') 、
これらのほとんどのプロトコルの場合、プロトコルの識別は
IEEE802.2 の論理リンク制御 (LLC) ヘッダによって行われます。
通常これは FDDI ヘッダや Token Ring ヘッダの上の層にあります。
.IP
FDDI または Token Ring のほとんどのプロトコル識別
をフィルタリングするとき、\fItcpdump\fR は
Ethernet をカプセル化するために
LLC ヘッダのプロトコル ID 範囲のみ、
いわゆる SNAP フォーマットである
管理組織識別子 (OUI) の 0x000000
の範囲のみをチェックします。
パケットが
SNAP フォーマットである
OUI の 0x000000 にあるか
どうかはチェックしません。
.IP
例外は以下の通りです。
\fIiso\fP は LLC ヘッダの
DSAP (Destination Service Access Point)
と SSAP (Source Service Access Point) の
範囲もチェックします。
\fIstp\fP および \fInetbeui\fP は、LLC ヘッダの
DSAP をチェックします。
\fIatalk\fP は、
SNAP フォーマットである OUI の 0x080007
と、Appletalk etype に対してチェックします。
.IP
Ethernet の場合、\fItcpdump\fR は、
これらのプロトコルのほとんどに対して Ethernet 型の
範囲をチェックします。
例外は以下の通りです。
\fIiso\fP、\fIsap\fP および \fInetbeui\fP では
FDDI および Token Ring の場合と同様に
802.3 フレームをチェックし、次に
LLC ヘッダをチェックします。
\fIatalk\fP では
FDDI および Token Ring の場合と同様に
Ethernet フレーム内 の Appletalk etype および
SNAP フォーマットパケットの両方に対してチェックします。
\fIaarp\fP では
Ethernet フレームまたは
802.3 SNAP フレームである
OUI の 0x000000 と、
Appletalk ARP etype に対してチェックします。
そして、\fIipx\fP では、Ethernet フレーム内の IPX etype、
LCC ヘッダ内の IPX DSAP、LCC ヘッダが IPX でカプセル化
されていない 802.2 および SNAP フレーム内の IPX etype を
チェックします。
]
.IP "\fBdecnet src \fIhost\fR"
DECNET パケットの始点アドレスが
.IR host
@ -625,7 +786,7 @@ DECNET
DECNET パケットの始点あるいは終点アドレスが
.IR host
の場合に、真となります。
.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR"
.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
.in +.5i
.nf
\fBether proto \fIp\fR
@ -700,8 +861,27 @@ IPv4
最初のフラグメントを捕捉します。
この検査は、\fBtcp\fP および \fBudp\fP のインデックス操作においては、暗黙のうち
に適用されます。
例えば、\fBtcp[0]\fP は常に TCP ヘッダの先頭バイトを指し、
例えば、\fBtcp[0]\fP は常に TCP \fIヘッダ\fPの先頭バイトを指し、
決して各フラグメントの先頭バイトを指すものではありません。
いくつかのオフセットとフィールド値は、数値ではなく
定数として表記できます。
次のプロトコルヘッダフィールドオフセットが利用可能です。
\fBicmptype\fP (ICMP タイプフィールド)、\fBicmpcode\fP (ICMP
コードフィールド) および \fBtcpflags\fP (TCP フラグフィールド)
次の ICMP タイプフィールド値が利用可能です。
\fBicmp-echoreply\fP,
\fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
\fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
\fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
\fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
\fBicmp-maskreq\fP, \fBicmp-maskreply\fP
次の TCP フラグフィールド値が利用可能です。
\fBtcp-fin\fP,
\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP, \fBtcp-push\fP,
\fBtcp-ack\fP, \fBtcp-urg\fP
.LP
プリミティブは、以下のように組み合わせることが可能です。
.IP
@ -809,7 +989,7 @@ tcpdump ip and not net \fIlocalnet\fP
.RS
.nf
.B
tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
.fi
.RE
.LP
@ -837,7 +1017,7 @@ echo
.RS
.nf
.B
tcpdump 'icmp[0] != 8 and icmp[0] != 0'
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
.fi
.RE
.SH 出力形式
@ -917,7 +1097,7 @@ arp reply csam is-at CSAM\fR
のイーサネットアドレスを返答しています (この例では、イーサネットアドレス
は大文字で、インターネットアドレス部は小文字で表記しています)。
.LP
\fBtcpdump \-n\fP として起動した場合には、少し冗長になります。
\fItcpdump \-n\fP として起動した場合には、少し冗長になります。
.RS
.nf
.sp .5
@ -926,7 +1106,7 @@ arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fR
.fi
.RE
.LP
\fBtcpdump \-e\fP として起動した場合には、最初のパケットはブロードキャスト
\fItcpdump \-e\fP として起動した場合には、最初のパケットはブロードキャスト
パケットであり、次のパケットはポイントツーポイントのパケットであることが
わかります。
.RS
@ -1039,9 +1219,9 @@ IP
.HD
.B 特定フラグの組み合わせ (SYN-ACK, URG-ACK 等) による TCP パケットの捕捉
.PP
TCP ヘッダの制御ビットセクションには、次の 6 ビットがあります:
TCP ヘッダの制御ビットセクションには、次の 8 ビットがあります:
.IP
.I URG | ACK | PSH | RST | SYN | FIN
.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
.PP
TCP 接続の確立に使用されるパケットを見たいものとしましょう。
新規接続を初期化する時、
@ -1074,7 +1254,7 @@ TCP
-----------------------------------------------------------------
| 確認応答番号 |
-----------------------------------------------------------------
| HL | 予約 |U|A|P|R|S|F| ウィンドウサイズ |
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
-----------------------------------------------------------------
| TCP チェックサム | 緊急ポインタ |
-----------------------------------------------------------------
@ -1089,7 +1269,7 @@ TCP
.nf
0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | 予約 |U|A|P|R|S|F| ウィンドウサイズ |
| HL | 予約 |C|E|U|A|P|R|S|F| ウィンドウサイズ |
----------------|---------------|---------------|----------------
| |13 オクテット目| | |
.fi
@ -1099,16 +1279,12 @@ TCP
.nf
| |
|---------------|
| |U|A|P|R|S|F|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
.fi
.PP
.\" 2 bytes は 2 bits の誤り？
このオクテットの上位 2 ビットは予約フィールドから来ています。
RFC 793 によると、この欄は将来の使用のために予約となっていて、
必ず 0 です。
残りの 6 ビットは、我々が興味がある TCP 制御ビットです。
これらは我々が興味がある TCP 制御ビットです。
このオクテットのビットを、右から左へ、0 から 7 と番号付けします。
PSH ビットは第 3 ビットであり、URG ビットは第 5 ビットです。
.PP
@ -1117,14 +1293,13 @@ SYN
第 13 オクテットになにが起きるか見てみましょう:
.PP
.nf
| |U|A|P|R|S|F|
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
.fi
.PP
第 7 ビットと第 6 ビットは予約フィールドに属し必ず 0 だと既に述べました。
制御ビットセクションを見ると、ビット番号 1 (SYN) のみがセットされています。
.PP
オクテット番号 13 が、ネットワークバイト順で、
@ -1167,7 +1342,7 @@ SYN-ACK
オクテット 13 がどうなっているかを見てみましょう:
.PP
.nf
| |U|A|P|R|S|F|
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
@ -1272,8 +1447,8 @@ IP
他の qclass が入った場合、`A' の直後に表示されます。
.LP
少数の変則的なパケットは検査され、カギカッコで囲まれた付加
フィールドにその結果が表示されます。query が返答、ネームサーバ
もしくはオーソリティセクションを含む場合、
フィールドにその結果が表示されます。問い合わせに返答が
あったとき、オーソリティレコードもしくは追加レコードのセクション
.IR ancount ,
.IR nscount ,
.I arcount
@ -1299,7 +1474,7 @@ helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
.RE
最初の例は、\fIh2opolo\fP からの質問 ID 3 の要求に対し、\fIhelios\fP が
3 つのアンサーレコード、3 つのネームサーバレコード、そして 7 つの
オーソリティレコードを持っているパケットで返答しているというものです。
追加レコードを持っているパケットで返答しているというものです。
最初のアンサーレコードは、タイプ A (アドレス) であり、そのデータは
IP アドレス 128.32.137.3 です。UDP と IP のヘッダを除いた総サイズは
273 バイトです。