リナックスコマンド

tcpdumpのヘルプ・マニュアル

日本語 英語

• help
• man

tcpdump --help

man tcpdump

TCPDUMP(1) TCPDUMP(1) 名前 tcpdump - ネットワークのトラフィックをダンプする 書式 tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ] [ -i interface ] [ -m module ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ expression ] 説明 tcpdump は真偽値の 条件式 に一致するネットワークインターフェイス上のパ ケットのヘッダを表示する。 nit か bpf を用いる SunOSの場合: tcpdump を動作させるためには /dev/nit か /dev/bpf* に 読み込み権限を持っている必要がある。 dlpi を利用する Solaris の場合: 仮想ネットワークデバイス、たとえば /dev/le といったもの に読み込み権限を持っている必要がある。 dlpi を利用する HP-UX の場合: 実 行者が root であるか、または root に setuid してインストールされてい る 必要がある。 snoop を用いる IRIX の場合: 実行者が root であるか、または root に setuid してインストールされている必要がある。 Linux の場合: 実 行 者が root であるか、または root に setuid してインストールされている 必要がある。 Ultrix および Digital UNIX の場合: まず、スーパーユーザ が pfconfig(8) を用いて無差別透過モード(promicuous-mode)を有効にする必要が ある。その後は一般ユーザが tcpdump を実行可能である 。 BSD の 場 合: /dev/bpf* に対する読み込み権限が必要。 オプション -a ネットワークとブロードキャストアドレスを DNS 名に変換する。 -c count 個のパケットを受信したのちに終了する。 -d コンパイルされたパケットマッチングコードを人間が読める形式で標準 出力にダンプし、終了する。 -dd パケットマッチングコードを C 言語の一部として利用可能なかたち で ダンプする。 -ddd パケットマッチングコードを 十進数でダンプする(count が先行する) 。 -e 各ダンプ行にリンクレベルヘッダを表示する。 -f 「外部の」インターネットアドレスをシンボルではなくて数値で表示す る (このオプションは馬鹿な Sun の yp サービスを迂回することを意 図している — Sun の yp サービスはローカルではないインターネッ ト ア ド レスを変換しようとすると永久に動作が停止してしまうバグがあ る)。 -F フィルター条件式の指示入力として file を用いる。この後ろにコマン ドラインで条件式による指示が与えられても無視する。 -i interface を監視する。指示のない場合は tcpdump はシステムのイン ターフェイスのリストから最も小さい番号で有効になっているもの( 但 し ループバックは除く)を探し出す。指示されたインターフェイスが存 在しない場合はもっとも近いものが選択される。 -l 標準出力をバッファリングする。データを蓄積しながら監視する場合に 有効である。使用例: ‘‘tcpdump -l | tee dat’’ or ‘‘tcpdump -l > dat & tail -f dat’’. -n アドレス(ホストアドレス、ポート番号など)を名前に変換しない。 -N ホストのドメイン名を表示しない。つまりこれを使用した場合 tcpdump は‘‘nic.ddn.mil’’ と表示するかわりに ‘‘nic’’ と表示する。 -m SMI MIB モジュールをファイル module から読み込む。複数の MIB モ ジュールを読み込む目的で、このオプションを複数回使用することも出 来る。 -O パケットマッチングコードオプティマイザを停止する。これはオプティ マイザのバグを疑っている場合にのみ有益である。 -p 無差別透過モードを 利用しない。しかしながら、他の理由でインタ ー フェイスが無差別透過モードになってしまうこともあることに注意する こと。このため ‘-p’ オプションは ‘ether host {loca-lw-addr} or ether broadcast’ の省略形としては使用できない。 -q すばやい(というか静かな)出力。限定されたプロトコルの情報しか出力 しないので、出力行は短いものとなる。 -r パケットを(-w オプションで作成した)fileから読み込む。 fileとして ‘‘-’’ を指定した場合には標準入力が利用される。 -s デ フォルトの 68 バイト(SunOS の NIT では最小は実際には 96 バイ ト)に代わって snaplen バイトをおのおののパケットから取り出し利用 する。 IP, ICMP, TCP, UDP については 68 バイトあれば十分だが、ネ ームサーバや NFS の情報には足りないかもしれない(後述)。 snapshot 制限のために後ろが切り捨てられたパ ケ ッ ト は 出 力 時 に‘‘[|proto]’’ の形式で示される。ここで proto は切り捨ての生じた レベルに対応するプロトコルの名前である。大きな snapshot を取ろう とするとパケットを処理する時間は増加し、またこちらのほうが重要だ が、バッファに溜めることができる量が減少してしまう点に注意するこ と。すなわちパケットが失なわれる可能性もある。プロトコルの情報が 得られる必要最小限の snaplen とすること。 -T "expression"(条件式) で選択されたパケットに指示された type で の 翻訳を指示する。現在有効な type は rpc (Remote Procedure Call)、 rtp (Real-Time Applications protocol)、 rtcp (Real-Time Applica- tions control protocol)、 snmp (Simple Network Management Proto- col), vat (Visual Audio Tool)、 wb (distributed White Board)。 -R ESP/AH パケットが古い定義(RFC1825 〜 RFC1829)に従っていると仮 定 す る 。このオプションが指定されると、tcpdump は relplay preven- tion フィールドを表示しない。 ESP/AH の定義にはプロトコルバー ジ ョ ンフィールドがないので、 tcpdump は ESP/AH プロトコルのバージ ョンを推論することが出来ない。 -S TCP シーケンス番号を相対値ではなくて絶対値で表示する。 -t ダンプ行に時間情報を表示しない。 -tt ダンプ行に表示する時間情報を整形しない。 -v (ちょっとだけ)詳細な出力。IP パケットにおける 生存時間(TTL) やサ ービスの種類の情報などを表示する。 -vv もっと詳細な出力。NFS応答パケットにおける付加フィールドなどを表 示する。 -vvv さらに詳細な出力。例えば、telnet SB ... SE オプションは全て表 示 さ れる。 -X オプションも指定されると、telnet オプションは 16 進 表示でも表示される。 -w パケットを解析、表示するかわりに生のまま file に書き出す。このフ ァ イ ル は あとで -r オプションを用いれば表示することができる。 file として ‘-’ を指示すると標準出力を用いる。 -x (リンクレベルヘッダを除く)すべてのパケットを 16 進で表示する。パ ケット全体と snaplen バイトの小さい方だけを表示する。 -X 16 進表示されるときに、 ASCII 文字も表示する。従って、 -x オプシ ョンもセットされると、パケットは 16 進と ASCII 文字の両方で表 示 される。これは新しいプロトコルを解析するときに非常に便利である。 -x オプションが設定されていなくても、パケットの部分によっては 16 進と ASCII 文字の両方で表示されることもある。 expression(条件式) ダンプするパケットの種類を選択する。 expression が与えられないと きは、ネットワーク上のすべてのパケットをダンプする。そうでなけれ ば、expression が‘true’(真) となるパケットだけをダンプする。 expression は一つ以上の primitive(要素) から成る。要素は一つ以上 の修飾子を先行する一個の id (名前でも番号でもよい)である。修飾子 には三つの種類がある: type 修飾子は id名または id 番号が指すものの種類を示す。利用可 能なものは host, net, port である。例: ‘host foo’ 、‘net 128.3’、‘port 20’。 type 修飾子が無い場合は、 host が指示 されているものとみなす。 dir 修飾子は id に向けて、または id へ、のどちらかあるいは 両 方 の 通 信 方向を特定する。方向として指示できるのは src, dst, src or dst, src and dst である。例、 ‘src foo’、‘dst net 128.3’、‘src or dst port ftp-data’。 dir 修飾子が指定 されない場合は src or dst が指示されているものと み な す 。‘null’ リンク層(すなわち slip のようなポイントツーポイ ントプロトコル)においては、方向を指定する修飾 子 と し て inbound と outbound も利用可能である。 proto 修飾子は一致する特定のプロトコルに制限する。利用可能なプ ロトコルは以下の通り: ether, fddi, mopdl, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, icmp, icmp6, tcp, udp。例: ‘ether src foor’、‘arp net 128.3’、‘tcp port 21’ 。 proto 修飾子が指示されない場合は type と矛盾しない範囲 で全てのプロトコルが指示されているものとみなす。例: ‘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’ を意味する。 [‘fddi’は実際には ‘ether’ の別名である;解析時に‘‘特定のネット ワ ー ク イ ン ターフェイスが利用するデータリンク層’’として扱われる 。FDDI ヘッダーはイーサネット的なソースおよびディスティネーシ ョ ンアドレスを含み、またイーサネット的なパケットタイプも含むので、 これらの FDDI フィールドをイーサネットの同類として選 別 で き る 。FDDI ヘッダにはその他のフィールドも含まれるが、これについては フィルタの条件式で明示的に指示することはできない。] 上記に加えて、特別な‘要素’を示すキーワード が あ る 。 gateway, broadcast, less, greater とarithmtic expression(数値による条件 式)である。これらについてはこのあとで記述する。 もっと複雑なフィルタ条件式は and, or, not と各要素の組合せで表現 できる。例:‘host foo and not port ftp and not port ftp-data’。明 示的な修飾子は省略してタイプ数を減らすことができる。例:‘tcp dst port ftp or ftp-data or domain’ は ‘tcp dst prot ftp or tcp dst port ftp-data or tcp dst prot domain’と全く同じ意味である。 許容される要素の組み合わせは以下の通り。 dst host host パケットの IPv4/v6 ディスティネーションフィールドが host であるとき真。アドレスでも名前でもよい src host host パケットの IPv4/v6 ソースフィールドが host であるとき真。 host host パケットの IPv4/v6 ソースまたは IP/v4/v6 ディスティネーシ ョ ンフィールドが host であるとき真。上記の各 host を示す 条件式には ip、arp、rarp、ip6 のいずれかを付加してもよ い 。 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 をゲートウェイとしているときに真。すなわ ち、イーサネットソース/ディスティネーションア ド レ ス は host であるが、 IP ソース/ディスティネーションアドレスは host ではないときのこと。 host は 名 前 で あ り 、 ま た /etc/hosts と /etc/ethers の両方に記載されていなければな らない (この条件式は host / ehost それぞれを名前か番号 で 記述する ether host ehost and not host host と同等である)。この文法は今のところ IPv6 を有効にした設定 では正しく動作しない。 dst net net パケットの IPv4/v6 ディスティネーションアドレスが net ネ ッ トワークを含んでいるときに真。net は/etc/networks に記 載される名前かネットワーク番号である( networks(4) を参照) 。 src net net パ ケットの IPv4/v6 ソースアドレスが net ネットワークのも のであるときに真。 net net パケットの IPv4/v6 ソース/ディスティネーションアドレス が net ネットワークであるときに真。 net net mask mask IP アドレスが netmask でマスクして net に一致するときに真 。src か dst で修飾してもよい。この文法は net が IPv6 の ときには不正であることに注意。 net net/len IPv4/v6 アドレスが len ビットのnetmask でマスクして net に一致するときに真。src か dst で修飾してもよい。 dst port port パケットが ip/tcp か ip/udp か ipv6/tcp か ipv6/udp で あ る場合で、行き先の port 番号が port であるときに真。 Port は番号の数値か /etc/services による名前を 利 用 で き る( tcp(4P) と udp(4P) を参照のこと)。名前が利用されている場 合は port 番号と protocol の両方で照合される。番号か多 重 に 定義されている名前が利用されている場合は port 番号だけ が照合される (例: dst port 513 は tcp/login と udp/who の 両 方の通信を表示するし、 port domain は tcp/domain と udp/domain の両方を表示する)。 src port port パケットが port 番号のポートをソースにしているとき真。 port port パケットのソースかディスティネーションポートが port で あ る とき真。この port を指定する条件式は tcp と udp のキー ワードを付加してもよい: tcp src port port は port をソースとする tcp のパケットのみに一致する。 less length パケットが length 以下のときに真。これは下記と同じ: len <= length. greater length パケットが length 以上のときに真。これは下記と同じ: len >= length. ip proto protocol パケットが protocol 型のプロトコルの IP パケット( ip(4P) を参照)のものであるとき真。 protocol として利用できるのは 数値と icmp、 igrp、udp、nd、tcp である。tcp、udp、 icmp はキーワードでもあるので、バックスラッシュ(\)でキーワード として解釈されるのを回避する必要がある。C-Shell で は \\ を 使う。この要素はプロトコルヘッダチェインを追跡しないこ とに注意。 ip6 proto protocol パケットがprotocol型の IPv6 パケットであるときに真。こ の 要素はプロトコルヘッダチェインを追跡しないことに注意。 ip6 protochain protocol パ ケットが IPv6 パケットであり、そのプロトコルヘッダチェ インの中にprotocol型のプロトコルヘッダがある場合に真。 例 えば、 は プロトコルヘッダチェインに TCP プロトコルを持つ IPv6 パケットに一致する。パケットには、例えば認証ヘッダ、ル ー テ ィングヘッダ、 hop-by-hopヘッダなどがIPv6 ヘッダと TCP ヘッダの間に含まれるかもしれない。この要素が作り出す BPF コードは複雑で、 tcpdumpの BPF 最適化コードで最適化できな い。そのため、少し遅いかもしれない。 ip protochain protocol ip6 protochain protocol と同様だが、これは IPv4 のため の ものである。 ether broadcast パ ケ ッ ト が イーサネットのブロードキャストであるとき真 。ether はなくてもよい。 ip broadcast パケットが IP ブロードキャストパケットであるとき真。こ れ は全て 0 と 全て 1 の両方のブロードキャスト形式に対応し、 さらにサブネットマスクにも対応している。 ether multicast パケットがイーサネットのマルチキャストであるとき真。ether は なくてもよい。これは ‘ether[0] & 1 != 0’の省略記法であ る。 ip multicast パケットが IP のマルチキャストであるとき真。 ip6 multicast パケットが IPv6 マルチキャストパケットであるとき真。 ether proto protocol パケットが ether の protocol 型のものであるとき真。 pro- tocol には番号か ip、ip6、arp、rarp の名前が利用可能。こ れらの識別子はキーワードでもあるので、バックスラッシュ(\) で キ ー ワードとして解釈されるのを回避する必要がある。 [ FDDI (たとえば ‘fddi protocol arp’)の場合、プロトコルの識 別 方法は 802.2 Logical Link Control (LLC) ヘッダーによる 。それは通常は FDDI ヘッダーの先頭に置かれている。tcpdump は プロトコル識別子でフィルターする場合に、全ての FDDI パ ケットは LLC ヘッダーを持っていて、その LLC ヘッ ダ ー は SNAP と呼ばれる形式になっているものとみなす。 ] decnet src host DECNET においてソースアドレスが‘‘10.123’’のようなアドレス や DECNETのホストネームの形式で指示される host と一致する と き 真 。[DECNETのホストネーム形式は DECNETに接続された ultrix システムにおいてのみ利用可能である。] decnet dst host DECNETにおいてディスティネーションアドレスが host に一 致 するとき真。 decnet host host DECNET において、ソースまたはディスティネーションアドレス が host に一致するときに真。 ip, ip6, arp, rarp, decnet 下記において: ether proto p p をそのいずれかのプロトコルとするのと同等である。 lat, moprc, mopdl 下記において: ether proto p p をそのいずれかのプロトコルとするのと同等である 。 tcp- dump はこれらのプロトコルの解析方法は正確には知らない点に 注意すること。 tcp, udp, icmp 下記において: ip proto pip6 proto p p をそのいずれかのプロトコルとするのと同等である。 expr relop expr 関係式が成り立てば真。relop(演算子)は >、<、>=、<=、=、!= のいずれか一つであり、expr(表現) は整定数による数値表現 ( 表現方法は標準的な C の文法にしたがう)、標準的な二項演 算 子[+ 、-、*、/、&、|]、長さ演算子、パケットデータアクセス 演算子のいずれか。パケット内のデータに対して適用するに は このように記述する: proto [ expr : size ] proto は ether、fddi、ip、arp、rarp、tcp、udp、icmp、ip6 のいずれかで操作対象のプロトコル層を指示する。 tcp, udp とその他の上位プロトコル層は IPv4 でのみ利用でき、 IPv6で は利用できないことに注意。(これは将来修正されるだろう) 指 示 されたプロトコル層についてのバイトオフセットは expr で 指定する。 size を指示する場合は注目するフィールドでの バ イ ト数で指示するが、それは one、two また four のいずれか を用いる。指示のない場合は one であるとみなす。長さ演算子 は キ ーワード len で示され、パケット長を与える。たとえば 、‘ether[0] & 1 != 0’という条件式はすべてのマルチキャスト による通信をとらえる。‘ip[0] & 0xf != 5’ という条件式はす べてのオプション付きの IP パケットをとらえる。‘ip[6:2] & 0x1fff = 0’はフラグメント化されていないデータグラムか 0 番の(最初の)フラグメントだけを表示する。なお、この条件 は tcp と udp への適用を暗示している。さらに tcp[0] は TCP ヘッダ の最初のバイトを意味するが、フラグメントの先頭のバ イトではありえない。 要素を複合させて用いる場合: 括弧でグループ分けする要素と演算子(括弧はシェルにとっても 特別な意味を持つのでたぶんエスケープしなければならない だ ろう)。 否定 (‘!’ or ‘not’). 結合 (‘&&’ or ‘and’). 択一 (‘||’ or ‘or’). 否定はもっとも高い優先度をもつ。択一と結合は同等の優先度を持ち、 左から右へ評価される。結合は併記するだけでなく明示的な and ト ー クンが必要なことに注意すること。 キーワードなしで識別子があらわれた場合、直前にあらわれたキーワー ドを伴っているとみなされる。たとえば、 not host vs and ace は not host vs and host ace の省略であり、これは not ( host vs or ace ) とは違う。 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 ロ ーカルネットのホスト群とネットワーク Berkeley のホスト群との通信を表 示する: tcpdump net ucb-ether インターネットへのゲートウェイの snup を通過する全ての ftp 通信を表示す る(条件式はシェルが括弧を(誤って)解釈するのを避けるためにクオートされて いる点に注意せよ): tcpdump ’gateway snup and (port ftp or ftp-data)’ ローカルホストへの入出力の通信を除外して表示する(他のネットワークへのゲ ートウェイであるとして、ローカルネットワークを除外する例): tcpdump ip and not net localnet ロ ー カ ル ホ スト以外が関わる TCP 通信の 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’ echo 要求/応答(つまり ping のパケット)以外のすべての ICMP パケットを表 示する: tcpdump ’icmp[0] != 8 and icmp[0] != 0" 出力形式 tcpdump の出力はプロトコルに依存する。下記は大部分の様式の簡単な解説 と 例である。 リンクレベルヘッダ ‘-e’ オプションが指示されている場合、リンクレベルヘッダが表示される。イ ーサネットではソースおよびディスティネーションのアドレスとパケット長 が 表示される。 FDDI のネットワークにおいては ’-e’ オプションにより tcpdump は、ソース およびディスティネーションのアドレスとパケット長からなるフレーム制御 フ ィールドを表示する。(フレーム制御フィールドはパケットの残りの部分の解釈 の制御をおこなう)。(IP データグラムを含むような)通常のパケットは優先 度 0 から 7 を持つ‘async’ パケットである;たとえば ‘async 4’。このようなパ ケットは 802.2 LLC を含むとみなされる。LLCヘッダはそれが ISO データグラ ムやいわゆる SNAP パケット でない ならば、表示される。 ( 注:以下の記述は RFC-1144 による SLIP 圧縮アルゴリズムを理解しているも のとみなして記述してある)。 SLIP 接続では、方向指示(‘‘I’’が入力、‘‘O’’が出力)、パケットタイプと圧縮 情報が表示される。最初にパケットタイプが表示される。タイプには ip、utcp 、ctcp の三種類がある。 ip パケットについてこれ以上のリンク情報は表示さ れ ない。 TCPパケットは接続識別子が次に表示される。パケットが圧縮されて いる場合はその符号化されたヘッダが表示される。 *S+n、*SA+n と表示される 特別な状態もある。ここで n はシーケンス番号(またはシーケンス番号と ack) が何回変更されたかを示す。特別な場合でなければ、ゼロかまたは変更の回 数 が 出力される。変更は U(urgent pointer)、W(windows)、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 一行目は rtsg が インターネットホスト csam のイーサネットアドレスを尋ね る arp パケットを送信した様子。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 で実行すると最初のパケットがブロードキャス ト で 二 番 目 は point-to-point であることが見てとれる: RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM 最 初のパケットは source のイーサネットアドレスが RTSG で、ディスティネ ーションがイーサネットのブロードキャストであり、タイプフィールド は 16 進の 0806(ETHER_ARP)、全長が 64 バイトであることがわかる。 TCP パケット ( 注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものとみな して記述してある。もしこのプロトコルに通じていないようなら、この記述 だ けでなく、tcpdump そのものも役に立たないだろうが。) 一般的なフォーマットは下記の通り: 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 のオプションで <>で囲まれ る(例)。 src、dst と flags はかならず表示される。他のフィールドはパケットの TCP プロトコルヘッダに依存するので必要な場合のみ表示される。 これはホスト rtsg から csam へのrlogin の開始時の一部。 rtsg.1023 > csam.login: S 768512:768512(0) win 4096 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 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 の TCP ポート番号 1023 から csam の login ポートへの送信 パケットの表示である。S は SYN フラグがセットされていることを示す。パケ ットのシーケンス番号は 768512 でこのパケットはデータを含まない。(このよ うに nbytes バイトのユーザデータを含むシーケンス番号 first か ら 、last (last は含まれない)を示すために ‘first:last(nbytes)’と表記する)。またこ のパケットには ack は設定されておらず、受信 window は 4096 バイト、最大 セグメントサイズ(mss)オプション が 1024 バイトに設定されていた。 これに対して、csam は rtsg の SYN に対する ack を含む他は同等の内容のパ ケットを返している。そこで、rtsg は csam の SYN に ack 応答を返す 。‘.’ は フラグがセットされていないことを示す。このパケットにはデータが含まれ ないので、シーケンス番号もない。ack 応答のシーケンス番号は小さな整数 1 である点に注意すること。最初に tcp の「会話」を見いだすと、tcpdump はそ のパケットのシーケンス番号を出力する。その会話のパケットからは、その シ ー ケンス番号と初期化されたシーケンス番号との差異が表示される。これは最 初以外のシーケンス番号はその会話のデータグラムにおける相対的なバイト 位 置として解釈できることを意味する (各データグラムは 1 から始まる)。 ’-S’ オプションはこの機能を無視して、本来のシーケンス番号を出力する。 6 行目で rtsg は scam へ 19 バイト(rtsg から csam の方向へ、2 バイト 目 か ら 20 バイト目まで) のデータを送る。このパケットには PUSH フラグが設 定されている。7 行目で、 csam は rtsg が送信したデータを受信した、と 言 っ ているが、これには 21 バイト目は含まれない。csam の受信 window が 19 バイト小さくなっていることから、このデータはソケットバッファに留まっ て いると推測される。csam はまた 1バイトのデータを rtsg に送信する。8 行目 と 9 行目とで csam は urgent および pushed 付きのパケ ッ ト 2 バ イ ト をrtsg へ送信している。 もし、snapshot が小さすぎて tcpdump が TCP ヘッダの全てを捉えられなかっ た場合は、できるだけの解釈をして、その残りには解釈不能だったものがあ る こ とを示すために ‘‘[|tcp]’’と表示する。ヘッダに意味不明なオプション(た とえば、小さすぎたり、ヘッダよりも長かったりする length とか)が設定され て いた場合は、tcpdump は ‘‘[bad opt]’’と表示し、それ以上のオプション解 析を中止する(それがどこから始められるかわからないので)。ヘッダ長がオ プ シ ョンを送信したことを示しているのに、 IP データグラム長はそこにオプシ ョンを含められないことを示す場合は tcpdump は ‘‘[bad hdr length]’’と 表 示する。 UDP パケット UDP はこの rwho のパケットで説明する: actinide.who > broadcast.who: udp 84 こ れ は ホ ス ト actinide の who のポートから UDP データグラムがホスト broadcast すなわちインターネットブロードキャストアドレスの who のポート へ 送られたことを表示している。パケットはユーザデータ 84 バイトを含んで いる。 いくつのかの UDP サービスに関しては(そのソースまたはディスネーション の ポート番号より)解釈することができ、より上位の層におけるプロトコル情報を 表示する。特にドメインネームサービス要求(RFC-1034/1035)や NFS につい て の Sun RPC (RFC-1050)について出力される。 UDP ネームサービス要求 (注:以下は RFC-1035 で記述される ドメインネームサービスプロトコルを理解 しているものとみなして記述している。もしこのプロトコルに通じていない よ うなら、以下の記述はちんぷんかんぷんかもしれない。) ネームサーバの要求は、 src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) のような形式である。 ホ ス ト h2opolo は helios の ドメインネームサーバに対して、 ucb- bax.berkeley.edu. という名前についてのアドレスレコード(qtype=A)を尋ねる 。 問い合わせの id は ‘3’。‘+’は再帰可能(recursion desired)フラグが設定 されていることを示す。問い合わせは UDP と IP のヘッダは含まめずに 37 バ イトある。問合せは標準的な Query なので op フィールドは省略されている。 もし、op フィールドを持つなら、それがなんであれ、‘3’ と ‘+’ の間に表 示 す る。また同様に、問合せクラス(qclass)も標準的な C_IN なので、省略され ている。ほかの問合せクラスの場合は ‘A’ に続いて表示する。 例外的なものを検出した場合、追加のフィールドを[ ] で囲んで表示するだ ろ う: もし問合せ(query)に回答、ネームサーバ、権威セクションが含まれる場合 、 ancount, nscount, arcount はそれぞれn をカウント数とし て 、 ‘[na]’ 、‘[nn]’ か ‘[nau]’ のように表示される。もし、第二および第三バイトにい くつかの応答bitが設定されている(AA、RA かまたは rcode)場合か、‘must be zero’ ビットが設定されている場合は ‘[b2&3=x]’と表示する。ここで x はヘ ッダの第二および第三バイトの 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 は h2opolo の id 3 の要求に三個の回答レコード、 三 個 のネームサーバレコードと七個の権威レコードを返答している。最初の回答 は A レコードで、このデータはインターネットアドレスの 128.32.137.3 であ る 。 応 答 の サイズは UDP と IP のヘッダは含まずに 273 バイトである。 (queryの) op と response code(この場合は NoError)は、A レコードの ク ラ ス(C_IN)と同様に省略されている。 次の例は helios はドメインが存在しない、という response code (NXDomain) で回答はなし、ネームサーバは一個、権威レコードもなし、という返答をし て いる。 ‘*’ は authoritative answer ビットが設定されていることを示す。回 答がないので、 type とクラスおよびデータは表示されない。 ほかのフラグは‘-’(RA(再帰可)が設定されていない)、‘|’TC(まるめられたメッ セ ー ジ) が 設 定されている。‘question’ セクションが一つでない場合には 、‘[nq]’と出力する。 ネームサーバの応答はデフォルトの snaplen である 68 バイトよりも大きくな り がちなので、そのパケットを表示するのに十分なだけの情報を捉えきれない ことがある。ネームサービスの通信を厳密に解析したいときは、-s フラグを利 用して snaplen を拡張するべきである。 `-s 128’くらいが妥当であろう。 SMB/CIFS 展開 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 パケットの形式や all teフィールドが何を意味 す る か の 情 報 は 、 www.cifs.org か samba.org ミラーサイトの pub/samba/specs/ ディレクトリ を参照のこと。 SMB パッチは Andrew Tridgell (tridge@samba.org) が書いた 。 NFS 要求と回答 Sun NFS(Network File System)の要求と応答は次のように出力される: src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results 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 一行目はホスト sushi が id 6709 でトランザクション要求を wrl に送信して いる (src ホストに続く数字は port 番号 ではなくて トランザクショ ン id である点に注意せよ)。要求は UDP と IP のヘッダを除いて 112 バイトである 。動作要求はファイルハンドル(fh) 21,24/10.731657119 に対する readlink ( シンボリックリンクの値を読む)である。 (この例では、幸運なことに、デバイ スの major および minor 番号の対と inode 番号、generation 番号がファ イ ル ハンドルから抽出できている) Wrl はリンクの内容と ‘ok’ を返答している 。 三行目では sushi は wrl に対し ディレクトリファイル 9,74/4096.8678 から ‘xcolors’ を探し出すように要求している。出力されるデータは操作の種類に よって依存していることに注意すること。この出力形式は NFS プロトコル仕様 とともに読んだ場合に自己説明になるよう意図された形式である。 -v(verbose) フラグが与えられている場合、追加の情報も出力される。例: 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 (-v は IP ヘッダの TTL と ID、フラグメンテーションフィールドも表示する が、この例では省略している)。一行目では、sushi は wrl に対して 、 file 21,11/12.195 のバイトオフセット 24576 から 8192 バイト読み出し要求を出 している。Wrl は ‘ok’ を返している; 二行目に表示されているこのパケッ ト はフラグメント化された返答の一番目のパケットであるため、1472 バイトのみ である(残りのバイトはその後のフラグメントとして続くが、それらのフラグメ ン トは NFS ヘッダも UDP ヘッダも持たないので、フィルタ条件式の指定次第 で表示されないことがある)。また -v フラグがあたえられていることにより、 い く つかのファイルの属性も表示される(ファイルデータに付加して返答され る): ファイルのタイプ (‘‘REG’’ は普通のファイル)、ファイルのモード(八進 で)、uid と gid、またファイルのサイズなど。 -v フラグが複数与えられると(-vvのこと)もっと詳細な情報が出力される。 NFS の要求はとても大きいので、snaplen を増加しないと十分な情報が表示で きないかもしれないことに注意すること。 NFS の通信を監視する場合 は ‘-s 192’ を試してみるとよい。 NFSの返答パケットは RPC操作によって識別することができない。しかしながら 、tcpdump は ‘‘最近の’’要求を覚えておいて、返答がそのトランザクシ ョ ン ID に一致するか調べる。応答が対応する要求の近くに通信されていない場合は きちんと解析できないかもしれない。 AFS 要求と応答 Transarc AFS (Andrew File System) 要求と応答は以下のように表示される。 src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args 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 最初の行で、ホスト elvis は RX パケットを pike に送信している。こ れ は fs (ファイルサーバ) サービスへの RX データパケットで、 RPC 呼び出しの開 始である。 RPC 呼び出しはリネームで、古いディレクトリファイ ル ID は 536876964/1/1 、古いファイル名は‘.newsrc.new’、新しいディレクトリファイ ル ID は 536876964/1/1、新しいファイル名は ‘.newsrc’ である 。 ホ ス ト pike は リネーム呼び出しに対する RPC 応答パケット (データパケットであり 、中断パケットではないので成功を意味する) を返信している。 一般に、全ての AFS RPC は少なくとも RPC 呼び出し名はデコードされる。 ほ とんどの AFC RPC は少なくともいくつかの引数はデコードされる (一般に ‘興 味深い’ 引数のみがデコードされる)。 表示フォーマットは自己説明的なものを目指しているが、 AFS と RX の動作に 詳しくない人々にとってはおそらく便利ではないだろう。 -v ( 詳細) オプションが 2 回指定されると、追加情報が表示される。これは RX 呼び出し ID、呼び出し番号、シーケンス番号、シリアル番号、RX パケット フラグなどである。 さ らに -v オプションが指定されると、セキュリティインデックスとサービス ID が表示される。 中断パケットのエラーコードも表示される。但し、Ubik ビーコンパケットは例 外である。 (なぜなら、Ubik プロトコルにおける中断パケットは賛成票を意味 するからである)。 AFS 要求は非常に大きく、多くの引数はsnaplenを増やさないとおそらく表示さ れないことに注意すること。 AFS 通信を監視する場合は ‘-s 256’ を試してみ るとよい。 AFS 応答パケットは明示的に RPC 操作を識別しない。代わりに、tcpdump は‘‘ 最 近の’’要求を覚えていて、それを呼び出し番号とサービス ID を用いて応答 と照合させる。もし応答が対応する要求と結び付けられなかった場合、その パ ケットはパーズできない。 KIP Appletalk (UDP 内 DDP) UDP データグラム内に格納されたアップルトークの DDP パケットは取り出され て、 DDP パケットとして表示される(すなわちすべての UDP ヘッダ情報は捨て ら れる)。 /etc/atalk.names ファイルが アップルトークネットとノード番号 を名前に変換するのに利用される。ファイルの形式は下記の通り。 番号 名前 1.254 ether 16.1 icsd-net 1.254.110 ace 最初の二行はアップルトークネットワークに名前を与える。三行目は特定の ホ ストの名前を与える(ホストはネットワーク番号の第三オクテットで識別される - ネットワーク番号は二オクテットで なければならず、またホスト番号は三オ ク テットで なければならない。番号と名前は空白文字で区切られる(blank か tab)。 /etc/atalk.names ファイルは空行とコメント行(‘#’で始まる行)を含ん でもよい。 アップルトークのアドレスは次の形式で表示される。 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 がない場合またはそれに適切なアップルトークのネット番 号、ホスト番号が含まれない場合は、アドレスは数字で表示される)。最初の例 は ネットワーク 144.1 のノード 209 の NBP(DDP のポート番号 2 )からネッ トワーク icsd のノード 112 ポート番号220 番への送信を示す。二番目も同様 だ が 、ノード名(‘office’) がわかっている場合の例。三行目はネットワーク jssmag のノード 149 の 235 番ポートから icsd-net の NBPポートへのブロー ドキャストを示す。ブロードキャストアドレス(255)はホスト番号を伴わないネ ットワーク名だけの出力で識別できることに注意すること - /etc/atalk.names にノード名とネットワーク名を記述しておくのはよい考えである)。 NBP(名前解決プロトコル)と ATP(アップルトークトランザクションプロトコル) パケットについては、その内容も解析される。その他のプロトコルはプロト コ ル 名(名前がわからなければ番号)とパケットのサイズが表示されるだけである 。 NBP パケット は次の例のように表示される: 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 。 二行目はその要求へのホスト jssmag.209 からの応答(id 番号が同じである こ と に注意)で、‘‘RM1140’’という名前のレーザライタを 250 番ポートに持って いることを答えている。三行目は同じ要求に対する別の返答でホスト techpit が186番ポートに "tecpit" が登録されていることを答えている。 ATP パケット は次のように表示される: 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 jssmga.209 はホスト helios に対して id 12266 でトランザクションを開始し 最大 8パケット(‘<0-7>’と示す)を要求する。行末の 16 進数字は要求に含まれ る ‘userdata’のフィールドである。 helios は八個の 512 バイトのパケットを返答している。トランザクションid に続く ‘:数字’ 表現はトランザクションにおけるパケットのシーケンス番号で 、カッコに囲まれた数字は atp ヘッダを除いたパケットのデータ量である。パ ケット 7 番の ‘*’ は EOM ビットが設定されていることを示す。 jssmag.209 はパケット 3 番とパケット 5 番の再送を要求してい る 。helios は そ れ らを再送し、jssmag はトランザクションを終了する。そして、 jss- mag.209 は次の要求を開始する。要求の ‘*’ は XO (‘一回だけ’)は設定 さ れ ていない ことを示す。 IP フラグメント化(fragmentation) イ ンターネットデータグラムのフラグメント化されたものは次のように表示す る。 (frag id:size@offset+) (frag id:size@offset) (最初の形式はまだ続くフラグメントがあることを示し、二番目の形式はそれが 最後のフラグメントであることを示す) id はフラグメントの id 。size はフラグメントの IP ヘッダを除くサイズ(バ イトで)。offset はフラグメントのもともとのデータグラム内でのオフセット( バイトで)。 フ ラグメントの情報はフラグメント毎に表示される。最初のフラグメントには 上位プロトコルのヘッダを含み、フラグメント情報はプロトコル情報に続い て 表 示される。二番目以降のフラグメントには上位プロトコルの情報を含まない ので、フラグメント情報はソースおよびディスティネーションアドレスに続 い て 表 示 さ れ る 。以下の例は 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 二 つの注意点がある: 一つ目として、二行目で示されるアドレスにはポート番 号は含まれていない点に注意すること。 TCP プロトコルの情報は最初のフラグ メ ントに含まれるため、残りのフラグメントからは表示すべきポート番号やシ ーケンス番号がわからないためである。二つ目は、一行目の TCP のシーケンス 情報には実際には 512 バイト(最初のフラグメントで 308 バイト、二番目のフ ラグメントで204 バイトの場合)のユーザデータが 308 バイトであるかのよ う に表示されている点である。シーケンスの漏れやパケットの ack の対応を調査 するとき、ここに悩まされることがあるかもしれない。 フラグメント化禁止フラグ の設定されたパケットの場合、行末に (DF)と表 示 する。 時間表示 デ フォルトでは全ての出力行の先頭にタイムスタンプがつく。タイムスタンプ は現在の時刻を次の形式で表示し、 hh:mm:ss.frac これは、kernel の時間情報同様に正確である。タイムスタンプは kernel がパ ケ ットを確認した時点の時刻を反映している。イーサネットインターフェイス が回線からパケットを取得した時点からカーネルが ‘新しいパケット’ によ る 割り込みを受ける時点までの時間差は反映されていない。 関連項目 traffic(1C), nit(4P), bpf(4), pcap(3) 著者 原著者は: Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. 最新版は tcpdump.org によって管理されている。 http://www.tcpdump.org/ IPv6/IPsec のサポートは WIDE/KAME プロジェクトによって追加された。こ の プ ログラムは Eric Young の SSLeay ライブラリを特定の設定の元に使用して いる。 バグ 問題点、バグ、質問、拡張のお願いなどは、以下のアドレスに送ってほしい。 tcpdump-workers@tcpdump.org ソースコードの寄贈などは以下のアドレスへ送ってほしい。 patches@tcpdump.org NIT は外へ出ていく通信は見ることができない。BPF はそれが可能である。 後 者の利用を推奨する。 用 途によっては、IPフラグメントを再構築したり、上位プロトコルの長さを計 算するくらいのことは必要となるだろう。 ネームサーバの逆引き要求は正確に表示できない。(空の)質問はむしろ回答 の 中 に含まれる要求として表示される。逆引き要求にはバグがふくまれていて、 それを修正するのは tcpdump ではなくてネームサービスの方であるべきと考え ている人もいる。 ア ッ プルの EtherTalk の DDP パケットは KIP DDP パケットのように容易に dump できるはずだが、行なわない。たとえ ethertalk を扱おうという気に な っ ても(なってないが)、LBLが ネットワーク上のethertalk へのアクセスを許 さないので、コードのテストができないのだ。 夏時間に切り替わるときにパケットトレースを行なっていると時間がずれて し まう(時間の変更は無視される)。 FDDI ヘッダに対するフィルタの条件式はすべての FDDI パケットがイーサネッ トのパケットをカプセル化しているものとみなして適用 さ れ る 。 こ れ は 、IP,ARP と DECNET PhaseIV については正しく動作するが、 ISO CLNS のよう なプロトコルではうまくいかないだろう。それゆえにフィルターは条件式に 一 致しないようなパケットをあやまってあつかってしまうかもしれない。 ip6 proto はヘッダチェインを追跡するべきだが、今のところそうはなってい ない。 tcp や udp もヘッダチェインを追跡するべきである。 tcp[0]のようなトランスポート層ヘッダに対する算術表現は、 IPv6 パケッ ト に対してはうまく働かない。 IPv4 パケットに対してのみ働く。 30 June 1997 TCPDUMP(1)

