名称

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” or “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 option で出力できます。 file に “−” を指定すると、 標準出力が使用される。

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

式

どのパケットをダンプするかを選択する。 式を指定しないと、 ネット上の全てのパケットが出力される。 もしくは、式が ‘真’ であるパケットのみダンプされる。 式は一つ以上のプリミティブで構成される。 通常、プリミティブは前に一つ以上の 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 は、一つ、二つ、または四つであり、 デフォルトとは、一です。 キーワード 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 は (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 プロトコルの設計はリスポンスの解析を困難にして いますが、このさい関知しません。) 三行目では、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 は二つの 8 進数、 ホスト番号 must は三つの 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。 二番目の行は、このリクエスト (同じ ID を持つことに注意) に対する ホスト jssmag.209 からのリスポンスがポート 250 上にリソース名 "RM1140" の レーザライタが登録されていることをしめす。 三番目の行は同じリクエストに対するリスポンスが ホスト 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) and Steven McCanne (mccanne@helios.ee.lbl.gov), all of Lawrence Berkeley Laboratory, University of California, Berkeley, CA. 

バグ

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

NEWS-OSRelease 4.1C