名称

tcpdump − ネットワーク上のトラフィックをダンプする

形式

tcpdump [ −deflnNOpqStvx ] [ −c count ] [ −F file ] [ −i interface ] [ −r file ] [ −s snaplen ] [ −w file ] expression

解説

tcpdump は、ブーレン式に一致するネットワークインターフェース上の パケットのヘッダを出力します。 NEWS-OS ではアクセスは /dev/bpf0 などによって管理されます。

オプション

−c count の数だけパケット受信後、終了します。

−d コンパイルしたパケットマッチングコードを 標準出力にダンプし、 停止します。

−e 各ダンプ行にリンクレベルヘッダを付加して出力します。

−f 「ローカル」でないインターネットアドレスを名前ではなく数字で出力します。 (NIS サーバで起こりうるの重大なバグを回避するため。 つまり、非ローカルインターネット番号を いつまでも変換し続けるようなハングを防ぐため。)

−F フィルタ式の入力として file を使用します。 コマンド行に式を追加しても、 無視されます。

−i interface を指定します。 指定しない場合、 tcpdump は最も小さい数字を付け、 アップされたインターフェースのシステムインターフェースリスト (ループ バックを除く) を調べます。

−l 標準出力行をバッファリングします。 出力を何らかの加工してから見ようとする場合に有効です。 例えば、

tcpdump  −l  |  tee dat

または、

tcpdump  −l   > dat  &  tail  −f  dat

−n アドレス (例えば、 ホストアドレス、ポート番号等) を名称に変換しません。

−N ホスト名のドメイン名を出力しません。 例えば、 このオプションを指定すると、 tcpdump は、 nic.ddn.mil の代りとして nic を出力します。

−O パケットマッチング コード オプティマイザ を実行しません。 オプティマイザにバグがあると 疑う場合に有効となります。

−p インターフェースをプロミスキュアスモード (全てのパケットを 受信する状態) にしません。 なんらかの他の理由があれば、 インターフェースはプロミスキュアスモードになりうることに注意。 つまり、 ‘ether host {localhost} or broadcast’ の省略形として −p は使用できません。

−q quick (quiet?) 出力。 プロトコル情報を短縮して、 出力行を短く表示します。

−r file (−w オプションにて生成)よりパケットを読みます。 file が − の場合、標準入力が使用されます。

−s デフォルトの 68 (NIT では、実際の最小値は 96) ではなく、 各パケットからの snaplen バイトのデータを読み取ります。 IP、ICMP、TCP および UDP には 68 バイトが適切ですが、 ネームサーバと NFS パケット (下記参照) からプロトコル情報が切り取られてしまいます。 スナップショットの長さの制限のために切り捨てられたパケット情報が ある場合には “[|]” を持つ出力に示されます。 スナップショットを長く指定すると、 各パケットの処理時間を増やし、また その結果パケットバッファの全体の量を減らします。 その結果パケットを失うかもしれません。 必要なプロトコル情報を獲得できる 最短の snaplen を指定する必要があります。

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

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

−v (少しだけ多く) verbose 出力。 例えば、IP パケットの TTL (time to live) や service タイプなどを出力します。

−w パケットの内容をそのままの形で、解析したり出力したりせずに file に書き込みます。このファイルの内容は、 −r オプションで出力できます。 file に − を指定すると、標準出力が使用されます。

−x 各パケット (リンクレベル ヘッダを除く) を 16 進数で出力します。 実際のパケット長または snaplen の小さい方の長さだけ出力されます。

expression(式)

どのパケットをダンプするかを選択します。 式を指定しないと、ネット上の全てのパケットが出力されます。 そうでなければ、式が「真」であるパケットのみダンプされます。 式は一つ以上のプリミティブで構成されます。 通常、プリミティブは前に一つ以上の qualifier を持つ id (名前または番号)で構成されます。 3 種類の qualifier があります。

typeID 名前または番号が参照するものの種類を示します。 host、 net または port などの種類があります。 例えば、 ‘host foo’、 ‘net 128.3’、 ‘port 20’ など。 タイプを指定しないと、 host が設定されます。