TCPDUMP(8) TCPDUMP(8) NAME tcpdump - dump traffic on a network SYNOPSIS tcpdump [ -AdDefIJKlLnNOpqRStuUvxX ] [ -B buffer_size ] [ -c count ] [ -C file_size ] [ -G rotate_seconds ] [ -F file ] [ -i interface ] [ -j tstamp_type ] [ -m module ] [ -M secret ] [ -Q|-P in|out|inout ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -E spi@ipaddr algo:secret,... ] [ -y datalinktype ] [ -z postrotate-command ] [ -Z user ] [ expression ] DESCRIPTION Tcpdump prints out a description of the contents of packets on a net- work interface that match the boolean expression. It can also be run with the -w flag, which causes it to save the packet data to a file for later analysis, and/or with the -r flag, which causes it to read from a saved packet file rather than to read packets from a network interface. In all cases, only packets that match expression will be processed by tcpdump. Tcpdump will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIGINT signal (generated, for example, by typing your interrupt character, typically control-C) or a SIGTERM sig- nal (typically generated with the kill(1) command); if run with the -c flag, it will capture packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number of packets have been processed. When tcpdump finishes capturing packets, it will report counts of: packets ‘‘captured’’ (this is the number of packets that tcpdump has received and processed); packets ‘‘received by filter’’ (the meaning of this depends on the OS on which you’re running tcpdump, and possibly on the way the OS was configured - if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched by the filter expression and, even if they were matched by the filter expression, regardless of whether tcpdump has read and processed them yet, on other OSes it counts only packets that were matched by the filter expression regardless of whether tcpdump has read and processed them yet, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump); packets ‘‘dropped by kernel’’ (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0). On platforms that support the SIGINFO signal, such as most BSDs (including Mac OS X) and Digital/Tru64 UNIX, it will report those counts when it receives a SIGINFO signal (generated, for example, by typing your ‘‘status’’ character, typically control-T, although on some platforms, such as Mac OS X, the ‘‘status’’ character is not set by default, so you must set it with stty(1) in order to use it) and will continue capturing packets. Reading packets from a network interface may require that you have special privileges; see the pcap (3PCAP) man page for details. Reading a saved packet file doesn’t require special privileges. OPTIONS -A Print each packet (minus its link level header) in ASCII. Handy for capturing web pages. -B Set the operating system capture buffer size to buffer_size. -c Exit after receiving count packets. -C Before writing a raw packet to a savefile, check whether the file is currently larger than file_size and, if so, close the current savefile and open a new one. Savefiles after the first savefile will have the name specified with the -w flag, with a number after it, starting at 1 and continuing upward. The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576 bytes). Note that when used with -Z option (enabled by default), privi- leges are dropped before opening first savefile. -d Dump the compiled packet-matching code in a human readable form to standard output and stop. -dd Dump packet-matching code as a C program fragment. -ddd Dump packet-matching code as decimal numbers (preceded with a count). -D Print the list of the network interfaces available on the system and on which tcpdump can capture packets. For each network interface, a number and an interface name, possibly followed by a text description of the interface, is printed. The interface name or the number can be supplied to the -i flag to specify an interface on which to capture. This can be useful on systems that don’t have a command to list them (e.g., Windows systems, or UNIX systems lacking ifconfig -a); the number can be useful on Windows 2000 and later systems, where the interface name is a somewhat complex string. The -D flag will not be supported if tcpdump was built with an older version of libpcap that lacks the pcap_findalldevs() func- tion. -e Print the link-level header on each dump line. -E Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that are addressed to addr and contain Security Parameter Index value spi. This combination may be repeated with comma or newline seperation. Note that setting the secret for IPv4 ESP packets is supported at this time. Algorithms may be des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, or none. The default is des-cbc. The ability to decrypt packets is only present if tcpdump was compiled with cryptography enabled. secret is the ASCII text for ESP secret key. If preceeded by 0x, then a hex value will be read. The option assumes RFC2406 ESP, not RFC1827 ESP. The option is only for debugging purposes, and the use of this option with a true ‘secret’ key is discouraged. By presenting IPsec secret key onto command line you make it visible to others, via ps(1) and other occasions. In addition to the above syntax, the syntax file name may be used to have tcpdump read the provided file in. The file is opened upon receiving the first ESP packet, so any special per- missions that tcpdump may have been given should already have been given up. -f Print ‘foreign’ IPv4 addresses numerically rather than symboli- cally (this option is intended to get around serious brain dam- age in Sun’s NIS server — usually it hangs forever translating non-local internet numbers). The test for ‘foreign’ IPv4 addresses is done using the IPv4 address and netmask of the interface on which capture is being done. If that address or netmask are not available, available, either because the interface on which capture is being done has no address or netmask or because the capture is being done on the Linux "any" interface, which can capture on more than one interface, this option will not work correctly. -F Use file as input for the filter expression. An additional expression given on the command line is ignored. -G If specified, rotates the dump file specified with the -w option every rotate_seconds seconds. Savefiles will have the name specified by -w which should include a time format as defined by strftime(3). If no time format is specified, each new file will overwrite the previous. If used in conjunction with the -C option, filenames will take the form of ‘file’. -i Listen on interface. If unspecified, tcpdump searches the sys- tem interface list for the lowest numbered, configured up inter- face (excluding loopback). Ties are broken by choosing the ear- liest match. On Linux systems with 2.2 or later kernels, an interface argu- ment of ‘‘any’’ can be used to capture packets from all inter- faces. Note that captures on the ‘‘any’’ device will not be done in promiscuous mode. If the -D flag is supported, an interface number as printed by that flag can be used as the interface argument. -I Put the interface in "monitor mode"; this is supported only on IEEE 802.11 Wi-Fi interfaces, and supported only on some operat- ing systems. Note that in monitor mode the adapter might disassociate from the network with which it’s associated, so that you will not be able to use any wireless networks with that adapter. This could prevent accessing files on a network server, or resolving host names or network addresses, if you are capturing in monitor mode and are not connected to another network with another adapter. This flag will affect the output of the -L flag. If -I isn’t specified, only those link-layer types available when not in monitor mode will be shown; if -I is specified, only those link- layer types available when in monitor mode will be shown. -j Set the time stamp type for the capture to tstamp_type. -J List the supported time stamp types for the interface and exit. If the time stamp type cannot be set for the interface, no time stamp types are listed. --time-stamp-precision=tstamp_precision When capturing, set the time stamp precision for the capture to tstamp_precision. Note that availability of high precision time stamps (nanoseconds) and their actual accuracy is platform and hardware dependent. Also note that when writing captures made with nanosecond accuracy to a savefile, the time stamps are written with nanosecond resolution, and the file is written with a different magic number, to indicate that the time stamps are in seconds and nanoseconds; not all programs that read pcap savefiles will be able to read those captures. When reading a savefile, convert time stamps to the precision specified by timestamp_precision, and display them with that resolution. If the precision specified is less than the preci- sion of time stamps in the file, the conversion will lose preci- sion. The supported values for timestamp_precision are micro for microsecond resolution and nano for nanosecond resolution. The default is microsecond resolution. -K Don’t attempt to verify IP, TCP, or UDP checksums. This is use- ful for interfaces that perform some or all of those checksum calculation in hardware; otherwise, all outgoing TCP checksums will be flagged as bad. -l Make stdout line buffered. Useful if you want to see the data while capturing it. E.g., ‘‘tcpdump -l | tee dat’’ or ‘‘tcpdump -l > dat & tail -f dat’’. -L List the known data link types for the interface, in the speci- fied mode, and exit. The list of known data link types may be dependent on the specified mode; for example, on some platforms, a Wi-Fi interface might support one set of data link types when not in monitor mode (for example, it might support only fake Ethernet headers, or might support 802.11 headers but not sup- port 802.11 headers with radio information) and another set of data link types when in monitor mode (for example, it might sup- port 802.11 headers, or 802.11 headers with radio information, only in monitor mode). -m Load SMI MIB module definitions from file module. This option can be used several times to load several MIB modules into tcp- dump. -M Use secret as a shared secret for validating the digests found in TCP segments with the TCP-MD5 option (RFC 2385), if present. -n Don’t convert host addresses to names. This can be used to avoid DNS lookups. -nn Don’t convert protocol and port numbers etc. to names either. -N Don’t print domain name qualification of host names. E.g., if you give this flag then tcpdump will print ‘‘nic’’ instead of ‘‘nic.ddn.mil’’. -O Do not run the packet-matching code optimizer. This is useful only if you suspect a bug in the optimizer. -p Don’t put the interface into promiscuous mode. Note that the interface might be in promiscuous mode for some other reason; hence, ‘-p’ cannot be used as an abbreviation for ‘ether host {local-hw-addr} or ether broadcast’. -Q|-P Choose send/receive direction direction for which packets should be captured. Possible values are ‘in’, ‘out’ and ‘inout’. Not available on all platforms. -q Quick (quiet?) output. Print less protocol information so out- put lines are shorter. -R Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829). If specified, tcpdump will not print replay pre- vention field. Since there is no protocol version field in ESP/AH specification, tcpdump cannot deduce the version of ESP/AH protocol. -r Read packets from file (which was created with the -w option). Standard input is used if file is ‘‘-’’. -S Print absolute, rather than relative, TCP sequence numbers. -s Snarf snaplen bytes of data from each packet rather than the default of 65535 bytes. Packets truncated because of a limited snapshot are indicated in the output with ‘‘[|proto]’’, where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause pack- ets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you’re interested in. Setting snaplen to 0 sets it to the default of 65535, for back- wards compatibility with recent older versions of tcpdump. -T Force packets selected by "expression" to be interpreted the specified type. Currently known types are aodv (Ad-hoc On- demand Distance Vector protocol), cnfp (Cisco NetFlow protocol), rpc (Remote Procedure Call), rtp (Real-Time Applications proto- col), rtcp (Real-Time Applications control protocol), snmp (Sim- ple Network Management Protocol), tftp (Trivial File Transfer Protocol), vat (Visual Audio Tool), and wb (distributed White Board). -t Don’t print a timestamp on each dump line. -tt Print an unformatted timestamp on each dump line. -ttt Print a delta (micro-second resolution) between current and pre- vious line on each dump line. -tttt Print a timestamp in default format proceeded by date on each dump line. -ttttt Print a delta (micro-second resolution) between current and first line on each dump line. -u Print undecoded NFS handles. -U Make output saved via the -w option ‘‘packet-buffered’’; i.e., as each packet is saved, it will be written to the output file, rather than being written only when the output buffer fills. The -U flag will not be supported if tcpdump was built with an older version of libpcap that lacks the pcap_dump_flush() func- tion. -v When parsing and printing, produce (slightly more) verbose out- put. For example, the time to live, identification, total length and options in an IP packet are printed. Also enables additional packet integrity checks such as verifying the IP and ICMP header checksum. When writing to a file with the -w option, report, every 10 sec- onds, the number of packets captured. -vv Even more verbose output. For example, additional fields are printed from NFS reply packets, and SMB packets are fully decoded. -vvv Even more verbose output. For example, telnet SB ... SE options are printed in full. With -X Telnet options are printed in hex as well. -w Write the raw packets to file rather than parsing and printing them out. They can later be printed with the -r option. Stan- dard output is used if file is ‘‘-’’. See pcap-savefile(5) for a description of the file format. -W Used in conjunction with the -C option, this will limit the num- ber of files created to the specified number, and begin over- writing files from the beginning, thus creating a ’rotating’ buffer. In addition, it will name the files with enough leading 0s to support the maximum number of files, allowing them to sort correctly. Used in conjunction with the -G option, this will limit the num- ber of rotated dump files that get created, exiting with status 0 when reaching the limit. If used with -C as well, the behavior will result in cyclical files per timeslice. -x When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex. The smaller of the entire packet or snaplen bytes will be printed. Note that this is the entire link-layer packet, so for link layers that pad (e.g. Ethernet), the padding bytes will also be printed when the higher layer packet is shorter than the required padding. -xx When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex. -X When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex and ASCII. This is very handy for analysing new protocols. -XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII. -y Set the data link type to use while capturing packets to datalinktype. -z Used in conjunction with the -C or -G options, this will make tcpdump run " command file " where file is the savefile being closed after each rotation. For example, specifying -z gzip or -z bzip2 will compress each savefile using gzip or bzip2. Note that tcpdump will run the command in parallel to the cap- ture, using the lowest priority so that this doesn’t disturb the capture process. And in case you would like to use a command that itself takes flags or different arguments, you can always write a shell script that will take the savefile name as the only argument, make the flags & arguments arrangements and execute the command that you want. -Z Drops privileges (if root) and changes user ID to user and the group ID to the primary group of user. This behavior is enabled by default (-Z tcpdump), and can be disabled by -Z root. expression selects which packets will be dumped. If no expression is given, all packets on the net will be dumped. Otherwise, only packets for which expression is ‘true’ will be dumped. For the expression syntax, see pcap-filter(7). Expression arguments can be passed to tcpdump as either a single argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed. EXAMPLES To print all packets arriving at or departing from sundown: tcpdump host sundown To print traffic between helios and either hot or ace: tcpdump host helios and \( hot or ace \) To print all IP packets between ace and any host except helios: tcpdump ip host ace and not helios To print all traffic between local hosts and hosts at Berkeley: tcpdump net ucb-ether To print all ftp traffic through internet gateway snup: (note that the expression is quoted to prevent the shell from (mis-)interpreting the parentheses): tcpdump ’gateway snup and (port ftp or ftp-data)’ To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net). tcpdump ip and not net localnet To print the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host. tcpdump ’tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet’ To print all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not, for example, SYN and FIN packets and ACK-only packets. (IPv6 is left as an exercise for the reader.) tcpdump ’tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)’ To print IP packets longer than 576 bytes sent through gateway snup: tcpdump ’gateway snup and ip[2:2] > 576’ To print IP broadcast or multicast packets that were not sent via Eth- ernet broadcast or multicast: tcpdump ’ether[0] & 1 = 0 and ip[16] >= 224’ To print all ICMP packets that are not echo requests/replies (i.e., not ping packets): tcpdump ’icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply’ OUTPUT FORMAT The output of tcpdump is protocol dependent. The following gives a brief description and examples of most of the formats. Link Level Headers If the ’-e’ option is given, the link level header is printed out. On Ethernets, the source and destination addresses, protocol, and packet length are printed. On FDDI networks, the ’-e’ option causes tcpdump to print the ‘frame control’ field, the source and destination addresses, and the packet length. (The ‘frame control’ field governs the interpretation of the rest of the packet. Normal packets (such as those containing IP data- grams) are ‘async’ packets, with a priority value between 0 and 7; for example, ‘async4’. Such packets are assumed to contain an 802.2 Logi- cal Link Control (LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-called SNAP packet. On Token Ring networks, the ’-e’ option causes tcpdump to print the ‘access control’ and ‘frame control’ fields, the source and destination addresses, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet. Regardless of whether the ’-e’ option is specified or not, the source routing information is printed for source-routed packets. On 802.11 networks, the ’-e’ option causes tcpdump to print the ‘frame control’ fields, all of the addresses in the 802.11 header, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet. (N.B.: The following description assumes familiarity with the SLIP com- pression algorithm described in RFC-1144.) On SLIP links, a direction indicator (‘‘I’’ for inbound, ‘‘O’’ for out- bound), packet type, and compression information are printed out. The packet type is printed first. The three types are ip, utcp, and ctcp. No further link information is printed for ip packets. For TCP pack- ets, the connection identifier is printed following the type. If the packet is compressed, its encoded header is printed out. The special cases are printed out as *S+n and *SA+n, where n is the amount by which the sequence number (or sequence number and ack) has changed. If it is not a special case, zero or more changes are printed. A change is indicated by U (urgent pointer), W (window), A (ack), S (sequence num- ber), and I (packet ID), followed by a delta (+n or -n), or a new value (=n). Finally, the amount of data in the packet and compressed header length are printed. For example, the following line shows an outbound compressed TCP packet, with an implicit connection identifier; the ack has changed by 6, the sequence number by 49, and the packet ID by 6; there are 3 bytes of data and 6 bytes of compressed header: O ctcp * A+6 S+49 I+6 3 (6) ARP/RARP Packets Arp/rarp output shows the type of request and its arguments. The for- mat is intended to be self explanatory. Here is a short sample taken from the start of an ‘rlogin’ from host rtsg to host csam: arp who-has csam tell rtsg arp reply csam is-at CSAM The first line says that rtsg sent an arp packet asking for the Ether- net address of internet host csam. Csam replies with its Ethernet address (in this example, Ethernet addresses are in caps and internet addresses in lower case). This would look less redundant if we had done 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 If we had done tcpdump -e, the fact that the first packet is broadcast and the second is point-to-point would be visible: RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM For the first packet this says the Ethernet source address is RTSG, the destination is the Ethernet broadcast address, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes. TCP Packets (N.B.:The following description assumes familiarity with the TCP proto- col described in RFC-793. If you are not familiar with the protocol, neither this description nor tcpdump will be of much use to you.) The general format of a tcp protocol line is: src > dst: flags data-seqno ack window urgent options Src and dst are the source and destination IP addresses and ports. Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single ‘.’ (no flags). Data-seqno describes the portion of sequence space covered by the data in this packet (see example below). Ack is sequence number of the next data expected the other direction on this connection. Window is the number of bytes of receive buffer space available the other direction on this connection. Urg indicates there is ‘urgent’ data in the packet. Options are tcp options enclosed in angle brackets (e.g., ). Src, dst and flags are always present. The other fields depend on the contents of the packet’s tcp protocol header and are output only if appropriate. Here is the opening portion of an rlogin from host rtsg to host csam. rtsg.1023 > csam.login: S 768512:768512(0) win 4096 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 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 The first line says that tcp port 1023 on rtsg sent a packet to port login on csam. The S indicates that the SYN flag was set. The packet sequence number was 768512 and it contained no data. (The notation is ‘first:last(nbytes)’ which means ‘sequence numbers first up to but not including last which is nbytes bytes of user data’.) There was no piggy-backed ack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes. Csam replies with a similar packet except it includes a piggy-backed ack for rtsg’s SYN. Rtsg then acks csam’s SYN. The ‘.’ means no flags were set. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer (1). The first time tcpdump sees a tcp ‘conversation’, it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet’s sequence number and this ini- tial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation’s data stream (with the first data byte each direction being ‘1’). ‘-S’ will override this feature, causing the original sequence numbers to be output. On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg → csam side of the conversation). The PUSH flag is set in the packet. On the 7th line, csam says it’s received data sent by rtsg up to but not including byte 21. Most of this data is apparently sit- ting in the socket buffer since csam’s receive window has gotten 19 bytes smaller. Csam also sends one byte of data to rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg. If the snapshot was small enough that tcpdump didn’t capture the full TCP header, it interprets as much of the header as it can and then reports ‘‘[|tcp]’’ to indicate the remainder could not be interpreted. If the header contains a bogus option (one with a length that’s either too small or beyond the end of the header), tcpdump reports it as ‘‘[bad opt]’’ and does not interpret any further options (since it’s impossible to tell where they start). If the header length indicates options are present but the IP datagram length is not long enough for the options to actually be there, tcpdump reports it as ‘‘[bad hdr length]’’. Capturing TCP packets with particular flag combinations (SYN-ACK, URG- ACK, etc.) There are 8 bits in the control bits section of the TCP header: CWR | ECE | URG | ACK | PSH | RST | SYN | FIN Let’s assume that we want to watch packets used in establishing a TCP connection. Recall that TCP uses a 3-way handshake protocol when it initializes a new connection; the connection sequence with regard to the TCP control bits is 1) Caller sends SYN 2) Recipient responds with SYN, ACK 3) Caller sends ACK Now we’re interested in capturing packets that have only the SYN bit set (Step 1). Note that we don’t want packets from step 2 (SYN-ACK), just a plain initial SYN. What we need is a correct filter expression for tcpdump. Recall the structure of a TCP header without options: 0 15 31 ----------------------------------------------------------------- | source port | destination port | ----------------------------------------------------------------- | sequence number | ----------------------------------------------------------------- | acknowledgment number | ----------------------------------------------------------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------------------------------------------------------- | TCP checksum | urgent pointer | ----------------------------------------------------------------- A TCP header usually holds 20 octets of data, unless options are present. The first line of the graph contains octets 0 - 3, the second line shows octets 4 - 7 etc. Starting to count with 0, the relevant TCP control bits are contained in octet 13: 0 7| 15| 23| 31 ----------------|---------------|---------------|---------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------|---------------|---------------|---------------- | | 13th octet | | | Let’s have a closer look at octet no. 13: | | |---------------| |C|E|U|A|P|R|S|F| |---------------| |7 5 3 0| These are the TCP control bits we are interested in. We have numbered the bits in this octet from 0 to 7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5. Recall that we want to capture packets with only SYN set. Let’s see what happens to octet 13 if a TCP datagram arrives with the SYN bit set in its header: |C|E|U|A|P|R|S|F| |---------------| |0 0 0 0 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0| Looking at the control bits section we see that only bit number 1 (SYN) is set. Assuming that octet number 13 is an 8-bit unsigned integer in network byte order, the binary value of this octet is 00000010 and its decimal representation is 7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2 We’re almost done, because now we know that if only SYN is set, the value of the 13th octet in the TCP header, when interpreted as a 8-bit unsigned integer in network byte order, must be exactly 2. This relationship can be expressed as tcp[13] == 2 We can use this expression as the filter for tcpdump in order to watch packets which have only SYN set: tcpdump -i xl0 tcp[13] == 2 The expression says "let the 13th octet of a TCP datagram have the dec- imal value 2", which is exactly what we want. Now, let’s assume that we need to capture SYN packets, but we don’t care if ACK or any other TCP control bit is set at the same time. Let’s see what happens to octet 13 when a TCP datagram with SYN-ACK set arrives: |C|E|U|A|P|R|S|F| |---------------| |0 0 0 1 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0| Now bits 1 and 4 are set in the 13th octet. The binary value of octet 13 is 00010010 which translates to decimal 7 6 5 4 3 2 1 0 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18 Now we can’t just use ’tcp[13] == 18’ in the tcpdump filter expression, because that would select only those packets that have SYN-ACK set, but not those with only SYN set. Remember that we don’t care if ACK or any other control bit is set as long as SYN is set. In order to achieve our goal, we need to logically AND the binary value of octet 13 with some other value to preserve the SYN bit. We know that we want SYN to be set in any case, so we’ll logically AND the value in the 13th octet with the binary value of a SYN: 00010010 SYN-ACK 00000010 SYN AND 00000010 (we want SYN) AND 00000010 (we want SYN) -------- -------- = 00000010 = 00000010 We see that this AND operation delivers the same result regardless whether ACK or another TCP control bit is set. The decimal representa- tion of the AND value as well as the result of this operation is 2 (binary 00000010), so we know that for packets with SYN set the follow- ing relation must hold true: ( ( value of octet 13 ) AND ( 2 ) ) == ( 2 ) This points us to the tcpdump filter expression tcpdump -i xl0 ’tcp[13] & 2 == 2’ Note that you should use single quotes or a backslash in the expression to hide the AND (’&’) special character from the shell. UDP Packets UDP format is illustrated by this rwho packet: actinide.who > broadcast.who: udp 84 This says that port who on host actinide sent a udp datagram to port who on host broadcast, the Internet broadcast address. The packet con- tained 84 bytes of user data. Some UDP services are recognized (from the source or destination port number) and the higher level protocol information printed. In particu- lar, Domain Name service requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS. UDP Name Server Requests (N.B.:The following description assumes familiarity with the Domain Service protocol described in RFC-1035. If you are not familiar with the protocol, the following description will appear to be written in greek.) Name server requests are formatted as src > dst: id op? flags qtype qclass name (len) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) Host h2opolo asked the domain server on helios for an address record (qtype=A) associated with the name ucbvax.berkeley.edu. The query id was ‘3’. The ‘+’ indicates the recursion desired flag was set. The query length was 37 bytes, not including the UDP and IP protocol head- ers. The query operation was the normal one, Query, so the op field was omitted. If the op had been anything else, it would have been printed between the ‘3’ and the ‘+’. Similarly, the qclass was the normal one, C_IN, and omitted. Any other qclass would have been printed immediately after the ‘A’. A few anomalies are checked and may result in extra fields enclosed in square brackets: If a query contains an answer, authority records or additional records section, ancount, nscount, or arcount are printed as ‘[na]’, ‘[nn]’ or ‘[nau]’ where n is the appropriate count. If any of the response bits are set (AA, RA or rcode) or any of the ‘must be zero’ bits are set in bytes two and three, ‘[b2&3=x]’ is printed, where x is the hex value of header bytes two and three. UDP Name Server Responses Name server responses are formatted as 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) In the first example, helios responds to query id 3 from h2opolo with 3 answer records, 3 name server records and 7 additional records. The first answer record is type A (address) and its data is internet address 128.32.137.3. The total size of the response was 273 bytes, excluding UDP and IP headers. The op (Query) and response code (NoEr- ror) were omitted, as was the class (C_IN) of the A record. In the second example, helios responds to query 2 with a response code of non-existent domain (NXDomain) with no answers, one name server and no authority records. The ‘*’ indicates that the authoritative answer bit was set. Since there were no answers, no type, class or data were printed. Other flag characters that might appear are ‘-’ (recursion available, RA, not set) and ‘|’ (truncated message, TC, set). If the ‘question’ section doesn’t contain exactly one entry, ‘[nq]’ is printed. SMB/CIFS decoding tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data on UDP/137, UDP/138 and TCP/139. Some primitive decoding of IPX and Net- BEUI SMB data is also done. By default a fairly minimal decode is done, with a much more detailed decode done if -v is used. Be warned that with -v a single SMB packet may take up a page or more, so only use -v if you really want all the gory details. For information on SMB packet formats and what all te fields mean see www.cifs.org or the pub/samba/specs/ directory on your favorite samba.org mirror site. The SMB patches were written by Andrew Tridgell (tridge@samba.org). NFS Requests and Replies Sun NFS (Network File System) requests and replies are printed as: src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results 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 In the first line, host sushi sends a transaction with id 6709 to wrl (note that the number following the src host is a transaction id, not the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a readlink (read symbolic link) on file handle (fh) 21,24/10.731657119. (If one is lucky, as in this case, the file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number.) Wrl replies ‘ok’ with the contents of the link. In the third line, sushi asks wrl to lookup the name ‘xcolors’ in directory file 9,74/4096.6878. Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol spec. If the -v (verbose) flag is given, additional information is printed. For example: 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 (-v also prints the IP header TTL, ID, length, and fragmentation fields, which have been omitted from this example.) In the first line, sushi asks wrl to read 8192 bytes from file 21,11/12.195, at byte off- set 24576. Wrl replies ‘ok’; the packet shown on the second line is the first fragment of the reply, and hence is only 1472 bytes long (the other bytes will follow in subsequent fragments, but these fragments do not have NFS or even UDP headers and so might not be printed, depending on the filter expression used). Because the -v flag is given, some of the file attributes (which are returned in addition to the file data) are printed: the file type (‘‘REG’’, for regular file), the file mode (in octal), the uid and gid, and the file size. If the -v flag is given more than once, even more details are printed. Note that NFS requests are very large and much of the detail won’t be printed unless snaplen is increased. Try using ‘-s 192’ to watch NFS traffic. NFS reply packets do not explicitly identify the RPC operation. Instead, tcpdump keeps track of ‘‘recent’’ requests, and matches them to the replies using the transaction ID. If a reply does not closely follow the corresponding request, it might not be parsable. AFS Requests and Replies Transarc AFS (Andrew File System) requests and replies are printed as: src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args 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 In the first line, host elvis sends a RX packet to pike. This was a RX data packet to the fs (fileserver) service, and is the start of an RPC call. The RPC call was a rename, with the old directory file id of 536876964/1/1 and an old filename of ‘.newsrc.new’, and a new directory file id of 536876964/1/1 and a new filename of ‘.newsrc’. The host pike responds with a RPC reply to the rename call (which was success- ful, because it was a data packet and not an abort packet). In general, all AFS RPCs are decoded at least by RPC call name. Most AFS RPCs have at least some of the arguments decoded (generally only the ‘interesting’ arguments, for some definition of interesting). The format is intended to be self-describing, but it will probably not be useful to people who are not familiar with the workings of AFS and RX. If the -v (verbose) flag is given twice, acknowledgement packets and additional header information is printed, such as the the RX call ID, call number, sequence number, serial number, and the RX packet flags. If the -v flag is given twice, additional information is printed, such as the the RX call ID, serial number, and the RX packet flags. The MTU negotiation information is also printed from RX ack packets. If the -v flag is given three times, the security index and service id are printed. Error codes are printed for abort packets, with the exception of Ubik beacon packets (because abort packets are used to signify a yes vote for the Ubik protocol). Note that AFS requests are very large and many of the arguments won’t be printed unless snaplen is increased. Try using ‘-s 256’ to watch AFS traffic. AFS reply packets do not explicitly identify the RPC operation. Instead, tcpdump keeps track of ‘‘recent’’ requests, and matches them to the replies using the call number and service ID. If a reply does not closely follow the corresponding request, it might not be parsable. KIP AppleTalk (DDP in UDP) AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated and dumped as DDP packets (i.e., all the UDP header information is dis- carded). The file /etc/atalk.names is used to translate AppleTalk net and node numbers to names. Lines in this file have the form number name 1.254 ether 16.1 icsd-net 1.254.110 ace The first two lines give the names of AppleTalk networks. The third line gives the name of a particular host (a host is distinguished from a net by the 3rd octet in the number - a net number must have two octets and a host number must have three octets.) The number and name should be separated by whitespace (blanks or tabs). The /etc/atalk.names file may contain blank lines or comment lines (lines starting with a ‘#’). AppleTalk addresses are printed in the form net.host.port 144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2 (If the /etc/atalk.names doesn’t exist or doesn’t contain an entry for some AppleTalk host/net number, addresses are printed in numeric form.) In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending to whatever is listening on port 220 of net icsd node 112. The second line is the same except the full name of the source node is known (‘office’). The third line is a send from port 235 on net jssmag node 149 to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indicated by a net name with no host number - for this reason it’s a good idea to keep node names and net names distinct in /etc/atalk.names). NBP (name binding protocol) and ATP (AppleTalk transaction protocol) packets have their contents interpreted. Other protocols just dump the protocol name (or number if no name is registered for the protocol) and packet size. NBP packets are formatted like the following examples: 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 The first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net jssmag. The nbp id for the lookup is 190. The second line shows a reply for this request (note that it has the same id) from host jssmag.209 saying that it has a laserwriter resource named "RM1140" registered on port 250. The third line is another reply to the same request saying host techpit has laserwriter "techpit" registered on port 186. ATP packet formatting is demonstrated by the following example: 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 initiates transaction id 12266 with host helios by request- ing up to 8 packets (the ‘<0-7>’). The hex number at the end of the line is the value of the ‘userdata’ field in the request. Helios responds with 8 512-byte packets. The ‘:digit’ following the transaction id gives the packet sequence number in the transaction and the number in parens is the amount of data in the packet, excluding the atp header. The ‘*’ on packet 7 indicates that the EOM bit was set. Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios resends them then jssmag.209 releases the transaction. Finally, jss- mag.209 initiates the next request. The ‘*’ on the request indicates that XO (‘exactly once’) was not set. IP Fragmentation Fragmented Internet datagrams are printed as (frag id:size@offset+) (frag id:size@offset) (The first form indicates there are more fragments. The second indi- cates this is the last fragment.) Id is the fragment id. Size is the fragment size (in bytes) excluding the IP header. Offset is this fragment’s offset (in bytes) in the original datagram. The fragment information is output for each fragment. The first frag- ment contains the higher level protocol header and the frag info is printed after the protocol info. Fragments after the first contain no higher level protocol header and the frag info is printed after the source and destination addresses. For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa over a CSNET connection that doesn’t appear to handle 576 byte datagrams: 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 There are a couple of things to note here: First, addresses in the 2nd line don’t include port numbers. This is because the TCP protocol information is all in the first fragment and we have no idea what the port or sequence numbers are when we print the later fragments. Sec- ond, the tcp sequence information in the first line is printed as if there were 308 bytes of user data when, in fact, there are 512 bytes (308 in the first frag and 204 in the second). If you are looking for holes in the sequence space or trying to match up acks with packets, this can fool you. A packet with the IP don’t fragment flag is marked with a trailing (DF). Timestamps By default, all output lines are preceded by a timestamp. The times- tamp is the current clock time in the form hh:mm:ss.frac and is as accurate as the kernel’s clock. The timestamp reflects the time the kernel first saw the packet. No attempt is made to account for the time lag between when the Ethernet interface removed the packet from the wire and when the kernel serviced the ‘new packet’ interrupt. SEE ALSO stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-filter(7) AUTHORS The original authors are: Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. It is currently being maintained by tcpdump.org. The current version is available via http: http://www.tcpdump.org/ The original distribution is available via anonymous ftp: ftp://ftp.ee.lbl.gov/tcpdump.tar.Z IPv6/IPsec support is added by WIDE/KAME project. This program uses Eric Young’s SSLeay library, under specific configurations. BUGS Please send problems, bugs, questions, desirable enhancements, patches etc. to: tcpdump-workers@lists.tcpdump.org NIT doesn’t let you watch your own outbound traffic, BPF will. We rec- ommend that you use the latter. On Linux systems with 2.0[.x] kernels: packets on the loopback device will be seen twice; packet filtering cannot be done in the kernel, so that all pack- ets must be copied from the kernel in order to be filtered in user mode; all of a packet, not just the part that’s within the snapshot length, will be copied from the kernel (the 2.0[.x] packet cap- ture mechanism, if asked to copy only part of a packet to user- land, will not report the true length of the packet; this would cause most IP packets to get an error from tcpdump); capturing on some PPP devices won’t work correctly. We recommend that you upgrade to a 2.2 or later kernel. Some attempt should be made to reassemble IP fragments or, at least to compute the right length for the higher level protocol. Name server inverse queries are not dumped correctly: the (empty) ques- tion section is printed rather than real query in the answer section. Some believe that inverse queries are themselves a bug and prefer to fix the program generating them rather than tcpdump. A packet trace that crosses a daylight savings time change will give skewed time stamps (the time change is ignored). Filter expressions on fields other than those in Token Ring headers will not correctly handle source-routed Token Ring packets. Filter expressions on fields other than those in 802.11 headers will not correctly handle 802.11 data packets with both To DS and From DS set. ip6 proto should chase header chain, but at this moment it does not. ip6 protochain is supplied for this behavior. Arithmetic expression against transport layer headers, like tcp[0], does not work against IPv6 packets. It only looks at IPv4 packets. 05 March 2009 TCPDUMP(8)