名
tcpdump - ネットワーク上のトラフィックをダンプする
シノプシス
tcpdump [ -adeflnNOpqRStuvxX ] [ -c カウント ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -U user ] [ -w file ]
[ -E algo：秘密 ] [ 式 ]
DESCRIPTION
Tcpdumpは、ブール式と一致するネットワークインターフェイス上のパケットのヘッダーを出力します。 後で解析するためにパケット・データをファイルに保存する-wフラグ、またはパケットを読み取るのではなく保存されたパケット・ファイルから読み取る-rフラグを使用して実行することもできますネットワークインターフェイスから。 すべての場合、 式に一致するパケットだけがtcpdumpによって処理されます。
Tcpdumpは、 -cフラグを付けて実行しないと、SIGINTシグナル（割り込み文字、通常はcontrol-Cを入力するなどして生成される）またはSIGTERMシグナル（通常はkill （1）コマンド）。 -cフラグを付けて実行すると、SIGINTまたはSIGTERMシグナルによって中断されるか、または指定された数のパケットが処理されるまでパケットをキャプチャします。
tcpdumpがパケットのキャプチャを終了すると、次のカウントが報告されます。
パケットが `` filter 'によって受信された（これは、 tcpdumpを実行しているOSと、OSが設定されている方法によって異なります） - コマンドラインでフィルタが指定された場合、パケットがフィルタ式と一致しているかどうかにかかわらず、他のOSではフィルタ式と一致し、 tcpdumpによって処理されたパケットのみを数えます。
パケットが ``カーネルによってドロップされた ''（これは、OSがその情報をアプリケーションに報告する場合、 tcpdumpが実行されているOSのパケットキャプチャメカニズムによって、バッファ領域の不足のためにドロップされたパケットの数です。そうでない場合は、0と報告されます）。
ほとんどのBSDのようなSIGINFOシグナルをサポートしているプラットフォームでは、SIGINFOシグナルを受け取ったときにそれらのカウントを報告します（例えば `` status ''文字を入力することによって生成されます。通常はcontrol-T）。 。
ネットワークインタフェースからパケットを読み取るには、特別な特権が必要です。
NITまたはBPFを使用したSunOS 3.xまたは4.xの場合：
/ dev / nitまたは/ dev / bpf *への読み取りアクセス権が必要です。
DLPIを使用するSolarisの場合：
ネットワーク擬似デバイス（例： / dev / le）への読み取り/書き込みアクセス権が必要です。 しかし、Solarisの少なくともいくつかのバージョンでは、 tcpdumpがプロミスキャスモードで取得できるようにするには十分ではありません。 プロミスキャスモードで取得するには、Solarisのこれらのバージョンではrootでなければならず、 tcpdumpを setuidをrootにインストールする必要があります。 プロミスキャスモードでキャプチャしないと、多くの（おそらくすべての）インターフェイスで、発信パケットは表示されないので、プロミスキャスモードでは行われないキャプチャはあまり役に立ちません。
DLPIを使用したHP-UXの場合：
あなたはrootでなければなりません.tcpdumpはsetuidをrootにインストールする必要があります。
スヌープ付きIRIXの下で：
あなたはrootでなければなりません.tcpdumpはsetuidをrootにインストールする必要があります。
Linuxの場合：
あなたはrootでなければなりません.tcpdumpはsetuidをrootにインストールする必要があります。
UltrixおよびDigital UNIX / Tru64 UNIXの場合：
どのユーザーもtcpdumpを使用してネットワークトラフィックをキャプチャできます。 しかし、スーパーユーザがpfconfig （8）を使用してそのインタフェース上でプロミスキャスモード操作を有効にしていない限り、スーパーユーザでさえもプロミスキャスモードでキャプチャできません。 ）は、スーパーユーザがpfconfigを使用してそのインタフェース上でコピーオールモード動作を有効にしていない限り、インタフェース上でマシンが受信した、またはマシンが送信したユニキャストトラフィックをキャプチャできるため、インタフェース上の有用なパケットキャプチャでは、 - 全モード動作、または両方の動作モードが、そのインタフェース上でイネーブルにされる。
BSDの下で：
/ dev / bpf *への読み取りアクセス権が必要です。
保存されたパケットファイルを読み取るのに特別な特権は必要ありません。
オプション
-a
ネットワークアドレスとブロードキャストアドレスを名前に変換しようとしています。
-c
カウントパケットを受信した後に終了します。
-C
生のパケットを保存ファイルに書き込む前に、そのファイルが現在file_sizeより大きいかどうかをチェックし、もしあれば、現在の保存ファイルを閉じて新しいファイルを開きます。 最初のセーブファイルの後のセーブファイルは、 -wフラグで指定された名前を持ちます。その後に番号が付けられ、2から開始して上に続きます。 file_sizeの単位は、何百万バイト（1,000,000バイト、1,048,576バイトではありません）です。
-d
コンパイルされたパケットマッチングコードを人間が読める形式で標準出力にダンプして停止します。
-dd
パケットマッチングコードをCプログラムの断片としてダンプします。
-ddd
パケットマッチングコードを10進数でダンプします（countで始まる）。
-e
各ダンプ行にリンクレベルのヘッダーを出力します。
-E
IPsec ESPパケットを解読するには、 algo：secretを使用します。 アルゴリズムは、 des-cbc 、 3des-cbc 、 blowfish-cbc 、 rc3-cbc 、 cast128-cbc 、またはnoneのいずれかです。 デフォルトはdes-cbcです。 パケットを解読する能力は、暗号化を有効にしてtcpdumpをコンパイルした場合にのみ存在します。 ESP秘密鍵のASCIIテキストを秘密にします。 現時点では、任意のバイナリ値をとることはできません。 このオプションはRFC2406 ESPであり、RFC1827 ESPではありません。 このオプションはデバッグの目的にのみ使用され、本当に `secret 'キーでこのオプションを使用することはお勧めしません。 コマンドラインにIPsec秘密鍵を提示することで、 ps （1）や他の機会を通じて他の人に見えるようにすることができます。
-f
シンボリックではなく数値的に `外国の 'インターネットアドレスを表示します（このオプションは、サンのypサーバーで重大な脳損傷を回避することを目的としています。通常、非ローカルインターネット番号の翻訳は永久に停止します）。
-F
フィルター式の入力としてfileを使用します 。 コマンドラインで与えられた追加の式は無視されます。
-私
インターフェイスで聞く。 指定されていない場合、 tcpdumpはシステムインタフェースリストから番号の付いた、設定されたインターフェイスのうち最も小さいものを検索します（ループバックは除く）。 一番早い試合を選ぶことで絆が崩れます。
2.2以降のカーネルを持つLinuxシステムでは、 `` any ''のインタフェース引数を使用して、すべてのインタフェースからパケットを取得できます。 `` any ''デバイス上のキャプチャはプロミスキャスモードでは行われないことに注意してください。
-l
stdout行をバッファします。 キャプチャ中にデータを表示する場合に便利です。 例えば、
`` tcpdump -l | tee dat ''または `` tcpdump -l> dat＆tail -f dat ''のいずれかです。
-m
ファイルモジュールからSMI MIBモジュール定義をロードします 。 このオプションを使用すると、複数のMIBモジュールをtcpdumpにロードすることができます。
-n
ホストアドレスを名前に変換しないでください。 これは、DNSルックアップを避けるために使用できます。
-nn
プロトコルやポート番号などを名前に変換しないでください。
-N
ホスト名のドメイン名の修飾は表示しないでください。 たとえば、このフラグを指定すると、 tcpdumpは `` nic.ddn.mil ''の代わりに `` nic ''を表示します。
-O
パケットマッチングコードオプティマイザを実行しないでください。 これは、オプティマイザのバグが疑われる場合にのみ有効です。
-p
インターフェイスをプロミスキャスモードにしないでください。 他の何らかの理由で、インターフェイスがプロミスキャスモードになっている可能性があります。 したがって `-p 'は` ether host {local-hw-addr}やetherブロードキャスト'の略語として使うことはできません。
-q
クイック（静かな）出力。 より少ないプロトコル情報を出力し、出力ラインを短くします。
-R
ESP / AHパケットが古い仕様（RFC1825〜RFC1829）に基づいていると仮定します。 指定した場合、 tcpdumpは再生防止フィールドを表示しません。 ESP / AH仕様にはプロトコルバージョンフィールドがないため、 tcpdumpはESP / AHプロトコルのバージョンを推測することはできません。
-r
ファイルからパケットを読み込みます （-wオプションで作成されたもの）。 ファイルが `` - ''の場合、標準入力が使用されます 。
-S
相対的ではなく絶対的なTCPシーケンス番号を出力します。
-s
Snarfは、デフォルトの68ではなく、各パケットからデータのバイトを作成します（SunOSのNITで、最小値は実際には96です）。 68バイトはIP、ICMP、TCP、UDPには適していますが、ネームサーバとNFSパケットからプロトコル情報を切り捨てることがあります（下記参照）。 スナップショットが限られているために切り詰められたパケットは、出力に `` [|]で示されます。 proto ] ''、 protoは切り捨てが発生したプロトコルレベルの名前です。 スナップショットを大きくすると、パケットの処理に要する時間が長くなり、効果的にパケットのバッファリング量が減少します。 これにより、パケットが失われる可能性があります。 snaplenを0に設定すると、必要な長さを使用してパケット全体を捕捉することになります。
-T
" 式 "によって選択されたパケットを指定された型に強制的に解釈します。 現在知られているタイプは、 cnfp （Cisco NetFlowプロトコル）、 rpc （リモートプロシージャコール）、 rtp （リアルタイムアプリケーションプロトコル）、 rtcp （リアルタイムアプリケーション制御プロトコル）、 snmp （簡易ネットワーク管理プロトコル）、 vat ）、 wb （分散型ホワイトボード）
-t
各ダンプ行にタイムスタンプを出力しないでください 。
-tt
各ダンプ行に書式なしのタイムスタンプを出力します。
-U
root権限を削除し 、ユーザーIDをユーザーおよびグループIDに変更して、ユーザーのプライマリ・グループに変更します 。
注意！ Red Hat Linuxは、何も指定されていなければ自動的に権限をユーザ `` pcap ''に落とします。
-ttt
各ダンプ行の現在の行と前の行との間にデルタ（マイクロ秒単位）を表示します。
-tttt
各ダンプ行の日付によって進められるデフォルトの形式のタイムスタンプを出力します。
-u
undecoded NFSハンドルを出力します。
-v
（やや詳細）冗長出力。 例えば、生存時間、識別、全長、およびIPパケットのオプションが印刷されます。 また、IPおよびICMPヘッダーチェックサムの検証など、パケットの完全性チェックを追加で可能にします。
-vv
より冗長な出力。 たとえば、追加のフィールドはNFS応答パケットから出力され、SMBパケットは完全にデコードされます。
-vvv
より冗長な出力。 たとえば、telnet SB ... SEオプションは完全に印刷されます。 -X telnetオプションは16進数でも表示されます。
-w
生のパケットを解析して印刷するのではなく、 ファイルに書き出します 。 後で-rオプションを付けて印刷することもできます。 ファイルが `` - ''の場合、標準出力が使用されます 。
-バツ
各パケット（リンクレベルヘッダを差し引いたもの）を16進数で表示します。 パケット全体またはスナッププランバイトのうち小さい方が出力されます。 これはリンク層パケット全体であることに注意してください。パッド層（例えばイーサネット）のリンク層では、上位層のパケットが必要なパディングより短い場合にもパディングバイトが印刷されます。
-バツ
16進数を印刷するときにasciiも印刷します。 したがって、 -xも設定されている場合、パケットは16進数/ ASCII形式で出力されます。 これは新しいプロトコルを分析するのに非常に便利です。 -xが設定されていなくても、いくつかのパケットの一部が16進数/ ASCII形式で出力されることがあります。
表現
どのパケットをダンプするかを選択します。 式が与えられなければ、ネット上のすべてのパケットがダンプされます。 そうでなければ、 式が真であるパケットだけがダンプされます。
式は1つ以上のプリミティブで構成されます。 プリミティブは、通常、1つ以上の修飾子が付いたID （名前または番号）で構成されます。 修飾子には3種類あります。
タイプ
修飾子は、IDの名前または番号がどのような種類のものを参照するかを示します。 可能なタイプは、 ホスト 、 ネット 、およびポートです。 例えば `host foo '、` net 128.3'、 `port 20 'などです。 型修飾子がない場合は、 ホストとみなされます。
指
修飾子はidと/またはidからの特定の転送方向を指定します。 可能な方向は、 src 、 dst 、 srcまたはdst 、 srcおよび dstです。 例えば `src foo '、` dst net 128.3'、 `src or dst port ftp-data 'のようになります。 dir修飾子がない場合、 srcまたはdstが仮定されます。 `ヌル 'リンク層（すなわち、スリップのようなポイント・ツー・ポイント・プロトコル）では、 インバウンドとアウトバウンドの修飾子を使用して、希望する方向を指定することができます。
元祖
修飾子は一致を特定のプロトコルに制限します。 考えられるプロトスは、 ether 、 fddi 、 tr 、 ip 、 ip6 、 arp 、 rarp 、 decnet 、 tcp 、 udpです。 例えば、 `ether src foo '、` arp net 128.3'、 `tcp port 21 'などです。 プロト修飾子がない場合は、その型と一致するすべてのプロトコルが仮定されます。 `` net bar ''は ``（ip or arp or rarp）net bar ''を意味し、 `` port 53 ''は ``（IP or arp or rarp）src foo ' `（tcpまたはudp）ポート53 '。
[`fddi 'は実際には` ether'のエイリアスです。 FDDIヘッダーにはイーサネットのような送信元と宛先のアドレスが含まれており、多くの場合イーサネットのようなパケットタイプが含まれているため、これらのFDDIフィールドでフィルタリングすることができます類似のイーサネットフィールドと同じように。 FDDIヘッダーには他のフィールドも含まれますが、フィルター式で明示的に名前を付けることはできません。
同様に、 `tr 'は` ether'のエイリアスです。 FDDIヘッダーに関する前の段落のステートメントもトークンリングヘッダーに適用されます。]
上記に加えて、パターンに従わない特別な「プリミティブ」キーワードがあります： ゲートウェイ 、 ブロードキャスト 、 less 、 greater 、算術式です。 これらのすべてについて以下で説明します。
より複雑なフィルタ式は、単語or 、 or 、 andを使用してプリミティブを結合することによって構築されます。 例えば、 `ホストfooでポートftpではなく、ポートftp-dataではない '。 型を節約するために、同じ修飾子リストを省略することができます。 たとえば、 `tcp dst port ftpまたはftp-data or domain 'は` tcp dst port ftpまたはtcp dst port ftp-dataまたはtcp dst port domain'とまったく同じです。
許容されるプリミティブは、
dstホスト ホスト
パケットのIPv4 / v6宛先フィールドがホスト （アドレスまたは名前のいずれか）である場合は真です。
srcホスト ホスト
パケットのIPv4 / v6ソースフィールドがホストの場合は真です。
ホスト ホスト
パケットのIPv4 / v6ソースまたは宛先のどちらかがホストの場合はtrue。 上記のホスト式のいずれかに、次のようにキーワードip 、 arp 、 rarp 、またはip6を付加することができます。
ipホスト ホストこれは以下と同等です：
ether proto \ ip とホスト ホストhostが複数のIPアドレスを持つ名前である場合、各アドレスの一致がチェックされます。
ether dst ehost
イーサネット宛先アドレスがehostの場合は真です。 Ehostは/ etc / ethersの名前でも、 数値でも構いません（数値形式の場合はethers （3N）を参照してください）。
ether src ehost
イーサネットソースアドレスがehostの場合は真です。
エーテルホスト ehost
イーサネットソースまたは宛先アドレスのいずれかがehostの場合は真です。
ゲートウェイ ホスト
パケットがホストをゲートウェイとして使用していれば真。 つまり、イーサネットソースまたは宛先アドレスがホストであったが、IPソースもIP宛先もホストではなかった。 ホストは名前でなければならず、マシンのホスト名/ IPアドレス解決メカニズム（ホスト名ファイル、DNS、NISなど）とマシンのホスト名/イーサネットアドレス解決の両方によって検出されなければなりませんメカニズム（/ etc /エーテルなど）。 （同等の表現は
etherホスト ehost でホスト ホスト ではないこれはhost / ehostの名前または番号のどちらでも使用できます）。この時点では、この構文はIPv6対応構成では機能しません。
dst net net
パケットのIPv4 / v6宛先アドレスにnetのネットワーク番号がある場合はtrue。 Netは/ etc / networksの名前かネットワーク番号です（詳細はネットワーク（4）を参照）。
src net net
パケットのIPv4 / v6送信元アドレスがnetのネットワーク番号を持つ場合はtrue。
ネット ネット
パケットのIPv4 / v6送信元アドレスまたは宛先アドレスのいずれかにnetのネットワーク番号がある場合はtrue。
ネット ネット マスク ネットマスク
IPアドレスがnetと特定のネットマスクと一致する場合はtrueです。 srcまたはdstで修飾されている可能性があります。 この構文はIPv6 ネットでは無効です。
net net / len
IPv4 / v6アドレスがnetとlenビット幅のネットマスクで一致する場合はtrue。 srcまたはdstで修飾されている可能性があります。
dstポート ポート
パケットがip / tcp、ip / udp、ip6 / tcp、またはip6 / udpで、宛先ポート値がportの場合は真です。 ポートは、/ etc / services（ tcp （4P）およびudp （4P）を参照）で使用される番号または名前にすることができます。 名前を使用する場合は、ポート番号とプロトコルの両方がチェックされます。 番号またはあいまいな名前を使用すると、ポート番号だけがチェックされます（たとえば、 dstポート513はtcp / loginトラフィックとudp / whoトラフィックの両方を出力し、 portドメインはtcp / domainとudp / domainトラフィックの両方を出力します）。
srcポート ポート
パケットの送信元ポート値がportの場合はtrue。
ポート ポート
パケットの送信元ポートまたは宛先ポートのいずれかがportの場合はtrue。 上記のいずれのポート式にも、次のようにキーワードtcpまたはudpを前に付けることができます。
tcp srcポート ポート送信元ポートがポートであるtcpパケットのみと一致します 。
短い 長さ
パケットの長さがlength以下の場合はtrue。 これは次のようになります。
len <= length 。より長い 長さ
パケットの長さがlength以上の場合はtrue。 これは次のようになります。
len> = 長さ 。ipプロト プロトコル
パケットがプロトコルタイププロトコルの IPパケット（ ip （4P）を参照）である場合は真です 。 Protocolには、 icmp 、 icmp6 、 igmp 、 igrp 、 pim 、 ah 、 esp 、 vrrp 、 udp 、またはtcpのいずれかの番号または1つを指定できます。 識別子tcp 、 udp 、およびicmpもキーワードであり、バックスラッシュ（\）を使用してエスケープする必要があります。これはCシェルの\\です。 このプリミティブはプロトコルヘッダーチェーンを追跡しないことに注意してください。
ip6プロト プロトコル
パケットがプロトコルタイププロトコルの IPv6パケットであれば真。 このプリミティブはプロトコルヘッダーチェーンを追跡しないことに注意してください。
ip6プロトコイン プロトコル
パケットがIPv6パケットであり、プロトコルヘッダーチェーンにプロトコルタイプのプロトコルヘッダーが含まれている場合はTrueです。 例えば、
ip6 protochain 6任意のIPv6パケットをプロトコルヘッダーチェーン内のTCPプロトコルヘッダーと照合します。 パケットは、IPv6ヘッダとTCPヘッダとの間に、例えば、認証ヘッダ、ルーティングヘッダ、またはホップバイホップオプションヘッダを含むことができる。 このプリミティブによって生成されたBPFコードは複雑で、 tcpdumpの BPFオプティマイザコードでは最適化できないため、やや遅くなる可能性があります。
ip protochain プロトコル
ip6 protochain プロトコルに相当しますが、これはIPv4用です。
エーテル放送
パケットがイーサネットブロードキャストパケットであれば真。 etherキーワードはオプションです。
ipブロードキャスト
パケットがIPブロードキャストパケットの場合はtrueです。 これは、オールゼロとすべてのブロードキャストの両方の規則をチェックし、ローカルサブネットマスクをルックアップします。
エーテルマルチキャスト
パケットがイーサネットマルチキャストパケットであれば真。 etherキーワードはオプションです。 これは ` ether [0]＆1！= 0 'の省略形です。
ipマルチキャスト
パケットがIPマルチキャストパケットであれば真。
ip6マルチキャスト
パケットがIPv6マルチキャストパケットであれば真。
エーテルプロト プロトコル
パケットがetherタイプのプロトコルの場合は真です 。 プロトコルには、 ip 、 ip6 、 arp 、 rarp 、 atalk 、 aarp 、 decnet 、 sca 、 lat 、 mopdl 、 moprc 、 iso 、 stp 、 ipx 、またはnetbeuiのいずれかの番号または1つを指定できます。 これらの識別子はキーワードでもあり、バックスラッシュ（\）でエスケープする必要があります。
[FDDI（ fddiプロトコルarp ）やトークンリング（例えば、 trプロトコルarp ）の場合、これらのプロトコルのほとんどでは、プロトコル識別は802.2論理リンク制御（LLC）ヘッダに由来します。 FDDIまたはトークンリングヘッダーの上部に通常階層化されています。
FDDIまたはトークンリング上のほとんどのプロトコル識別子をフィルタリングする場合、 tcpdumpはカプセル化されたイーサネットの組織単位識別子（OUI）が0x000000のいわゆるSNAP形式のLLCヘッダーのプロトコルIDフィールドのみをチェックします。 パケットが0x000000のOUIでSNAP形式であるかどうかをチェックしません。
例外はisoであり、LLCヘッダーのDSAP（Destination Service Access Point）フィールドとSSAP（Source Service Access Point）フィールド、 stpとnetbeui 、LLCヘッダーのDSAPをチェックし、 atalk 0x080007のOUIとAppletalk etypeを持つSNAP形式のパケットをチェックします。
イーサネットの場合、 tcpdumpはこれらのプロトコルのほとんどのイーサネットタイプフィールドをチェックします。 例外はiso 、 sap 、 netbeuiであり、802.3フレームをチェックし、FDDIとトークンリングatalkの場合と同様にLLCヘッダーをチェックし、イーサネットフレームのAppletalk etypeとFDDIとトークンリング、 aarpの場合と同様にSNAP形式のパケットは、OUIが0x000000のイーサネットフレームまたは802.2 SNAPフレームのAppletalk ARP etypeと、IPX etypeがあるかどうかを確認するipxイーサネットフレーム、LLCヘッダー内のIPX DSAP、IPXのLLCヘッダーカプセル化がない802.3、およびSNAPフレーム内のIPX etype）。
decnet src host
DECNETソース・アドレスがホストであれば真です。これは `` 10.123 ''の形式のアドレス、またはDECNETホスト名です。 [DECNETホスト名のサポートは、DECNETを実行するように構成されたUltrixシステムでのみ使用可能です。]
decnet dst host
DECNET宛先アドレスがhostの場合は真です。
デネットホスト ホスト
DECNETの送信元アドレスまたは宛先アドレスのどちらかがホストの場合は真です。
ip 、 ip6 、 arp 、 rarp 、 atalk 、 aarp 、 decnet 、 iso 、 stp 、 ipx 、 netbeui
略語：
エーテルプロトンここで、 pは上記のプロトコルの1つです。
lat 、 moprc 、 mopdl
略語：
エーテルプロトンここで、 pは上記のプロトコルの1つです。 tcpdumpは現在、これらのプロトコルの解析方法を知らないことに注意してください。
vlan [vlan_id]
パケットがIEEE 802.1Q VLANパケットであれば真。 [vlan_id]が指定されている場合、パケットにはvlan_idが指定されているだけです。 式で遭遇する最初のvlanキーワードは、パケットがVLANパケットであると仮定して残りの式の復号オフセットを変更することに注意してください。
tcp 、 udp 、 icmp
略語：
ip proto p またはip6 proto pここで、 pは上記のプロトコルの1つです。
イソプロト プロトコール
パケットがプロトコルタイププロトコルの OSIパケットであれば真。 Protocolには、 clnp 、 esis 、またはisisという名前の番号または1つを指定できます。
clnp 、 esis 、 isis
略語：
イソプロプロトここで、 pは上記のプロトコルの1つです。 tcpdumpはこれらのプロトコルを解析する不完全な仕事をします。
expr relop expr
関係が保持されている場合はtrue、 relopは>、<、> =、<=、=、！=のいずれかであり、 exprは整数定数（標準C構文で表される）、通常の2項演算子[ 、 - 、*、/、＆、|]、長さ演算子、および特別なパケットデータアクセサです。 パケット内のデータにアクセスするには、次の構文を使用します。
proto [ expr ： size ]Protoは、 ether、fddi、tr、ppp、slip、link、ip、arp、rarp、tcp、udp、icmpまたはip6のいずれかであり、インデックス操作のプロトコル層を示します。 （ ether、fddi、tr、ppp、slip 、 linkはすべてリンク層を指します） 。tcp、 udpなどの上位層のプロトコルタイプは、IPv6ではなくIPv4にのみ適用されます（これは将来修正される予定です）。 示されたプロトコル層に対するバイトオフセットは、 exprによって与えられます。 Sizeはオプションで、対象フィールド内のバイト数を示します。 1つ、2つ、または4つのいずれかになり、デフォルトは1になります。 長さ演算子は、キーワードlenで示され、パケットの長さを示します。
たとえば、 ` ether [0]＆1！= 0 'はすべてのマルチキャストトラフィックをキャッチします。 式 ` ip [0]＆0xf！= 5 'はオプション付きのすべてのIPパケットをキャッチします。 式 ` ip [6：2]＆0x1fff = 0 'は断片化されていないデータグラムと断片化されたデータグラムのフラグゼロだけをキャッチします。 このチェックは、 tcpおよびudpインデックス操作に暗黙的に適用されます。 たとえば、 tcp [0]は常にTCP ヘッダの最初のバイトを意味し、介在するフラグメントの最初のバイトを意味するものではありません。
いくつかのオフセットおよびフィールド値は、数値としてではなく名前として表される場合があります。 icmptype （ICMPタイプフィールド）、ICMPコード（ICMPコードフィールド）、およびtcpflags （TCPフラグフィールド）のプロトコルヘッダーフィールドオフセットを使用できます。
icmp-echoreply 、 icmp-unreach 、 icmp-sourcequench 、 icmp-redirect 、 icmp-echo 、 icmp-routeradvert 、 icmp-routersolicit 、 icmp-timxceed 、 icmp-paramprob 、 icmp-tstamp 、 icmpの ICMPタイプフィールド値が利用可能です-stamp 、 icmp-ireq 、 icmp-ireqreply 、 icmp-maskreq 、 icmp-maskreply 。
tcp-fin 、 tcp-syn 、 tcp-rst 、 tcp-push 、 tcp-push 、 tcp-ack 、 tcp-urgの各TCPフラグフィールド値を使用できます。
プリミティブは、以下を使用して結合できます。
カッコで囲まれたプリミティブと演算子のグループ（かっこはシェルにとって特別であり、エスケープする必要があります）。
否定（ ` ！ 'または` not '）。
連結（ ` && 'または` and '）。
交替（ ` || 'または` or '）。
否定は最も高い優先順位を持つ。 交替と連結は同じ優先順位を持ち、左から右に関連付けられます。 並列化ではなく、明示的トークンとトークンが連結に必要であることに注意してください。
キーワードなしで識別子が与えられた場合、最も新しいキーワードが仮定されます。 例えば、
ホスト対エースではない短くて
ホストとホストのエースではないそれはと混同すべきではありません
ない（ホスト対エース）式引数は、単一の引数または複数の引数のいずれかとして、より便利なtcpdumpに渡すことができます。 一般に、式にシェルのメタキャラクタが含まれている場合は、引用符で囲まれた単一の引数として渡す方が簡単です。 複数の引数は、解析される前にスペースで連結されます。
使用例
日没に到着または出発するすべてのパケットを印刷するには：
tcpdumpホストのダウントウheliosとhotまたはaceの間でトラフィックを印刷するには：
tcpdumpホストheliosと\（ホットまたはエース）エースとヘリオスを除くすべてのホストとの間ですべてのIPパケットを印刷するには：
tcpdump ip host aceとheliosではないBerkeleyのローカルホストとホスト間のすべてのトラフィックを印刷するには：
tcpdump net ucb-etherインターネットゲートウェイsnupを介してすべてのftpトラフィックを出力するには ：（シェルが括弧を誤って解釈しないように式が引用されていることに注意してください）
tcpdump 'ゲートウェイsnupと（ポートftpまたはftp-data）'ローカルホストからのトラフィックでも、ローカルホストでもないトラフィックを印刷するには（他のネットに接続する場合は、ローカルネット上に決して配置しないでください）。
tcpdump ipおよびネットネットではない非ローカルホストを含む各TCP会話の開始パケットと終了パケット（SYNとFINパケット）を出力する。
tcpdump 'tcp [tcpflags]＆（tcp-syn | tcp-fin）！= 0ではなく、srcとdst net localnet 'ゲートウェイsnupを介して送信された576バイトより長いIPパケットを出力するには ：
tcpdump 'ゲートウェイsnupおよびip [2：2]> 576'イーサネットブロードキャストまたはマルチキャスト経由で送信されなかった IPブロードキャストまたはマルチキャストパケットを印刷するには、次の手順を実行します。
tcpdump 'ether [0]＆1 = 0、ip [16]> = 224'エコー要求/応答ではないすべてのICMPパケットを出力する（つまり、pingパケットではない）：
tcpdump 'icmp [icmptype]！= icmp-echoとicmp [icmptype]！= icmp-echoreply'出力フォーマット
tcpdumpの出力はプロトコルに依存します。 以下に、ほとんどの形式の簡単な説明と例を示します。
リンクレベルヘッダー
'-e'オプションを指定すると、リンクレベルヘッダが出力されます。 イーサネット上では、送信元アドレスと宛先アドレス、プロトコル、およびパケット長が出力されます。
FDDIネットワークでは、 '-e'オプションを指定すると、 tcpdumpは `frame control 'フィールド、送信元アドレスと宛先アドレス、およびパケット長を出力します。 （ `frame control 'フィールドはパケットの残りの部分を解釈します。通常のパケット（IPデータグラムを含むパケットなど）は` async'パケットで、優先順位は0〜7です。パケットには802.2論理リンク制御（LLC）パケットが含まれているものとみなされ、LLCヘッダーはISOデータグラムまたはいわゆるSNAPパケットでない場合に印刷されます。
トークンリングネットワークでは、 '-e'オプションを指定すると、 tcpdumpは `access control 'と` frame control'フィールド、送信元と宛先アドレス、パケットの長さを表示します。 FDDIネットワークの場合と同様に、パケットはLLCパケットを含むと仮定される。 '-e'オプションが指定されているかどうかにかかわらず、ソースルーティング情報はソースルートパケット用に出力されます。
（注：以下の記述は、RFC-1144に記述されているSLIP圧縮アルゴリズムに精通していることを前提としています。）
SLIPリンクでは、方向インジケータ（インバウンドの場合は「I」、アウトバウンドの場合は「O」）、パケットタイプ、および圧縮情報が出力されます。 パケットタイプが最初に印刷されます。 3つのタイプはip 、 utcp 、およびctcpです。 ipパケットには、それ以上のリンク情報は表示されません。 TCPパケットの場合は、接続識別子がタイプに従って出力されます。 パケットが圧縮されている場合、そのエンコードされたヘッダーが出力されます。 特殊なケースは、 * S + nと* SA + nとして出力されます .nはシーケンス番号（またはシーケンス番号とack）が変更された量です。 特殊なケースでない場合は、0回以上の変更が出力されます。 変更は、U（緊急ポインタ）、W（ウィンドウ）、A（ack）、S（シーケンス番号）、およびI（パケットID）の後にデルタ（+ nまたは-n）、または新しい値（= n）である。 最後に、パケット内のデータ量と圧縮ヘッダ長が出力されます。
たとえば、次の行は、暗黙の接続識別子を持つ発信圧縮パケットを示しています。 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-csamさんはrtsg arp reply csamさんに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：c4tcpdump -eを実行した場合、最初のパケットがブロードキャストされ、2番目のパケットがポイントツーポイントであるという事実が見えます：
RTSGブロードキャスト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プロトコルに精通していることを前提としています。プロトコルに精通していない場合は、この説明もtcpdumpも大変役に立ちません。
tcpプロトコル行の一般的な形式は次のとおりです。
src> dst：flags data-seqno ackウィンドウ緊急オプション Srcとdstは送信元と宛先のIPアドレスとポートです。 フラグは、S（SYN）、F（FIN）、P（PUSH）、R（RST）、または単一の `。 （フラグなし）。 Data-seqnoは、このパケット内のデータによってカバーされるシーケンススペースの部分を記述する（以下の例を参照）。 Ackは、この接続上で他の方向に予測される次のデータのシーケンス番号です。 ウィンドウは、この接続の他の方向で利用可能な受信バッファスペースのバイト数です。 Urgはパケットに「緊急」なデータがあることを示します。 オプションは山括弧で囲まれたtcpオプションです（例：
Src、dst 、 flagsは常に存在します。 その他のフィールドは、パケットのTCPプロトコルヘッダーの内容に依存し、適切な場合にのみ出力されます。
ここには、ホストrtsgからホストcsamまでのrloginの開始部分があります。
rtsg.1023> csam.login：S 768512：768512（0）win 4096最初の行は、rtsgのtcpポート1023がcsamのポートログインにパケットを送信したことを示しています。 Sは、 SYNフラグが設定されたことを示します。 パケットシーケンス番号は768512であり、データは含まれていませんでした。 （表記は `first：last（nbytes） 'です。これは` nbytesバイトのユーザデータである最後から最後までは含まないシーケンス番号を意味します'）。ピギーバックAckはなく、利用可能な受信ウィンドウは4096バイトで、 1024バイトのmssを要求するmax-segment-sizeオプションがありました。
Csamは同様のパケットで応答しますが、rtsgのSYNにはピギーバックのackが含まれています。 RtsgはcsamのSYNを受け取ります。 `。 ' フラグが設定されていないことを意味します。 パケットにはデータが含まれていないため、データシーケンス番号はありません。 ackシーケンス番号は小さい整数（1）であることに注意してください。 最初のtcpdumpはtcp `会話 'を見て、パケットからシーケンス番号を出力します。 会話の後続パケットでは、現在のパケットのシーケンス番号とこの初期シーケンス番号との間の差異が印刷される。 つまり、最初のバイトの後のシーケンス番号は、会話のデータストリーム内の相対バイト位置として解釈できます（最初のデータバイトは各方向が `1 '）。 `-S 'はこの機能を無効にし、元のシーケンス番号を出力します。
6行目では、rtsgがcsamに19バイトのデータ（会話のrtsg - > csam側の2〜20バイト）を送信します。 PUSHフラグがパケットに設定されます。 7行目では、csamはrtsgから受信したバイト21までのデータを受信したと報告しています。このデータの大部分は、csamの受信ウィンドウが19バイト小さくなっているため、ソケットバッファに格納されています。 Csamはこのパケットの1バイトのデータをrtsgに送信します。 8行目と9行目で、csamは2バイトの緊急プッシュデータをrtsgに送信します。
tcpdumpが完全なTCPヘッダーを取得しないほどスナップショットが小さかった場合は、可能な限り多くのヘッダーを解釈し、 `` [| tcp ] ''を使用して、残りを解釈できなかったことを示します。 ヘッダーに偽のオプションが含まれている場合（長さが小さすぎるか、ヘッダーの終わりを超えている場合）、 tcpdumpは `` [ bad opt ] ''と報告し、それ以上のオプションは解釈しません彼らがどこで始まるか）。 ヘッダーの長さがオプションが存在するがIPデータグラムの長さが実際にそこに存在するための十分な長さでない場合、 tcpdumpは `` [ bad hdr length ] ''と報告します。
特定のフラグの組み合わせ（SYN-ACK、URG-ACKなど）を使用してTCPパケットをキャプチャする
TCPヘッダーの制御ビットセクションには8ビットあります。
CWR | ECE | URG | ACK | PSH | RST | SYN | フィン
TCP接続の確立に使用されるパケットを監視したいと仮定しましょう。 TCPは、新しい接続を初期化するときに3方向ハンドシェイクプロトコルを使用することを思い出してください。 TCP制御ビットに関する接続シーケンスは、
1）発信者はSYN
2）受信者がSYN、ACKで応答する
3）発信者がACKを送信する
今度は、SYNビットのみが設定されたパケットをキャプチャすることに興味があります（ステップ1）。 我々はステップ2（SYN-ACK）からのパケット、単純な初期SYNだけを望んでいないことに注意してください。 必要なのは、 tcpdumpの正しいフィルタ式です。
オプションのないTCPヘッダーの構造を思い出してください：
0 15 31 ----------------------------------------------- ------------------ | | | -------------------------------------------------- --------------- | | -------------------------------------------------- --------------- | | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | |ウィンドウサイズ| -------------------------------------------------- --------------- | TCPチェックサム| 緊急ポインタ| -------------------------------------------------- ---------------オプションが存在しない限り、TCPヘッダーは通常20オクテットのデータを保持します。 グラフの最初の行にはオクテット0〜3が含まれ、2番目の行にはオクテット4〜7などが表示されます。
0でカウントすることを開始すると、関連するTCP制御ビットはオクテット13に含まれます。
0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | |ウィンドウサイズ| ---------------- | --------------- | --------------- | - --------------- | | | 13オクテット| | |オクテット番号を詳しく見てみましょう。 13：
| | | --------------- | | C | E | U | A | P | R | S | F | | --------------- | | 7 5 3 0 |これらは私たちが興味を持っているTCP制御ビットです。このオクテットのビットを右から左へ0から7まで番号付けしていますので、PSHビットはビット番号3、URGビットは番号5です。
SYNが設定されたパケットだけをキャプチャすることを思い出してください。 TCPデータグラムが到着し、SYNビットがヘッダに設定されている場合、オクテット13がどうなるかを見てみましょう：
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 0 0 0 0 | | --------------- | | 7 6 5 4 3 2 1 0 |制御ビットセクションを見ると、ビット番号1（SYN）だけが設定されていることがわかります。
オクテット番号13がネットワークバイトオーダーの8ビット符号なし整数であると仮定すると、このオクテットのバイナリ値は
00000010
その小数点は
7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2SYNが設定されていれば、TCPヘッダの13番目のオクテットの値は、ネットワークバイトオーダーで8ビットの符号なし整数として解釈されるとき、正確に2でなければならないことがわかっているので、ほぼ完了しました。
この関係は、次のように表すことができます。
tcp [13] == 2
この式をtcpdumpのフィルタとして使用して、SYNのみが設定されたパケットを監視することができます。
tcpdump -i xl0 tcp [13] == 2
式は「TCPデータグラムの13番目のオクテットに10進値2を持たせる」と言っています。これはまさに私たちが望むものです。
ここで、SYNパケットをキャプチャする必要があると仮定しますが、ACKや他のTCP制御ビットが同時に設定されているかどうかは気にしません。 SYN-ACKセットを持つTCPデータグラムが到着したときにオクテット13がどうなるかを見てみましょう：
| C | E | U | A | P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |今、ビット1と4は13番目のオクテットに設定されます。 オクテット13のバイナリ値は次のとおりです。
00010010
これは10進数に変換されます
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今度は、 tcpdumpフィルタ式で 'tcp [13] == 18'を使うことはできません。これは、SYN-ACKが設定されたパケットだけを選択し、SYNのみを設定したパケットは選択しないためです。 SYNが設定されている限り、ACKやその他の制御ビットが設定されているかどうかは気にしません。
私たちの目標を達成するためには、オクテット13のバイナリ値をSYNビットを保存するために他の値と論理的にANDする必要があります。 どのような場合でもSYNを設定することが望ましいので、13番目のオクテットの値とSYNのバイナリ値を論理的にANDします。
00010010 SYN-ACK 00000010 SYNと00000010（SYNが必要）と00000010（SYNが必要）-------- -------- = 00000010 = 00000010このAND演算はACKか別のTCP制御ビットが設定されているかどうかにかかわらず同じ結果を提供することがわかります。 この演算の結果と同様に、AND値の小数表現は2（2進数00000010）です。したがって、SYNが設定されたパケットの場合、次の関係が成り立つ必要があります。
（（オクテット13の値AND（2））==（2）
これは、 tcpdumpフィルタ式を示しています
tcpdump -i xl0 'tcp [13]＆2 == 2'
式の中に一重引用符またはバックスラッシュを使用して、AND（ '＆'）特殊文字をシェルから隠す必要があることに注意してください。
UDPパケット
UDPフォーマットは、このrwhoパケットによって示されています。
actinide.who>放送。誰：udp 84これは、ホストアクチニド上のポートがホストブロードキャストの誰かのポートにインターネットブロードキャストアドレスを送信することを示しています。 パケットには84バイトのユーザーデータが含まれていました。
一部のUDPサービスが認識され（送信元または宛先ポート番号から）、上位プロトコル情報が表示されます。 特に、NFSへのドメインネームサービス要求（RFC-1034/1035）とSun RPC呼び出し（RFC-1050）。
UDPネームサーバー要求
（注意：以下の説明は、RFC-1035に記述されているドメインサービスプロトコルに精通していることを前提としていますが、プロトコルに慣れていない場合は以下の説明がギリシャ語で書かれているようです）。
ネームサーバ要求は、
src> dst：id op？ フラグqtype qクラス名（len） h2opolo.1538> helios.domain：3+ A？ ucbvax.berkeley.edu。 （37）ホストh2opoloはhelios上のドメインサーバーにucbvax.berkeley.eduという名前に関連付けられたアドレスレコード（qtype = A）を要求しました。 クエリIDは `3 'です。 `+ 'は再帰要求フラグが設定されたことを示します。 クエリーの長さは37バイトで、UDPおよびIPプロトコルヘッダーは含まれませんでした。 照会操作は通常の照会操作であったため、操作フィールドは省略されました。 opが他のものであれば、 `3 'と` +'の間に出力されていたでしょう。 同様に、qclassは通常のC_INであり、省略されています。 他のqclassは `A 'の直後に出力されます。
いくつかの異常がチェックされ、余分なフィールドが角カッコで囲まれている可能性があります。クエリに回答が含まれている場合、権限レコードまたは追加レコードセクション、 ancount 、 nscount 、またはarcountは `[ n a] '、` [ n n ] 'または `[ n au]'であり、 nは適切な数です。 応答ビットのいずれかが設定されている場合（AA、RAまたはrcode）、または「0でなければならない」ビットのいずれかがバイト2と3で設定されている場合、 xは16進数の値である[b2と3 = x ]ヘッダーバイトは2と3です。
UDPネームサーバの応答
ネームサーバの応答は、
src> dst：id opcodeフラグa / n / auタイプクラスデータ（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レコード（クエリ）とレスポンスコード（NoError）は、Aレコードのクラス（C_IN）と同様に省略されました。
2番目の例では、 heliosは、応答なし、存在しないドメイン（NXDomain）のレスポンスコード、1つのネームサーバー、および権限レコードなしでクエリ2に応答します。 `* 'は、 正式な回答ビットが設定されたことを示します。 回答がなかったので、タイプ、クラス、データは印刷されませんでした。
他のフラグ文字は ` - '（再帰可能、RA、 未設定）と` |' （切り詰められたメッセージ、TC、セット）。 `question 'セクションに正確に1つのエントリが含まれていない場合、` [ n q]'が表示されます。
ネームサーバの要求と応答は大きくなる傾向があり、デフォルトのスナッププランの68バイトでは、パケットを印刷するのに十分な量が得られないことに注意してください。 ネーム・サーバーのトラフィックを真剣に調査する必要がある場合は、 -sフラグを使用してスナッププランを増やします。 ` -s 128 'は私のためにうまくいきました。
SMB / CIFSデコード
tcpdumpには、UDP / 137、UDP / 138、TCP / 139のデータに対するかなり広範なSMB / CIFS / NBTデコードが含まれています。 IPXおよびNetBEUI SMBデータのプリミティブなデコードも行われます。
デフォルトでは、かなり最小のデコードが行われ、-vが使用された場合にはより詳細なデコードが行われます。 -va単一のSMBパケットは1ページ以上を占める可能性があるので、実際にすべての詳細を知りたい場合にのみ-vを使用してください。
ユニコード文字列を含むSMBセッションをデコードする場合は、環境変数USE_UNICODEを1に設定したい場合があります。ユニコード文字の自動検出のパッチは大歓迎です。
SMBパケットフォーマットとすべてのteフィールドの意味については、お気に入りのsamba.orgミラーサイトのwww.cifs.orgまたはpub / samba / specs /ディレクトリを参照してください。 SMBパッチは、Andrew Tridgell（tridge@samba.org）によって作成されました。
NFS要求と応答
Sun NFS（ネットワークファイルシステム）の要求と応答は、次のように出力されます。
src.xid> dst.nfs：len op args src.nfs> dst.xid：応答統計結果 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ルックアップfh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b：reply ok 128ルックアップfh 9,74 / 4134.3150最初の行では、ホストの寿司はid 6709のトランザクションをwrlに送信します（srcホストに続く数字はソースポートではなくトランザクションIDです）。 要求はUDPヘッダーとIPヘッダーを除いて112バイトでした。 操作はファイルハンドル（ fh ）21,24 / 10.731657119の読み取りリンク（シンボリックリンクを読む）でした。 （この場合のように運が良ければ、ファイルハンドルはメジャー、マイナーデバイス番号の組、その後のinode番号と世代番号として解釈できます） .Wrlは `ok 'にリンクの内容を返します。
3行目では、ディレクトリファイル9,74 / 4096.6878の ` xcolors 'という名前を参照するようにwrlに問い合わせます。 印刷されるデータは、操作の種類によって異なります。 このフォーマットは、NFSプロトコル仕様と併せて読めば、自明であることを意図しています。
-v（冗長）フラグを指定すると、追加情報が表示されます。 例えば：
sushi.1372a> wrl.nfs：148 read fh 21,11 / 12.195 8192 bytes @ 24576 wrl.nfs> sushi.1372a：返信OK 1472読み取りREG 100664 ids 417/0 sz 29388（この例では省略されているIPヘッダーのTTL、ID、長さ、フラグメンテーションフィールドも表示されます）。最初の行で、 sushiは、ファイル21,11 / 12.195からバイトオフセットで8192バイトを読みとるようにwrlに求めます24576. Wrlが `ok 'と答えます。 2行目に表示されているパケットは応答の最初のフラグメントであるため、長さはわずか1472バイトです（他のバイトは後続のフラグメントで続きますが、これらのフラグメントにはNFSヘッダーまたはUDPヘッダーがないため、使用されるフィルター式に応じて）。 -vフラグが指定されているので、ファイルタイプ（ `` REG ''、通常ファイル）、ファイルモード（8進数）、ファイルタイプuidとgid、およびファイルサイズ。
-vフラグが複数回指定されると、さらに詳細が表示されます。
NFS要求は非常に大きく、 snaplenを増やさないと詳細の多くが出力されないことに注意してください。 ` -s 192 'を使ってNFSトラフィックを調べてみてください。
NFS応答パケットは、RPC操作を明示的に識別しません。 代わりに、 tcpdumpは ``最近の ''リクエストを追跡し、それらをトランザクションIDを使って返答と照合します。 応答が対応する要求に厳密に従わない場合、解析できない可能性があります。
AFS要求と応答
Transarc AFS（Andrew File System）の要求と応答は次のように出力されます。
src.sport> dst.dport：rx packet-type src.sport> dst.dport：rxパケットタイプのサービスコールcall-name args src.sport> dst.dport：rxパケットタイプサービスの応答コール名args elvis。 7001> pike.afsfs：rxデータfsコールの名前変更古いfid 536876964/1/1 ".newsrc.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呼び出し名でデコードされます。 ほとんどのAFS RPCには、少なくともいくつかの引数がデコードされています（興味深い定義のために、一般的には「面白い」引数のみです）。
フォーマットは自己記述的なものですが、AFSやRXの仕組みに精通していない人にとってはおそらく役に立ちません。
-v（冗長）フラグを2回指定すると、RX呼び出しID、呼び出し番号、シーケンス番号、シリアル番号、RXパケットフラグなど、確認応答パケットと追加のヘッダー情報が出力されます。
-vフラグを2回指定すると、RX呼び出しID、シリアル番号、RXパケットフラグなどの追加情報が出力されます。 MTUネゴシエーション情報は、RX ACKパケットからも出力されます。
-vフラグが3回指定されると、セキュリティー・インデックスとサービスIDが出力されます。
エラーコードは、Ubikビーコンパケットを除いて、アボートパケット用に印刷されます（アボートパケットはUbikプロトコルのためにイエス投票を示すために使用されるため）。
AFS要求は非常に大きく、 snaplenを増やさないと多くの引数が出力されないことに注意してください。 ` -s 256 'を使ってAFSトラフィックを監視してみてください。
AFS応答パケットは、RPC操作を明示的に識別しません。 代わりに、 tcpdumpは ``最近の ''リクエストを追跡し、呼び出し番号とサービスIDを使って応答にマッチさせます。 応答が対応する要求に厳密に従わない場合、解析できない可能性があります。
KIP Appletalk（UDPのDDP）
Appletalk UDPデータグラムにカプセル化されたDDPパケットはカプセル化され、DDPパケットとしてダンプされます（つまり、すべてのUDPヘッダー情報は破棄されます）。 /etc/atalk.namesファイルは、appletalkのネット番号とノード番号を名前に変換するために使用されます。 このファイルの行には次の形式があります。
番号名 1.254エーテル16.1 icsd-net 1.254.110エース最初の2行はappletalkネットワークの名前を与えます。 3行目は特定のホストの名前を示します（ホストは数字の3番目のオクテットでネットと区別されます - ネット番号は2オクテットで、ホスト番号は3オクテットでなければなりません ）。番号と名前は分離する必要があります空白（空白またはタブ）で囲みます。 /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のNBP（DDPポート2）ノード209は、ネットicsdノード112のポート220をリッスンしているものに送信している。ソースノードのフルネームが分かっていることを除いて、第2行は同じである（「オフィス」）。 3番目の行は、net jssmagノード149のポート235からicsd-net NBPポートでブロードキャストするためのものです（ブロードキャストアドレス（255）はホスト名のないネット名で示されていることに注意してください）。 /etc/atalk.namesでノード名とネット名を区別します）。
NBP（ネームバインディングプロトコル）とATP（Appletalkトランザクションプロトコル）パケットの内容は解釈されます。 他のプロトコルは、プロトコル名（またはプロトコルに名前が登録されていない場合は番号）とパケットサイズをダンプします。
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最初の行は、net icsdホスト112によって送信され、ネットjssmagでブロードキャストされたレーザーライターの名前検索要求です。 ルックアップのnbp IDは190です。2行目には、ホストjssmag.209からのこの要求に対するリプライ（ポート番号250に登録された "RM1140"という名前のレーザーライターリソースがあることを示しています）同じ要請に対する別の返答で、ホストtechpitにポート186にレーザーライター "techpit"が登録されていると言っています。
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> 0xae030002Jssmag.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（`一度だけ'）が設定されていないことを示します。
IP断片化
断片化されたインターネットデータグラムは、
（frag id ： size @ offset +） （frag id ： size @ offset ）（最初のフォームはフラグメントがさらにあることを示し、2番目のフラグメントは最後のフラグメントであることを示します）。
IdはフラグメントIDです。 Sizeは、IPヘッダーを除いたフラグメントサイズ（バイト単位）です。 オフセットは、元のデータグラムにおけるこのフラグメントのオフセット（バイト単位）です。
フラグメント情報は、各フラグメントについて出力される。 最初のフラグメントには上位レベルのプロトコルヘッダーが含まれ、フラグ情報はプロトコル情報の後に出力されます。 最初の後のフラグメントには、上位レベルのプロトコルヘッダーが含まれておらず、フラグメント情報はソースアドレスと宛先アドレスの後に出力されます。 たとえば、576バイトのデータグラムを処理していないCSNET接続上のarizona.eduからlbl-rtsg.arpaまでのftpの一部を次に示します。
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：。 アック1536勝2560ここで注意すべき点がいくつかあります。まず、2行目のアドレスにはポート番号が含まれていません。 これは、TCPプロトコル情報がすべて最初のフラグメントにあり、後のフラグメントを印刷するときにポート番号またはシーケンス番号が何であるかわからないためです。 第2に、1行目のtcpシーケンス情報は、実際には512バイト（最初のフラグメントに308、2番目に204）の308バイトのデータがあるかのように出力されます。 シーケンススペースに穴を探している場合や、パケットと一致するようにしようとする場合、これはあなたを欺くことができます。
IP do not fragmentフラグを持つパケットは、末尾（DF）でマークされます。
タイムスタンプ
デフォルトでは、すべての出力行の前にタイムスタンプが付きます。 タイムスタンプはフォーム内の現在の時計時刻です
hh：mm：ss.fracカーネルの時計ほど正確です。 タイムスタンプは、カーネルがパケットを最初に見た時刻を反映しています。 イーサネットインターフェイスがパケットをワイヤから取り除いたときと、カーネルが `新しいパケット '割り込みを処理したときとの間のタイムラグを考慮する試みは行われていません。
関連項目
トラフィック（1C）、nit（4P）、bpf（4）、pcap（3）
重要： manコマンド（ ％man ）を使用して、特定のコンピュータでコマンドがどのように使用されているかを確認してください。