dirid への、そして (または) ID からの特定の転送方向を示します。 src、 dst、 src or dst または src and dst などがあります。 例えば、 ‘src foo’、 ‘dst net 128.3’、 ‘src or dst port ftp-data’。 方向の qualifier を指定しないと、 src or dst となります。

proto特定のプロトコルに合致するものを指定します。 ether、 ip、 arp、 rarp、 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’ を示します。 上記に加え、 いくつかの特殊なプリミティブのキーワード があり、以下のものの後には指定できません。 gateway、 broadcast、 less、 greater そして数式など。それらについては、 次に示します。 より複雑はフィルタ式はプリミティブを and、 or 、 not などを使用して相互に接続することができます。例えば、 ‘host foo and not port ftp and not port ftp-data’ など。タイピング量を減らすために、 同一の qualifier を省略できます。 例えば、 ‘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
パケットの IP ディスティネーションフィールドが host なら真です。 それは、アドレスまたは名称でも構いません。

src host host
パケットの IP ソースフィールドが host なら真。

host host
パケットの IP ソースまたは行き先が host なら真。 上記ホスト式のどれの前にも キーワード ip、arp、または rarp などを指定できます。

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 なら真。

gateway host
パケットがゲートウェイとして host を使用するなら真。 例えば、IP のソースも IP のディスティネーションも host ではないときに、 イーサネットソースまたはディスティネーションアドレスが host です。 host は名称でなければなりません。 すなわち、 /etc/hosts および /etc/ethers に指定してなければなりません。 (同様に式として

ether host ehost and not host host

があり、host / ehost に対する名称または番号として使用されます。)

dst net net
パケットの IP ディスティネーションアドレスが net の ネットワーク番号を持てば真。 それは、実際のアドレスまたは名称どちらでも構いません。

src net net
パケットの IP ソースアドレスが net のネットワーク番号 ならば真。

net net
パケットの IP ソースまたはディスティネーションアドレスが net のネットワーク番号なら真。

dst port port
パケットが ip/tcp または ip/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 のソースポート値を持つなら真。

port port
パケットのソースまたはディスティネーションポート が port なら真。 上記ポート式のどれでも、 tcp または udp などの キーワードを前に指定できます。

tcp src port port

これは、tcp パケットにのみ一致します。

less length
パケットが length 以下または同等の長さを持つなら真。 これは次と同等。

len <= length. 

greater length
パケットが length 以上または同等の長さを持つなら真。 これは次と同等。

len >= length. 

ip proto protocol
パケットが プロトコルタイプ protocol の ip パケット (ip(4P) 参照) なら真。 protocol には番号 または icmp、udp、nd、または tcp の どれかの名称を指定できます。 識別子 tcp および udp もキーワードであり、 その前にバックスラッシュ (\) を指定しなければなりません。 C シェル内では \\ となります。

broadcast
パケットがブロードキャストなら真。

ether proto protocol
パケットが ether タイプの protocol なら真。 protocol には番号 または ip、arp、または rarp などの名称を指定 できます。識別子もキーワードであり、 その前にバックスラッシュ (\) を指定しなければなりません。

ip, arp, rarp
省略形として、

ether proto p

p は上記プロトコルの一つを指定します。

tcp, udp
省略形として、

ip proto p

p は上記プロトコルの一つを指定します。

expr relop expr
のような式も同じく有効です。 ここで、 relop が >、<、>=、 <=、=、!= のどれかであり、expr が整数の定数で構成される数式であり、 (標準の C の形式) 通常のバイナリオペレータ  (+、−、 ∗、/、&、 |)、 長さのオペレータ、 特殊なパケットデータアクセサリなどが指定できます。 パケット内のデータをアクセスする場合、 次の形式で指定します。

proto [ expr : size ]

proto は ether、ip、arp、rarp、tcp、 or udp のどれか を指定します。 それは、インデックスオペレーションのためにプロトコル層を指定します。 指定のプロトコル層に関連するバイトオフセット は expr で指定します。 size はオプションで、 関係のあるフィールドのバイト数 を示します。 size は、1、2、または 4 であり、デフォルトとは、1 です。 キーワード len で示される長さのオペレータは、 パケットの長さを指定する事に用います。
 
