RFC1761 日本語訳
1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R.Gilligan. February 1995. (Format: TXT=10761 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Callaghan
Request for Comments: 1761 R. Gilligan
Category: Informational Sun Microsystems, Inc.
February 1995
コメントを求めるワーキンググループB.キャラハン要求をネットワークでつないでください: 1761年のR.ギリガンカテゴリ: 情報のサン・マイクロシステムズ・インク1995年2月
Snoop Version 2 Packet Capture File Format
スヌープVersion2パケットキャプチャーファイル形式
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.
この論文は、人々が詮索好きパケットキャプチャーファイルを生成して、解釈するために互換プログラムを書くことができるように、紙が提供される日曜日のThisまでに開発された「詮索好き」によって使用されたファイル形式、パケットモニター、および捕獲プログラムについて説明します。
1. Introduction
1. 序論
The availability of tools to capture, display and interpret packets traversing a network has proven extremely useful in debugging networking problems. The ability to capture packets and store them for later analysis allows one to de-couple the tasks of collecting information about a network problem and analysing that information. The "snoop" program, developed by Sun, has the ability to capture packets and store them in a file, and can interpret the packets stored in capture files. This RFC describes the file format that the snoop program uses to store captured packets. This paper was written so that others may write programs to interpret the capture files generated by snoop, or create capture files that can be interpreted by snoop.
ネットワークを横断するパケットをキャプチャして、表示して、解釈するツールの有用性はデバッグネットワーク問題で非常に役に立つと判明しました。パケットをキャプチャして、それらを保存する能力は、1つがネットワーク問題とその情報を分析することに関して情報集めに関するタスクの衝撃を吸収するのを後で解析するために許容します。 Sunによって開発された「詮索好き」プログラムは、ファイルにパケットをキャプチャして、それらを保存する能力を持って、キャプチャーファイルに保存されたパケットを解釈できます。 このRFCは詮索好きプログラムが捕らわれているパケットを保存するのに使用するファイル形式について説明します。 この論文は、他のものが詮索好きによって生成されたキャプチャーファイルを解釈するためにプログラムを書くか、または詮索好きが解釈できるキャプチャーファイルを作成できるように、書かれました。
Callaghan & Gilligan [Page 1] RFC 1761 Snoop Packet Capture File Format February 1995
キャラハンとギリガン[1ページ]RFC1761はパケットキャプチャーファイル形式1995年2月に詮索します。
2. File Format
2. ファイル形式
The snoop packet capture file is an array of octets structured as follows:
詮索好きパケットキャプチャーファイルは以下の通り構造化された八重奏の勢ぞろいです:
+------------------------+
| |
| File Header |
| |
+------------------------+
| |
| Packet Record |
~ Number 1 ~
| |
+------------------------+
. .
. .
. .
+------------------------+
| |
| Packet Record |
~ Number N ~
| |
+------------------------+
+------------------------+ | | | ファイルヘッダー| | | +------------------------+ | | | パケット記録| ~ No.1~| | +------------------------+ . . . . . . +------------------------+ | | | パケット記録| ~ No.N~| | +------------------------+
The File Header is a fixed-length field containing general information about the packet file and the format of the packet records it contains. One or more variable-length Packet Record fields follow the File Header field. Each Packet Record field holds the data of one captured packet.
File Headerはパケットファイルに関して一般情報を含む固定長フィールドとそれが含むパケット記録の形式です。 1つ以上の可変長のPacket Record分野がFile Header野原に続きます。 それぞれのPacket Record分野は1つの捕らわれているパケットに関するデータを保持します。
3. File Header
3. ファイルヘッダー
The structure of the File Header is as follows:
File Headerの構造は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification Pattern +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datalink Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別パターン+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン番号=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データリンクタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Callaghan & Gilligan [Page 2] RFC 1761 Snoop Packet Capture File Format February 1995
キャラハンとギリガン[2ページ]RFC1761はパケットキャプチャーファイル形式1995年2月に詮索します。
Identification Pattern:
識別パターン:
A 64-bit (8 octet) pattern used to identify the file as
a snoop packet capture file. The Identification Pattern
consists of the 8 hexadecimal octets:
64ビット(8八重奏)のパターンは、以前はよくファイルが詮索好きパケットキャプチャーファイルであると認識していました。 Identification Patternは8つの16進八重奏から成ります:
73 6E 6F 6F 70 00 00 00
73 6 6E F6F70 00 00 00
This is the ASCII string "snoop" followed by three null
octets.
これは3つのヌル八重奏がいうことになったASCIIストリング「詮索好き」です。
Version Number:
バージョン番号:
A 32-bit (4 octet) unsigned integer value representing
the version of the packet capture file being used. This
document describes version number 2. (Version number 1
was used in early implementations and is now obsolete.)
使用されるパケットキャプチャーファイルのバージョンを表す32ビット(4八重奏)の符号のない整数値。 このドキュメントはバージョンNo.2について説明します。 (バージョンNo.1は、早めの実装に使用されて、現在、時代遅れです。)
Datalink Type:
データリンクタイプ:
A 32-bit (4 octet) field identifying the type of
datalink header used in the packet records that follow.
The datalink type codes are listed in the table below:
データリンクヘッダーのタイプを特定する32ビット(4八重奏)の分野はパケットで従う記録を使用しました。 データリンクタイプコードは以下のテーブルに記載されています:
Datalink Type Code
------------- ----
IEEE 802.3 0
IEEE 802.4 Token Bus 1
IEEE 802.5 Token Ring 2
IEEE 802.6 Metro Net 3
Ethernet 4
HDLC 5
Character Synchronous 6
IBM Channel-to-Channel 7
FDDI 8
Other 9
Unassigned 10 - 4294967295
データリンクタイプコード------------- ---- 同期IEEE802.3 0IEEE802.4トークンバス1IEEE802.5トークンリング2IEEE802.6地下鉄ネット3イーサネット4HDLC5のキャラクターの6のIBMのチャンネルからチャンネルへの7他の9が10--4294967295を割り当てなかったFDDI8
4. Packet Record Format
4. パケットレコード形式
Each packet record holds a partial or complete copy of one packet as well as some descriptive information about that packet. The packet may be truncated in order to limit the amount of data to be stored in the packet file. In addition, the packet record may be padded in order for it to align on a convenient machine-dependent boundary. Each packet record holds 24 octets of descriptive information about the packet, followed by the packet data, which is variable-length, and an optional pad field. The descriptive information is structured
それぞれのパケット記録はそのパケットに関する何らかの記述的な情報と同様に1つのパケットの部分的であるか完全なコピーを持っています。 パケットは、パケットファイルに保存されるためにデータ量を制限するために先端を切られるかもしれません。 さらに、パケット記録は、便利なマシン依存境界に並ぶために水増しされるかもしれません。 それぞれのパケット記録はパケットデータがあとに続いた可変長であることのパケット、および任意のパッド分野の周りに描写的である情報の24の八重奏を保持します。 記述的な情報は構造化されます。
Callaghan & Gilligan [Page 3] RFC 1761 Snoop Packet Capture File Format February 1995
キャラハンとギリガン[3ページ]RFC1761はパケットキャプチャーファイル形式1995年2月に詮索します。
as six 32-bit (4-octet) integer values.
6の(4八重奏)の32ビットの整数が評価するように。
The structure of the packet record is as follows:
パケット記録の構造は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Included Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Drops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Data .
. .
+ +- - - - - - - -+
| | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 含まれている長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットレコード長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 累積している低下| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ秒| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプマイクロセカンド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . パケットデータ+ (+)--、--、--、--、--、-+| | パッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Length
原長
32-bit unsigned integer representing the length in
octets of the captured packet as received via a network.
ネットワークを通して受け取るように捕らわれているパケットの八重奏における長さを表す32ビットの符号のない整数。
Included Length
含まれている長さ
32-bit unsigned integer representing the length of the
Packet Data field. This is the number of octets of the
captured packet that are included in this packet record.
If the received packet was truncated, the Included
Length field will be less than the Original Length
field.
Packet Data分野の長さを表す32ビットの符号のない整数。 これはこのパケット記録に含まれている捕らわれているパケットの八重奏の数です。 容認されたパケットが先端を切られたなら、Included Length分野はOriginal Length分野より以下になるでしょう。
Packet Record Length
パケットレコード長
32-bit unsigned integer representing the total length of
this packet record in octets. This includes the 24
octets of descriptive information, the length of the
Packet Data field, and the length of the Pad field.
八重奏における、このパケット記録の全長を表す32ビットの符号のない整数。 これは描写的である情報の24の八重奏、Packet Data分野の長さ、およびPad分野の長さを含んでいます。
Callaghan & Gilligan [Page 4] RFC 1761 Snoop Packet Capture File Format February 1995
キャラハンとギリガン[4ページ]RFC1761はパケットキャプチャーファイル形式1995年2月に詮索します。
Cumulative Drops
累積している低下
32-bit unsigned integer representing the number of
packets that were lost by the system that created the
packet file between the first packet record in the
file and this one. Packets may be lost because of
insufficient resources in the capturing system, or for
other reasons. Note: some implementations lack the
ability to count dropped packets. Those
implementations may set the cumulative drops value to
zero.
ファイルにおける最初のパケット記録とこれの間でパケットファイルを作成したシステムによって失われたパケットの数を表す32ビットの符号のない整数。 パケットはキャプチャするシステムの不十分なリソースのため他の理由ので失われるかもしれません。 以下に注意してください。 いくつかの実装が下げられたパケットを数える能力を欠いています。 それらの実装は累積している低下値をゼロに設定するかもしれません。
Timestamp Seconds
タイムスタンプ秒
32-bit unsigned integer representing the time, in
seconds since January 1, 1970, when the packet arrived.
パケットが到着した1970年1月1日以来の秒に時間を表す32ビットの符号のない整数。
Timestamp Microseconds
タイムスタンプマイクロセカンド
32-bit unsigned integer representing microsecond
resolution of packet arrival time.
パケット到着時間のマイクロセカンド解決を表す32ビットの符号のない整数。
Packet Data
パケットデータ
Variable-length field holding the packet that was
captured, beginning with its datalink header. The
Datalink Type field of the file header can be used to
determine how to decode the datalink header. The length
of the Packet Data field is given in the Included Length
field.
データリンクヘッダーと共に始まって、キャプチャされたパケットを保持する可変長の分野。 データリンクヘッダーを解読する方法を決定するのにファイルヘッダーのDatalink Type分野を使用できます。 Included Length分野でPacket Data分野の長さを与えます。
Pad
パッド
Variable-length field holding zero or more octets that
pads the packet record out to a convenient boundary.
パケット記録を便利な境界に広げる可変長の、より分野より多くの把持ゼロ八重奏。
5. Data Format
5. データの形式
All integer values are stored in "big-endian" order, with the high- order bits first.
すべての整数値が最初に、高いオーダービットによる「ビッグエンディアン」オーダーに保存されます。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Callaghan & Gilligan [Page 5] RFC 1761 Snoop Packet Capture File Format February 1995
キャラハンとギリガン[5ページ]RFC1761はパケットキャプチャーファイル形式1995年2月に詮索します。
Authors' Addresses
作者のアドレス
Brent Callaghan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMTV05-44 Mountain View, CA 94043-1100
ブレントキャラハンサン・マイクロシステムズ・インク2550ガルシア・アベニューMailstop UMTV05-44マウンテンビュー、カリフォルニア94043-1100
Phone: 1-415-336-1051 EMail: brent.callaghan@eng.sun.com
以下に電話をしてください。 1-415-336-1051 メールしてください: brent.callaghan@eng.sun.com
Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMTV05-44 Mountain View, CA 94043-1100
ロバートE.ギリガンサン・マイクロシステムズ・インク2550ガルシア・アベニューMailstop UMTV05-44マウンテンビュー、カリフォルニア94043-1100
Phone: 1-415-336-1012 EMail: bob.gilligan@eng.sun.com
以下に電話をしてください。 1-415-336-1012 メールしてください: bob.gilligan@eng.sun.com
Callaghan & Gilligan [Page 6]
キャラハンとギリガン[6ページ]
一覧
スポンサーリンク