例えば、‘ether[0] & 1 != 0’ は全てのマルチキャストトラフィックを 獲得します。 式 ‘ip[0] & 0xf != 5’ はオプション付きの全ての IP パケットを獲得します。 式 ‘ip[2:2] & 0x1fff = 0’ はフラグメントされていないパケットまたは フラグメント化されたデータのフラグのゼロに当たるパケットを獲得します。 このチェックは tcp および udp インデックスオペレーションにに適用することができます。 例えば、 tcp[0] は常に TCP header の先頭バイトを示すことになり、 途中のパケットデータの先頭バイトの意味にはなりません。 プリミティブは次のものから構成されます。

プリミティブおよびオペレータ の括弧付きグループ (括弧は Shell に特別の意味を持ち、必ずエスケープ する必要です。)

否定詞 (! または not)

接続詞 (and)

選択詞 (or) 否定詞は最も高い優先度を持ちます。 接続詞と選択詞は左から右に解釈され、同じ優先度を持ちます。 並列でない式の場合には、and は明示的に必要です。 キーワード無しで識別子が指定されると、 最後のキーワードが、仮定されます。 例えば、

not host vs and ace

は

not host vs and host ace

の省略であり、次のものと混用しないこと。

not ( host vs or ace )

式の引数は単一の引数としても、 複数の引数としてでも 都合のいい方法で tcpdump に渡すことができます。 通常、式にシェルのメタ文字が含まれている場合は、 単一の引用符を付けた引数として 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

ローカルホストとバークレーホスト間の 全てのトラフィックを出力します。

tcpdump net ucb-ether

インターネットゲートウェイ snup を通じた 全ての ftp トラフィックを出力します。 (式ではシェルが間違えて括弧を解釈しないように 引用付で囲むこと。)

tcpdump ’gateway snup and (port ftp or ftp-data)’

ローカルホストから、またはローカルホスト へのトラフィックを出力しません (他のネットワークにゲートウェイで 接続しているなら、決して自身のローカルネット に何も出力しません。)

tcpdump ip and not net localnet

ローカルホスト以外のホストでの各 TCP コネクションの 先頭および最終パケット (SYN および FIN パケット) を出力します。

tcpdump ’tcp[13] & 3 != 0 and not src and dst net localnet’

ゲートウェイ snup を通して 576 バイト以上の IP パケットを出力します。

tcpdump ’gateway snup and ip[2:2] > 576’

イーサネットのブロードキャスト またはマルチキャストを使って送信されない IP ブロードキャスト またはマルチキャストのパケット を出力します。

tcpdump ’ether[0] & 1 = 0 and ip[16] >= 224’

出力形式

tcpdump の出力はプロトコル依存です。 次に形式に関する簡単な説明と例を示します。 リンクレベルヘッダ リンクレベルヘッダが出力します。 イーサネットでは、 ソースアドレス、ディスティネーションアドレス、 プロトコル、パケット長が出力されます。 (注意: 次に述べる解説は RFC-1144 に記述する SLIP の圧縮されたアルゴリズム の知識を仮定しています。) SLIP リンクでは、方向の識別子 (I が入ってくる、 O が出ていく)、パケットタイプ、および圧縮情報が出力されます。 まず、パケットタイプが最初に出力されます。 三つのタイプがあり、ip、utcp、ctcp です。 ip パケットに関してはリンク情報以外は出力しません。 TCP パケットに関して、 接続識別子がタイプに続いて出力されます。 パケットを圧縮すると、 コード化されたヘッダが出力します。 特別のケースとして ∗S+n および ∗SA+n が出力され、 n はシーケンス番号 (またはシーケンス番号および ack) の変化量となります。 特別のケースでない場合、 ゼロまたはそれ以上の変更が出力されます。 変更は U (urgent pointer)、 W (window)、 A (ack)、 S (sequence number)、および I (packet ID) で示され、 デルタ値 (+n または −n) または 新しい値 (=n) が続く。 最終的に、パケットのデータ量および圧縮されたヘッダ長が出力します。 例えば、次の例では出力側の圧縮された TCP パケットを示し、 接続識別子を持っています。 ack は 6 ずつ変化し、シーケンス番号は 49 ずつ、 そしてパケット ID は 6 ずつそれぞれ変化しています。 3 バイトのデータと 6 バイトの短縮ヘッダがあります。

O ctcp ∗ A+6 S+49 I+6 3 (6)

ARP/RARP パケット arp/rarp 出力はリクエストタイプおよび その引数を示します。 以下のような説明で明らかでしょう。 ホスト rtsg からホスト csam への rlogin の先頭から取った簡単な例を示します。

arp who-has csam tell rtsg
arp reply csam is-at CSAM

最初の行は arp パケットを送った rtsg がインターネットホスト csam のイーサネットアドレスを要求することを示します。 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 パケット (注意: 次に述べる解説は RFC-793 に記述する TCP プロトコルに基づいています。 tcp に関して知らない場合には、 ここの説明も tcpdump もきっと対して役に立たないでしょう。) tcp プロトコルの通常の形式。

src > dst: flags data-seqno ack window urgent options

src および dst はソースおよびディスティネーションの IP アドレスおよびポートです。 flags は S (SYN)、 F (FIN)、 P (PUSH) または R (RST) または単一の  ‘.’ (フラグ無し)など から構成されます。 data-seqno はこのパケットデータ (次の記述を参照) で使用された あるシーケンス番号の範囲を示します。 ack は、 このコネクション上での片方向の次のデータパケットのシーケンス番号を示します。 window は、このコネクション上での片方向の受信バッファのバイト数を示します。 urg はパケット内に ‘urgent’ (緊急) データがあることを示します。 options は単一の括弧で囲まれる tcp オプションを示します。 (例として、 <mss 1024>) src、dst および flags は常に存在します。 その他フィールドはパケットの tcp プロトコルに 依存し、適当な場合に出力されます。 ホスト rtsg からホスト csam への rlogin の 先頭部を示します。

rtsg.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

最初の行は、 rtsg 上のポート 1023 からパケットを csam 上のポート login に送ることを示します。 S は SYN フラグが設定されていることを示します。 パケットシーケンス番号は 768512 で、 データを含みません。 (表記 first:last(nbytes) で、 last を含まないユーザデータ nbytes バイトまでの シーケンス番号 first を示します。) ピギーバックされた ack は無く、 有効なウィンドウサイズは 4096 バイトで、最大セグメントサイズオプション が 1024 バイトを要求しています。 rtsg の SYN に関するピギーバック ack を含むものを除いて、 同様のパケットにて返信します。 そして、 rtsg は csam の SYN を ack します。 ‘.’ はフラグが設定されていないことを示します。 パケットにデータが無いので、 データシーケンス番号もありません。 ack シーケンス番号は小さな整数 (1) であることに 注意すること。 最初には、 tcpdump は tcp「会話」を参照しています。 パケットからシーケンス番号を出力します。 「会話」の次のパケットから、「会話」が進むにつれ、 現在のパケットのシーケンス番号 とこの最初のシーケンス番号との差が出力されます。 このことは、 最初のパケットからのシーケンス番号 が会話のデータストリーム内の相対的バイト位置として 解釈されることを示します (最初のデータバイトの各方向が ‘1’)。 −S はこの機能を打ち消し、オリジナルのシーケンス番号を出力します。 6 番目の行では、 rtsg は csam に 19 バイトのデータを送る (会話の rtsg  csam 側での 2 番目から 20 番目のバイト)。 PUSH フラグはパケットに設定されます。 7 番目の行では、 バイト 21 を含まない、 rtsg によって送られたデータを受信したことを csam は示します。 このデータのほとんどは、 csam の受信ウィンドウが 19 バイト小さくなったので、 ソケットバッファ内に存在します。 csam もこのパケット内で rtsg に 1 バイトデータを 送ります。 8 番目と 9 番目の行では、 csam は 2 バイトの urgent データを送り、データを rtsg に送り出します。 UDP パケット UDP 形式はこの rwho パケットを例に示します。

actinide.who > broadcast.who: udp 84

これはホスト actinide 上のポート who が ホスト broadcast 上のポート who にデータグラム udp、 つまりインターネットブロードキャストアドレスを送ります。 パケットは 84 バイトのユーザデータを保持します。 いくつかの UDP サービスは認められており (ソースまたは ディスティネーションポート番号から) より上位のレベルのプロトコル情報が出力されます。 特に、Domain Name サービスリクエスト (RFC-1034/1035) および Sun NFS に対する RFCコール (RFC-1050) などです。 UDP ネームサーバリクエスト (注意: 次に述べる解説は RFC-1035 に記述する Domain Service プロトコル の知識を仮定しています。 プロトコルをあまり知らない場合には、 この記述はなにを言っているかわからないかも知れません。) ネームサーバリクエストは次のようになります。

src > dst: id op? flags qtype qclass name (len)

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

ホスト h2opolo は名称 ucbvax.berkeley.edu. に関連する アドレスレコード (qtype=A) を helios 上の ドメインサーバに要求します。 キュエリー ID は ‘3’。‘+’ は recursion desired フラグが 設定されたことを示します。 キュエリー長は 37 バイトで、UDP および IP プロトコルヘッダを 含みません。 キュエリー動作は普通のもの、query であり、 op フィールドは省略されます。 op が他に何か含まれている場合、それらは、‘3’ および ‘+’ の間に出力します。 同様に、qclass も普通のもの、C_IN であり、 省略されます。 他のクラスが指定された場合は A の直後に出力されます。 いくつかの異常がチェックされ、 四角括弧に囲まれたフィールドに表示されます。 query が回答を保持している場合、 ネームサーバまたはオーソリティセクション ancount、 nscount、 または arcount などは ‘[na]’、‘[nn]’ または ‘[nau]’ をして出力され、 n が適切な値となります。 応答ビットがセットされる場合 (AA、RA または rcode) と、 ‘must be zero’ ビットの 2 および 3 バイトめにセットされると、 ‘[b2&3=x]’ が出力され、x はヘッダバイト 2 および 3 の 16 進数となります。 UDP ネームサーバレスポンス ネームサーバレスポンスは次のようになります。

src > dst: id op rcode flags a/n/au type class data (len)

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain∗ 0/1/0 (97)

最初の例では、 helios はキュエリーに対して、 3 つの回答レコード、3 つのネームサーバレコード および 7 つのオーソリティレコード を持つ h2opolo から ID 3 を回答します。 最初の回答レコードはタイプ A (アドレス) および そのデータはインターネットアドレス 128.32.137.3 です。 回答の全体のサイズは UDP および IP ヘッダを含まない、 273 バイトです。 op (Query) および回答コード (NoError) は省略され、 A レコードのクラス (C_IN) となります。 二番目の例では、 helios はキュエリー 2 に対して、 回答無しで、存在しないドメイン (NXDomain) の回答コード、 一つのネームサーバ、そしてオーソリティレコード 無しで回答します。 ∗ は authoritative answer ビットがセットされていることを示します。 回答がなかった場合、タイプ、クラス、データは出力されません。 他のフラグキャラクタは − (再帰可能、RA、セットされず) および ‘|’ (切り捨てられたメッサージ、 TC、セット) などがあります。 ‘question’ セクションが実際に一つのエントリを保持する場合、‘[nq]’ が 出力されます。 ネームサーバリクエストおよび回答は大きくなりがちであり、 96 バイトのデフォルト snaplen が出力するパケット 十分ではないことに注意すること。 ネームサーバトラフィックを十分調査する場合、 snaplen を増やすために −s フラグを使用することが必要でしょう。 ‘−s 128’ は十分に機能します。 NFS リクエスト Sun NFS (Network File System) のリクエスト およびリスポンスの表示は次のようになります。

src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len

vs.e2766 > helios.nfs: 136 readdir fh 6.5197 8192 bytes @ 0
helios.nfs > vs.e2766: reply ok 384
vs.e2767 > helios.nfs: 136 lookup fh 6.5197 ‘RCS’

最初の行では、 ホスト vs は ID e2766 を持つトランザクションを helios に送ります。(src ホストに続く番号 がトランザクション ID であり、ソースポートでない ことに注意。) リクエストは 136 バイトであり、UDP および IP ヘッダ を含みません。 動作はファイルハンドル (fh) 6.5197 上の readdir (読み出し ディレクトリ) です。 8192 バイトが読まれ、オフセット 0 で始まります。 helios は 384 バイトデータで ‘ok’ と回答します。 (Sun’s RPC プロトコルの設計はリスポンスの解析を困難にして いますが、このさい関知しません。) 3 行目では、vs が helios に対して ディレクトリ 6.5197 の名称 ‘RCS’ を調査すること を要求します。 出力データの形式は動作のタイプに依存することに注意すること。 NFS プロトコルの仕様に従って読むと、 読めば明らかな形式 (少なくとも、私にとっては) になりがちです。 NFS リクエストは大変大きくなり、 snaplen を大きくしないかぎり上記のものが出力しないことに 注意すること。 NFSトラフィックを見るためには、−s 192 を使用することを お薦めします。 KIP AppleTalk (DDP in UDP) UDP データグラムにカプセルされた AppleTalk DDP パケットが カプセルを外され、DDP パケットとしてダンプされます (すなわち全てのUDP ヘッダ情報が破棄されます。) ファイル /etc/atalk.names は AppleTalk のネットワーク番号およびノード番号を 名称に変換する際に使用されます。 このファイル内の行は次のような形式です。

numbername
1.254ether
16.1icsd-net
1.254.110ace

先頭の 2 行は AppleTalk ネットワークの名称を指定します。 3 行目は特定のホストの名称 (ホストは番号内の 3 番目の 8 進数で ネットと区別され、 − ネット番号 must は 2 つの 8 進数、 ホスト番号 must は 3 つの 8 進数を保持しなければなりません。) 番号と名称は空白 (空白またはタブ)で区切られなければなりません。 /etc/atalk.names ファイルは空白行またはコメント行 (その行は # で始まる) とを含むことができます。 AppleTalk アドレスは次のような形式となります。

net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

(/etc/atalk.names が存在しない、または該当する AppleTalk のホスト/ネット番号が見つからない場合、 アドレスは数字形式で出力します。) 最初の例では、ネット 144.1 でノード 209 上の NBP (DDP ポート2) は、ネット icsd でノード 112 のポート 220 上のパケットを待とうしています。 二番目の行では、 ソースノードがストリングであることを除いて、同じであることが 判ります (‘office’)。 三番目の行では、ネット jssmag でノード 149 上のポート 235 から icsd ネットの NBP ポートのブロードキャストへの送信を示す。 (ブローキャストアドレス (255) はホスト番号無しのネット名称で 示されます。− この理由から、ノード名とネット名を /etc/atalk.names 内で区別するのに有効。) NBP (name binding protocol) および ATP (Appletalk transaction protocol) パケットは解釈されます。 他のプロトコルはプロトコル名 (プロトコルとして 名称が登録されていなければ、番号) およびパケットサイズを ダンプします。

NBP packets は次の例のような形式となります。

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。 2 番目の行は、このリクエスト (同じ ID を持つことに注意) に対する ホスト jssmag.209 からのリスポンスがポート 250 上に リソース名 "RM1140" のレーザライタが登録されていることを示します。 3 番目の行は同じリクエストに対するリスポンスが ホスト techpit がポート 186 上に "techpit" と登録された レーザライタを持っていることと示します。

ATP packet の形式は次のようになります。

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.133 > helios.132: atp-req∗ 12267<0-7> 0xae030002

jssmag.209 は 8 つまでのパケット(‘<0-7>’)をリクエスト することで、ホスト helios のトランザクション ID 12266 を要求します。 その行の最後の 16 進数はリクエスト内の ‘userdata’ フィールドの値。 helios は 8 つの 512 バイトパケットでリスポンスします。 トランザクション ID に続く ‘:digit’ はトランザクション内の パケットシーケンス番号を示し、 括弧内の数字は、atp ヘッダを除くパケット内のデータ量を示します。 パケット 7 上の ∗ は EOM ビットがセットされたことを示します。 そして、jssmag.209 はパケット 3 & 5 が再送されること をリクエストします。 helios はそれらを再送し、jssmag.209 はトランザクション を解放します。 最終的には、jssmag.209 は次のリクエストを示します。 リクエスト上の ∗ は XO (‘exactly once’)がセットされてないことを示します。

IP フラグメンテーション Fragmented Internet データグラムは次のように出力します。

(frag id:size@offset+)
(frag id:size@offset)

(最初の形式はさらにフラグメントがあることを示します。 次はこれが最後のフラグメントであることを示します。) Id はフラグメント ID (16 進数)。size は、 IP ヘッダを除くフラグメントのサイズ (バイト) を示します。 offset はオリジナルデータグラム内の フラグメントオフセット (バイト) を示します。 フラグメント情報は各フラグメントパケットごとに出力します。 最初のフラグメントパケットはより上位レベルのプロトコル情報を含み、 フラグメント情報はプロトコル情報の後ろに出力されます。 2 番目以降のフラグメントは上位レベルのプロトコル情報は 含まず、フラグメント情報はソースおよびディスティネーションアドレスの後に 出力されます。 例えば、 CSNET を使った arizona.edu から lbl-rtsg.arpa への 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 シーケンス情報が出力される際には、 実際には 512 バイト (最初のフラグでは 308 バイト、 次では 204 バイト) になるにもかかわらず、 まるで 308 バイトのユーザデータしかないように表示されます。 シーケンススペース内の穴を探そうとしたり、 ack とパケットを一致させようとする場合、 これらに注意しなければなりません。 IP don’t fragment フラグを持つパケットの 最後には (DF) が付加されます。 タイムスタンプ デフォルトでは、全ての出力行の前にタイムスタンプが付加されます。 タイムスタンプは次のように現在時刻を示します。

hh:mm:ss.frac

そして、カーネルの時計同様の (例えば、 10ms on a NEWS) 精度を持ちます。 タイムスタンプはカーネルが最初に パケットを発見した時刻を示します。 イーサネットインターフェースが、 実際にイーサネットの線からパケットを受け取った時刻と カーネルが ‘新しいパケット’ の受信割り込みされた時間との タイムラグについては考慮しません。 (ただし、NEWS の時計の場合には 大した問題にはなりません。)

関連事項

bpf(4)

著者

Van Jacobson (van@helios.ee.lbl.gov)、 Craig Leres (leres@helios.ee.lbl.gov)、 Steven McCanne (mccanne@helios.ee.lbl.gov)、 Lawrence Berkeley Laboratory, University of California, Berkeley, CA のすべての方々. 

バグ

NEWS の時計の性能はあまり優れたものではありません (10 ms)。 タイムスタンプを使用して何か重要なパフォーマンスに関する操作を行う 場合 (パケットの到着時刻のようなこと) には、 パケット自体をゆっくりと生成させる様な別の方法を 見つけるのがベストです。 NIT はユーザの出力のトラフィックを見るようにできていませんが、BPF は 行っています。 後者を採用すること薦めます。 IP フラグメントをリアセンブルしようとし、 少なくとも上位のプロトコルに渡す長さを計算しようとしています。 ネームサーバのリバースキュエリーは正しくダンプされません。 回答部内の実際のキュエリーでなく (空の) クエスチョン部が出力されます。 リバースのキュエリー自身がバグではないかと考えられるので、 tcpdump をフィックスするよりもリバースキュエリーを生成するプログラムを 直す方が良いと思います。 Apple Ethertalk DDP パケットは KIP DDP パケット同様に簡単にダンプできそう ですが、実際にはそうではありません。 たとえ、Ethertalk (そうはしないが) の使用を試みようとしても、 LBL はネットワーク上での Ethertalk の使用を認めないでしょう。 すなわちこのコードをテストする方法がないわけです。 夏時間と標準時間をまたがって使用すると、 タイムスタンプは、おかしな時間を示します。 (時刻帯の変更は無視されます)。

NEWS-OSRelease 4.2.1R