|
導入 簡単に言えば、tcpdump は、ネットワーク上のトラフィックをダンプし、ユーザーの定義に従ってネットワーク上のデータ パケットを傍受するパケット分析ツールです。 Tcpdump は、ネットワークで送信されるデータ パケットの「ヘッダー」を完全に傍受し、分析を提供できます。ネットワーク層、プロトコル、ホスト、ネットワーク、またはポートのフィルタリングをサポートし、and、or、not などの論理ステートメントを提供して、不要な情報を削除します。 実用的なコマンド例 デフォルトの起動 通常、tcpdump を直接起動すると、最初のネットワーク インターフェイスを通過するすべてのパケットが監視されます。 指定されたネットワークインターフェース上のパケットを監視する ネットワーク カードを指定しない場合、デフォルトでは tcpdump は最初のネットワーク インターフェイス (通常は eth0) のみを監視します。次の例では、ネットワーク インターフェイスを指定していません。 指定されたホストからのパケットを監視する 日没時に出入りするすべてのパケットを印刷します。 IPアドレスを指定して、例えば210.27.48.1のホストが送受信したすべてのパケットをキャプチャすることもできます。 heliosとhotまたはace間のデータパケットを印刷する
tcpdump ホスト helios および \( hot または ace \) ホスト 210.27.48.1 とホスト 210.27.48.2 または 210.27.48.3 間の通信を傍受する
tcpdump ホスト 210.27.48.1 および \ (210.27.48.2 または 210.27.48.3 \) ace と他のホスト間の IP パケットを印刷しますが、helios 間の IP パケットは印刷しません。
tcpdump ip ホスト ace および helios ではない ホスト 210.27.48.2 を除くすべてのホストの IP パケットを取得する場合は、次のコマンドを使用します。
tcpdump ip ホスト 210.27.48.1 および ! 210.27.48.2 ホストホスト名から送信されたすべてのデータを傍受する
tcpdump -i eth0 src ホスト ホスト名
ホストホスト名に送信されたすべてのパケットを監視する
tcpdump -i eth0 dst ホスト ホスト名
指定されたホストとポートからのパケットを監視する ホスト210.27.48.1が受信または送信したtelnetパケットを取得するには、次のコマンドを使用します。
tcpdump tcp ポート 23 およびホスト 210.27.48.1
ローカルudpポート123を監視します。123はntpのサービスポートです。 指定されたネットワーク上のパケットを監視する ローカル ホストと Berkeley ネットワーク上のホスト間のすべての通信パケットを印刷します (nt: ucb-ether、ここでは「Berkeley ネットワーク」のネットワーク アドレスとして理解できます。この表現の最も本来の意味は、次のように表現できます。ネットワーク アドレス ucb-ether を持つすべてのパケットを印刷します) ゲートウェイ snup を通過するすべての ftp パケットを印刷します (シェルが括弧を誤って解釈するのを防ぐために、式は一重引用符で囲まれていることに注意してください)
tcpdump 'ゲートウェイ snup および (ポート ftp または ftp-data)'
送信元または宛先アドレスがローカルホストであるすべてのIPパケットを印刷します。 (ローカルネットワークがゲートウェイを介して別のネットワークに接続されている場合、他のネットワークはローカルネットワークとしてカウントされません。(nt: この文は不正確であり、補足する必要があります。実際に localnet を使用する場合は、ローカルネットワークの名前に置き換える必要があります。)
tcpdump ip と not net localnet
指定されたプロトコルのパケットを監視する 送信元または送信先がローカル ネットワーク上のホストではない TCP セッションの開始パケットと終了パケットを印刷します。
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 かつ src および dst net localnet ではない'
送信元または宛先ポートが 80 で、ネットワーク層プロトコルが IPv4 で、SYN、FIN、ACK のみなどではなくデータを含むすべてのパケットを出力します (式の IPv6 バージョンは演習として使用できます)。
tcpdump 'tcp ポート 80 および (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: ip[2:2]はipデータパケット全体の長さを表し、(ip[0]&0xf)<<2)はipデータパケットヘッダーの長さを表し、(ip[0]&0xfはパケット内のIHLフィールドを表し、このフィールドの単位は32ビットであることがわかります。 バイト数を求めるには4倍、つまり2左シフトする。(tcp[12]&0xf0)>>4はTCPヘッダーの長さを示す。このフィールドの単位も32ビットである。変換されるビット数は((tcp[12]&0xf0)>>4) << ２、
つまり、((tcp[12]&0xf0)>>2)。((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0は、IPパケット全体の長さからIPヘッダーの長さを引いたもの、
TCP ヘッダーの長さが 0 ではないため、IP パケットには確かにデータが含まれています。IPv6 バージョンでは、IPv6 ヘッダーの「ペイロード長」と「TCP ヘッダーの長さ」の差のみを考慮する必要があり、式「ip[]」を「ip6[]」に置き換える必要があります。) 長さが576バイト以上でゲートウェイアドレスがsnupのIPパケットを印刷する
tcpdump 'ゲートウェイ snup および ip[2:2] > 576'
すべての IP 層のブロードキャストまたはマルチキャスト パケットを印刷しますが、物理イーサネット層のブロードキャストまたはマルチキャスト データグラムは印刷しません。
tcpdump 'ether[0] & 1 = 0 かつ ip[16] >= 224'
「エコー要求」または「エコー応答」パケット以外の ICMP パケットを印刷します (たとえば、この式を使用して、ping プログラムによって生成されていないすべてのパケットを印刷できます)。
(nt: 「エコー要求」と「エコー応答」は、通常 ping プログラムによって生成される 2 種類の ICMP パケットです)
tcpdump 'icmp[icmptype] != icmp-echo かつ icmp[icmptype] != icmp-echoreply'
tcpdump と wireshark Wireshark (旧称 ethereal) は、Windows で使用できる非常にシンプルで使いやすいパケット キャプチャ ツールです。しかし、Linux で優れたグラフィカル パケット キャプチャ ツールを見つけるのは困難です。
幸いなことに、Tcpdump があります。これを実現するには、Tcpdump + Wireshark の完璧な組み合わせを使用します。つまり、Linux でパケットをキャプチャし、Windows でパケットを分析します。
tcpdump tcp -i eth1 -t -s 0 -c 100 および dst ポート ! 22 および src ネット 192.168.1.0/24 -w ./target.cap
（１）tcp: ip icmp arp rarpおよびtcp、udp、icmpなどのオプションは、データグラムの種類をフィルタリングするために最初のパラメータ位置に配置する。
(2)-i eth1: インターフェースeth1を通過するパケットのみをキャプチャする
(3)-t: タイムスタンプを表示しない
（4）-s 0：データパケットをキャプチャするときのデフォルトのキャプチャ長は68バイトです。完全なデータパケットをキャプチャするには -S 0 を追加します
(5) -c 100 : 100パケットのみキャプチャする
(6)dst port ! 22: 宛先ポート22のパケットをキャプチャしない
(7)src net 192.168.1.0/24: パケットの送信元ネットワークアドレスは192.168.1.0/24です。
(8)-w ./target.cap: capファイルとして保存します。ethereal (wireshark)での解析に便利です。 tcpdump を使用して HTTP パケットをキャプチャする
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 または tcp[20:2]=0x4854
0x4745 は「GET」の最初の 2 文字「GE」、0x4854 は「HTTP」の最初の 2 文字「HT」です。 tcpdump は傍受したデータを完全にデコードせず、データ パケットの内容のほとんどが 16 進形式で直接出力されます。明らかに、これはネットワーク障害の分析には役立ちません。通常の解決策は、まず tcpdump を -w パラメータ付きで使用してデータを傍受し、ファイルに保存してから、他のプログラム (Wireshark など) を使用してデータをデコードして分析することです。もちろん、キャプチャされたデータ パケットがハード ディスク全体を占有しないように、フィルタリング ルールも定義する必要があります。 出力情報の意味 まず、tcpdumpの一般的な出力形式は次の通りです: システム時間 ソースホスト.ポート > ターゲットホスト.ポート データパケットパラメータ tcpdump の出力形式はプロトコルに依存します。以下は、最も一般的に使用される形式と関連する例の簡単な説明です。 リンク層ヘッダー FDDI ネットワークの場合、'-e' を指定すると、tcpdump は 'フレーム制御' フィールド、送信元と宛先のアドレス、および指定されたパケットの長さを出力します。(フレーム制御フィールドは、パケット内の他のフィールドの解釈を制御します。) 通常のパケット (IP データグラムのパケットなど) は 'async' フラグが設定されたパケットであり、優先度の値は 0 から 7 です。
たとえば、「async4」は、このパケットが優先度 4 の非同期データ パケットであることを意味します。これらのパケットには LLC パケット (論理リンク制御パケット) が含まれていると一般に考えられています。このとき、このパケットが ISO データグラムまたはいわゆる SNAP パケットでない場合は、LLC ヘッダーが印刷されます (nt: このパケットに含まれる LLC パケット ヘッダーを参照する必要があります)。 トークン リング ネットワークの場合、'-e' を指定すると、tcpdump は指定されたパケットの 'フレーム制御' フィールドと 'アクセス制御' フィールド、および送信元アドレスと宛先アドレスを出力します。
パケットの長さを足した値です。FDDI ネットワークと同様に、このパケットには通常 LLC パケットが含まれます。'-e' オプションが使用されているかどうかに関係なく。このネットワーク上の 'source-routed' タイプのパケットの場合 (nt:
データ パケットの送信元アドレスが追跡され、具体的な意味は不明で補足する必要がある)、パケットの送信元ルーティング情報が常に印刷されます。 802.11 ネットワーク (WLAN、ワイヤレス ローカル エリア ネットワーク) の場合、'-e' を指定すると、tcpdump は指定されたパケットのフレーム制御フィールドを出力します。
パケット ヘッダーには、すべてのアドレスとパケットの長さが含まれます。FDDI ネットワークと同様に、このパケットには通常 LLC パケットが含まれます。 （注：以下の説明は、SLIP圧縮アルゴリズム（nt：SLIPはSerial Line Internet Protocolの略）に精通していることを前提としています。このアルゴリズムは、
関連する手がかりは RFC-1144 にあります。 SLIPネットワーク（nt:SLIPリンク、つまりシリアル回線を介して確立された接続をネットワークと見なすことができ、単純な接続もネットワークと見なすことができます）の場合、
パケットの「方向インジケータ」（入力の場合は「I」、出力の場合は「O」）、タイプ、および圧縮情報が印刷されます。パケット タイプが最初に印刷されます。 タイプは ip、utcp、ctcp です (nt: 不明、追加予定)。ip パケットの場合、接続情報は印刷されません (nt: SLIP 接続では、ip パケットの接続情報は役に立たないか、未定義である可能性があります。
（再確認）。TCP パケットの場合、接続識別子の後にタイプが出力されます。パケットが圧縮されている場合は、エンコードされたヘッダーが出力されます。
このとき、特殊な圧縮パッケージの場合は以下のように表示されます。
*S+n または *SA+n。ここで、n は増加または減少するパケット数 (シーケンス番号または (シーケンス番号と確認応答番号)) を表します (nt | rt: S、SA は発音が難しいため、翻訳する必要があります)。
特殊でないアーカイブの場合、0 個以上の「変更」が印刷されます。「変更」は次の形式で印刷されます。
「フラグ」+/-/=n パケットデータ長 圧縮されたヘッダーの長さ。
ここで、「flag」は次の値を取ることができます。
U (緊急ポインタ)、W (バッファウィンドウ)、A (確認応答)、S (シーケンス番号)、I (パケット ID)、増分式 '=n' は新しい値が割り当てられることを示し、+/- は増加または減少を示します。 たとえば、次の図は、暗黙の接続識別子を含む送信圧縮TCPパケットの印刷を示しています。確認応答番号は6ずつ増加します。
シーケンス番号は 49 増加し、パケット ID は 6 増加し、パケット データ長は 3 バイト (オクテット)、圧縮ヘッダーは 6 バイトです。(nt: したがって、これは特別な圧縮データ パケットではないようです)。 ARP/RARP パケット Arp/rarpパケットのtcpdumpの出力情報には、リクエストの種類とリクエストに対応するパラメータが含まれます。表示形式は簡潔で明確です。以下は、ホストrtsgからホストcsamへの「rlogin」です。
(リモート ログイン) プロセスの開始時のサンプル パケット:
arp 誰が持っている csam tell rtsg
arp 応答 csam is-at CSAM
最初の行は、rtsgがcsamのイーサネットアドレスを問い合わせるためにarpパケット（nt：ネットワークセグメント全体に送信、arpパケット）を送信したことを示しています。
Csamは自分のイーサネットアドレスで応答しました（この場合、イーサネットアドレスは大文字の名前で識別されますが、インターネット
アドレス (IP アドレスなど) はすべて小文字の名前で識別されます。 tcpdump -n を使用すると、名前識別子の代わりにイーサネットと IP アドレスを明確に確認できます。
arp who-has 128.3.254.6 tell 128.3.254.68
arp 応答 128.3.254.6 は 02:07:01:00:01:c4 にあります tcpdump -e を使用すると、最初のパケットがネットワーク全体にブロードキャストされ、2 番目のパケットがポイントツーポイントであることが明確にわかります。
RTSG ブロードキャスト 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp 応答 csam is-at CSAM
最初のデータ パケットは、ARP パケットの送信元イーサネット アドレスが RTSG、宛先アドレスがイーサネット セグメント全体、タイプ フィールドの値が 16 進数の 0806 (ETHER_ARP (nt: arp パケット タイプ識別子) を示す) であることを示します。
パケットの合計長さは 64 バイトです。 TCPパケット (注: 以下は、RFC-793 で説明されている TCP に精通していることを前提としています。そうでない場合は、以下の説明と tcpdump プログラムはあまり役に立たないかもしれません。(nt: 警告は無視できます。
そのまま視聴を続け、よくわからない部分があれば戻って見てください。 通常、tcpdump は TCP パケットを次の形式で表示します。
src > dst: フラグ データ シーケンス番号 ack ウィンドウ 緊急オプション srcとdstは送信元と宛先のIPアドレスとそれに対応するポートです。フラグはS(SYN)、F(FIN)、P(PUSH、R(RST)、
W(ECN CWT(nt | rep: 不明、補足予定)) または E(ECN-Echo(nt | rep: 不明、補足予定))、
1つの「.」はフラグ識別子がないことを示します。データセグメントシーケンス番号（Data-seqno）は、このパケット内のデータに対応するシーケンス番号空間内の位置を示します（nt：データ全体がセグメント化され、
各セグメントにはシーケンス番号があり、すべてのシーケンス番号はシーケンス番号スペースを形成します (次の例を参照)。Ack は、ローカル エンドが同じ接続と方向で受信する必要がある次のセグメントを記述します。
データ フラグメントのシーケンス番号 (相手側が送信するデータ)。ウィンドウは、この側で使用可能なデータ受信バッファのサイズです (相手側がデータを送信するときに、データはこのサイズに従って整理される必要があります)。
Urg (urgent) は、データ パケットに緊急データがあることを示します。options は、山括弧で表現されるいくつかの TCP オプション (<mss 1024> など) を表します。 src、dst、flags フィールドは常に表示されます。その他のフィールドは、TCP プロトコル ヘッダーの情報に応じて、表示または表示されない場合があります。 これは、trsg から csam への rlogin アプリケーション ログインの開始です。
rtsg.1023 > csam.ログイン: S 768512:768512(0) 勝利 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 勝利 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 勝利 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023>csam.login: P 2:21(19) ack 1 勝利 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 ホストの TCP ポート login に送信されたことを示しています (nt: udp プロトコル ポートと tcp プロトコル ポートは 2 つの別々のスペースですが、値の範囲は同じです)。S は、SYN フラグが設定されていることを示します。パケットのシーケンス番号は 768512 で、データは含まれていません。(形式は「first:last(nbytes)」で、これは「このパケットのデータのシーケンス番号は first から始まり last で終わりますが、last は含まれません。また、合計 nbytes のユーザー データが含まれています」という意味です)。ピギーバック応答はありません (nt: 次のテキストから、2 行目はピギーバック応答のあるデータ パケットです)、使用可能な受信ウィンドウ サイズは 4096 バイト、要求側 (rtsg)
許容される最大データ セグメント サイズは 1024 バイトです (nt: この情報は、両者間のさらなるネゴシエーションの要求として、応答側の csam に送信されます)。 Csam は、ピギーバックされた ack を除いて、同様の SYN パケットで rtsg に応答します。 rtsg は、csam の SYN パケットに対しても ACK パケットで応答しました。 '.' は、このパケットにフラグが設定されていないことを意味します。この応答パケットにはデータが含まれていないため、パケットにはデータ セグメント シーケンス番号はありません。注意! この ACK パケットのシーケンス番号は、小さな整数 1 です。次の説明があります。tcp 接続のセッションの場合、tcpdump はセッションの両端で最初のデータ パケットのシーケンス番号のみを出力し、後続の対応するデータ パケットは最初のパケット シーケンス番号との差のみを出力します。つまり、最初のシーケンス番号の後のシーケンス番号は、送信されるデータ全体におけるこのセッションで現在送信されているデータ セグメントの「相対バイト」位置と見なすことができます (nt: 両側の最初の位置は 1、つまり「相対バイト」の開始番号です)。 '-S' はこの機能をオーバーライドします。
パケットの元のシーケンス番号が印刷されます。 6行目の意味は、rtsgが19バイトのデータをcsamに送信した（バイト番号は2から20で、送信方向はrtsgからcsam）。パケットにPUSHフラグが設定されている。7行目では、
csamはrtsgからバイト番号21までのバイトを受信したことを叫びます。これらのバイトはcsamのソケットの受信バッファに格納されます。したがって、
csam の受信バッファ ウィンドウ サイズは 19 バイト減少します (nt: は 5 行目と 7 行目の win 属性値の変更から確認できます)。csam は 7 行目のこのパケットで 1 バイトを rtsg に送信します。8 行目と 9 行目では、csam は 1 バイトのみを含む 2 つのデータ パケットを rtsg に送信し続け、このデータ パケットには PUSH フラグがあります。 キャプチャされた TCP パケット (nt: ここではスナップショット) が小さすぎて、tcpdump がそのヘッダー データを完全に取得できない場合、tcpdump は不完全なヘッダーを解析しようとします。
残りの解析されていない部分は '[|tcp]' として表示されます。ヘッダーに誤った属性情報が含まれている場合 (たとえば、長さ属性がヘッダーの実際の長さよりも長いか短い場合)、tcpdump はヘッダーに対して '[bad opt]' を表示します。ヘッダーの長さから、このパケットにいくつかのオプション (nt | rt: 次のテキストでは、IP パケットの TCP パケットのヘッダーにあるいくつかのオプションを指し、後で翻訳されます) が含まれていることがわかる場合、
実際の IP パケットの長さはこれらのオプションに対応するのに十分ではないため、tcpdump は '[bad hdr length]' を表示します。 特殊なフラグ (SYN-ACK フラグ、URG-ACK フラグなど) を持つ TCP パケットをキャプチャします。 TCP ヘッダーには制御ビット領域として使用される 8 ビットがあり、その値は次のとおりです。
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt: 式から、これらの 8 ビットは OR 方式で結合されていることがわかります。これは後で元に戻すことができます) ここで、TCP 接続を確立するプロセス全体で生成されるデータ パケットを監視するとします。TCP は 3 ウェイ ハンドシェイク プロトコルを使用して新しい接続を確立することを思い出してください。この 3 ウェイ ハンドシェイク接続シーケンスに対応するデータ パケットと、対応する TCP 制御フラグは次のとおりです。
1) 接続イニシエーター（nt:Caller）はSYNフラグ付きのパケットを送信します。
2) 受信者（nt: Recipient）はSYNフラグとACKフラグ付きのパケットで応答する。
3) 受信側からの応答を受信した後、イニシエーターは応答としてACKフラグ付きのデータパケットを送信する。
0 15 31
-----------------------------------------------------------------
| 送信元ポート | 宛先ポート |
-----------------------------------------------------------------
|シーケンス番号|
-----------------------------------------------------------------
| 確認番号 |
-----------------------------------------------------------------
| HL | rsvd |C|E|U|A|P|R|S|F| ウィンドウ サイズ |
-----------------------------------------------------------------
| TCP チェックサム | 緊急ポインタ |
-----------------------------------------------------------------
オプションデータなしのTCPヘッダーは通常20バイトを占めます（nt | rt:optionsはオプションデータとして解釈され、逆変換する必要があります）。最初の行には0から3までのバイトが含まれます。
2 行目には 4 ～ 7 の番号が付けられたバイトが含まれます。 番号が 0 から始まる場合、TCP 制御フラグはバイト 13 (nt: 4 行目の左半分) にあります。 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|
ここで、注目する制御フラグを示します。ビットは右から左に 0 から 7 まで番号が付けられており、PSH は 3 番、URG は 5 番です。
SYN フラグが設定されているパケットのみが必要であることを思い出してください。SYN ビットが設定されている場合、パケット ヘッダーのバイト 13 で何が起こるかを見てみましょう。 |C|E|U|A|P|R|S|F|
|--------------|
|0 0 0 0 0 0 1 0|
|--------------|
|7 6 5 4 3 2 1 0|
制御セグメントのデータでは、ビット 1 (ビット番号 1) のみが設定されます。 バイト番号 13 が 8 ビットの unsigned char 型であり、ネットワーク バイト番号 (nt: バイトの場合、ネットワーク バイト順序はホスト バイト順序と同等) でソートされていると仮定すると、そのバイナリ値は次のようになります。
00000010 その 10 進数値は次のとおりです。 0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2 (注: 1 * 2^6 は 1 の 2 の 6 乗を意味します。元の式の指数 7 6 ... 0 を下に移動して表現するとわかりやすいかもしれません) パケット ヘッダーの SYN ビットが設定されている場合、ヘッダーの 13 番目のバイトの値は 2 (nt: ネットワーク順序、つまりビッグ エンディアン モードでは、最も重要なバイトが先頭にあります (先頭、つまりバイトの実際のメモリ アドレスは比較的小さく、最も重要なバイトは数学的表現の数値の上位ビットを参照します (356 の 3 など)) であることがすでにわかっているため、目標に近づいています。 tcpdump が理解できる式として表現される関係は次のようになります。
tcp[13] 2 したがって、この関係を tcpdump のフィルター条件として使用し、SYN フラグを含むパケットのみを監視することが目標となります。
tcpdump -i xl0 tcp[13] 2 (nt: xl0はeth0などのネットワークインターフェースを指します) この式は、「TCP パケットのバイト 13 の値を 2 にする」という意味で、これが必要なことです。
さて、他のフラグが含まれているかどうかに関係なく、SYNフラグ付きのパケットをキャプチャする必要があるとします。（nt：SYNが含まれている限り、それが必要です）。パケットに次のフラグが含まれている場合、何が起こるかを見てみましょう。
SYN-ACK パケット (nt: SYN フラグと ACK フラグの両方) が到着すると何が起きますか。
|C|E|U|A|P|R|S|F|
|--------------|
|0 0 0 1 0 0 1 0|
|--------------|
|7 6 5 4 3 2 1 0|
バイト 13 のビット 1 と 4 が設定されており、そのバイナリ値は次のとおりです。
00010010 10進数に変換: 0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18 (nt: 1 * 2^6 は 1 の 2 の 6 乗を意味します。元の式の指数 7 6 ... 0 を下に移動して表現するとわかりやすいかもしれません) ここで、tcpdump のフィルター式として 'tcp[13] 18' のみを使用することはできません。これは、SYN-ACK フラグを持つパケットのみが選択され、他のパケットはすべて破棄されるためです。
私たちの目標は、パケットに SYN フラグのみを設定し、他のフラグを無視することであることを思い出してください。 目標を達成するには、バイト 13 のバイナリ値と別の数値の AND 演算を行って、SYN ビットの値を取得する必要があります。目標は、SYN が設定されている場合は、バイト 13 の SYN 値 (nt: 00000010) と AND 演算を行うことです。 00010010 SYN-ACK 00000010 SYN
AND 00000010 (SYN が必要です) AND 00000010 (SYN が必要です)
-------- --------
= 00000010 = 00000010
パケットの ACK または他のフラグが設定されているかどうかに関係なく、上記の AND 演算によって同じ値、つまり 10 進数で 2 (2 進数で 00000010) が返されることがわかります。
したがって、SYN フラグを持つパケットの場合、次の式は常に true と評価されることがわかります。 ( ( オクテット13の値 ) AND ( 2 ) ) ( 2 ) (nt: オクテット13の値、つまりバイト13の値) インスピレーションが続き、次のtcpdumpフィルタ式が得られました。
tcpdump -i xl0 'tcp[13] & 2 2' 一重引用符またはバックスラッシュ (nt: ここでは一重引用符が使用されています) は省略できないことに注意してください。省略すると、シェルが & を解釈または置換できなくなります。 UDPパケット UDP データ パケットの表示形式は、特定のアプリケーション rwho によって生成されたデータ パケットによって説明できます。
actinide.who > ブロードキャスト.who:udp 84 これは、actinide ホストのポート who が、ブロードキャスト ホストのポート who に UDP パケットを送信したことを意味します (nt: actinide と broadway はどちらもインターネット アドレスを指します)。
このパケットは 84 バイトのユーザー データを伝送します。 一部のUDPサービスは、パケットの送信元ポートまたは宛先ポート、または表示される上位レベルのプロトコル情報から識別できます。たとえば、ドメイン名サービス要求（DNS要求、
RFC-1034/1035 に記載されている)、および NFS への Sun RPC 呼び出し (RFC-1050 に記載されている NFS サーバーによって開始されるリモート呼び出し (nt: Sun RPC))。 UDP 名前サービス要求 (注: 以下の説明は、RFC-103 で説明されているドメイン サービス プロトコルに精通していることを前提としています。そうでない場合、以下の説明が理解できない可能性があります。
気にしないでください、それはあなたを怖がらせるためだけのものなので、ただ見続けてください）） 名前サービス要求の形式は次のとおりです。
src > dst: id op? flags qtype qclass name (len)
(nt: 次のテキストの形式は src > dst: id op flags qtype qclass? name (len) である必要があります)
たとえば、実際の表示は次のようになります。
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) ホスト h2opolo は、helios 上で実行されているネーム サーバーに、ucbvax.berkeley.edu (nt: qtype は A) のアドレス レコードを照会します。クエリ自体の ID は '3' です。シンボル
'+' は再帰クエリ フラグが設定されていることを意味します (nt: DNS サーバーは、サーバーに含まれていないアドレス レコードを上位レベルの DNS サーバーにクエリできます)。IP パケットを介して送信されるクエリ要求データは、UDP および IP プロトコルのヘッダー データを除いて 37 バイト長です。このクエリ操作は既定値 (nt | rt: 通常の操作) であるため、op フィールドは省略されます。
op フィールドは省略しない場合は '3' と '+' の間に表示されます。同様に qclass はデフォルト値の C_IN であり、これも表示されません。省略しない場合は 'A' の後に表示されます。 例外チェックでは、角括弧で囲まれた追加フィールドが表示されます。クエリに応答（nt:は以前のリクエストへの応答として理解できます）も含まれており、この応答に権限のあるレコードセグメントまたは追加のレコードセグメントが含まれている場合、
ancount、nscout、arcount（nt：補足される特定のフィールドの意味）は、「[na]」、「[nn]」、「[nau]」と表示されます。ここで、nは適切なカウントを表します。パケット内の次の応答ビット（AAビット、RAビット、rcodeビットなど）またはバイト2または3の「0でなければならない」ビットが設定されている場合（nt：1に設定）、 「[b2&3]=x」が表示されます。ここで、xはヘッダーバイト2とバイト3のAND演算後の値を表します。 UDP 名前サービス応答 ネームサービス応答パケットの場合、tcpdumpは次の表示形式になります。
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から送信されたクエリ要求3番に3つの回答レコード（nt | rt:回答レコード）、3つのネームサーバーレコードで応答したことを示しています。
および 7 つの追加レコード。最初の回答レコード (nt: 3 つの回答レコードの最初のもの) はタイプ A (nt: アドレスの略) であり、そのデータはインターネット アドレス 128.32.137.3 です。
この応答 UDP パケットには、273 バイトのデータ (UDP および IP ヘッダー データを除く) が含まれます。op フィールドと rcode フィールドは無視されます (nt: op の実際の値は Query、rcode です。つまり、
応答コードの実際の値はNoErrorです。クラスフィールドも無視されます（nt | rt：その値はC_INで、Aタイプレコードのデフォルト値でもあります） 2行目は、h2opoloから送信されたクエリ要求2に対してheliosが応答したことを示しています。応答では、rcodeはNXDomain（nt:は存在しないドメインを示します）であり、回答レコードはありません。
しかし、ネームサーバレコードは含まれているが、権限サーバレコードは含まれていない（nt | ck：上記から、ここでの権限レコードは対応する追加の
レコード）。「*」は、権威サーバー応答フラグが設定されていることを示します（nt: 追加のレコードが権限レコードを示すようにします）。
回答レコードがないため、タイプ、クラス、およびデータ フィールドは無視されます。 フラグ フィールドには、'-' (nt: 再帰クエリを示します。つまり、RA フラグが設定されていません)、'|' (nt: 切り捨てられたメッセージを示します。つまり、TC フラグが設定されています) などの他の文字が含まれる場合があります。応答の 'question' セグメントにエントリが含まれていない場合 (nt: 各エントリの意味、補足が必要)、'[nq]' が印刷されます。 ネーム サーバーの要求と応答は大きいため、デフォルトの snaplen の 68 バイトではパケット全体をキャプチャするのに十分でない可能性があることに注意してください。ネーム サーバーの負荷を実際に確認する必要がある場合は、tcpdump の -s オプションを使用して snaplen 値を増やします。 SMB/CIFS デコード tcpdump は、SMB/CIFS/NBT 関連アプリケーションのパケットの内容をデコードできるようになりました (nt: 'Server Message Block Common'、'Internet File System'
「TCP/IP 上に実装されたネットワーク プロトコルである NETBIOS の略」。これらのサービスは通常、UDP ポート 137/138 と TCP ポート 139 を使用します。IPX および NetBEUI SMB パケットの元のデコード機能は引き続き使用できます (nt: NetBEUI は NETBIOS の拡張バージョンです)。 デフォルトでは、tcpdump は対応するデータ パケットを最も簡潔なモードでのみデコードします。詳細なデコード情報が必要な場合は、-v 起動オプションを使用できます。-v は非常に詳細な情報を生成することに注意してください。
たとえば、1 つの SMB パケットで 1 画面分以上の情報が生成されるため、このオプションは必要な場合にのみ使用してください。 SMB パケット形式と各フィールドの意味に関する情報は、www.cifs.org または samba.org ミラー サイトの pub/samba/specs/ ディレクトリで参照できます。Linux 用の SMB パッチ
(nt | rt: patch) Andrew Tridgell ([email protected]) による寄稿。 NFS 要求と応答 tcpdump は、Sun NFS (ネットワーク ファイル システム) の要求および応答 UDP パケットを次の形式で出力します。
src.xid > dst.nfs:len op args
src.nfs > dst.xid: 応答 stat len op 結果 以下は具体的な出力データのセットです
sushi.6709 > wrl.nfs: 112 読み取りリンク fh 21,24/10.73165
wrl.nfs > sushi.6709: 応答 ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 検索 fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
返信OK 128 検索 fh 9,74/4134.3150 出力の最初の行は、ホスト sushi がホスト wrl に「トランザクション要求」(nt: トランザクション) を送信したことを示しています。この要求の ID は 6709 です (ホスト名の後に、送信元ポート番号ではなく、トランザクション ID 番号が続くことに注意してください)。要求データは 112 バイトで、UDP ヘッダーと IP ヘッダーの長さは含まれていません。操作タイプは readlink (nt: この操作はシンボリック リンクの読み取り操作です) です。
操作パラメータは fh 21,24/10.73165 (nt: 実際の動作環境に応じて次のように解釈できます。fd はファイル ハンドルが記述されていることを意味し、21,24 はこのハンドルに対応するデバイスのマスター/スレーブ デバイス番号ペアを意味し、10 はこのハンドルに対応する i-node 番号を意味します (nt: 各ファイルはオペレーティング システム内の i-node に対応します。Unix 系システムに限定されます)。
73165 は数字です (nt: このリクエストを識別するためのランダムな数字として理解できますが、具体的な意味を補足する必要があります)。 2行目では、WRLは「OK」で応答し、寿司が結果フィールドで読みたいシンボリックリンクの実際のディレクトリを返します。 3行目は、寿司が再び「FH 9,74/4096.6878」で記述されたディレクトリの「Xcolors」ファイルを検索することを示しています。 TCPDUMPの-Vオプション（冗長印刷オプション）が設定されている場合、追加情報が表示されます。
sushi.1372a> wrl.nfs：
148 FH 21,11/12.195 8192バイト @ 24576を読む
wrl.nfs> sushi.1372a：
返信OK 1472 REG 100664 IDS 417/0 SZ 29388を読む （-Vオプションは通常、IPヘッダーのTTL、ID、長さ、および断片化フィールドも印刷しますが、この例では省略されています。）
最初の行では、寿司はWRLに、オフセット24576バイトから始まるファイル21,11/12.195（上記のNT：形式）から8192バイトのデータを読むように依頼します。
WRLは、2行目が応答要求の始まりに過ぎないため、1472バイトのみが含まれています（残りのデータは次の返信セグメントになりますが、これらのパケットはNFSを持つことはありません。
ヘッダー、UDPヘッダー情報でさえ空（NT：ソースと宛先が存在する必要があります）。これにより、これらのフラグメントがフィルタリング条件を満たすことができないため、ファイルデータ情報を表示することに加えて、File Type（ファイルタイプ、「REG」は通常のファイル）、ファイルモード（nt）、uid（uid）、uid（uid）、uid、uid（ -vフラグが複数回（-VVなど）与えられた場合、TCPDUMPはより詳細な情報を表示します。 NFSリクエストパケットには多くのデータが含まれていることに注意してください
'-S 192' NFSアプリケーションのネットワーク負荷（NT：トラフィック）を監視するために使用できます。 NFS応答パケットは、以前の対応するリクエストパケット（NT：RPC操作）に従いません。
応答パケットを解析することはできません。 AFSリクエストと応答 AFS（NT：Andrew File System、TransArc、不明、補足される）リクエストと回答には次の約束があります 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データfsコール名前の名前の古いfid 536876964/1/1 ".newsrc.new"
新しいFID 536876964/1/1 ".newsrc"
pike.afsfs> elvis.7001：rx data fs返信の名前 最初の行では、ホストのエルビスがRXパケットをパイクに送信します。
これは、ファイルサービスのリクエストパケットです（NT：RXデータパケット、データパケットの送信、相手のサービスをリクエストするためにパケットを送信すると理解できます）。これもRPCです。
呼び出しの開始（NT：RPC、リモートプロシージャコール）は、パイクに名前が実行され、操作を実行し、関連するパラメーターを指定します。
元のディレクトリ記述子は536876964/1/1、元のファイル名は「.newsrc.new」、新しいディレクトリ記述子は536876964/1/1、新しいファイル名は「.newsrc」です。
ホストパイクは、名前変更操作のRPC要求に応答します（応答は、応答が異常なパケットではなくデータコンテンツを含むパケットであるため、名前変更操作が成功したことを示します）。 一般的に、すべての「AFS RPC」リクエストには、この名前が表示されると、名前（nt：decode）が与えられます。
さらに、これらのRPCリクエストのいくつかのパラメーターには、表示されると名前が付けられます（nt | rt：デコード、デコード、一般的に言えば、命名も非常に直接的です。
興味深いパラメーターが「興味深い」と表示されます。これは、発音が難しく、翻訳する必要があります）。 このディスプレイ形式は「一目で理解しやすい」ように設計されていますが、AFSとRXの動作に慣れていない人にとってはあまり役に立たないかもしれません（NT：それを無視するだけで、ただあなたを怖がらせることです、ただ読んでください）。 -v（verbose）フラグが繰り返し（nt：wike -vv）が与えられた場合、tcpdumpは確認パケット（nt：返信パケットとは異なるパケットとして理解できます）と追加のヘッダー情報を印刷します。
（NT：確認パケットの追加のヘッダー情報だけでなく、すべてのパケットとして理解できます）。たとえば、RXコールID（リクエストパケットの「リクエストコール」のID）、
呼び出し番号（ 'コールリクエスト'番号）、シーケンス番号（NT：パケットシーケンス番号）、
シリアル番号（NT | RT：パケット内のデータに関連する別のシリアル信号として理解できます。特定の意味を補完する必要があります）、次の段落は繰り返し説明です。
したがって、省略されています）、および確認パケットのMTUネゴシエーション情報も印刷されます（NT：確認パケットは、リクエストパケット、最大送信ユニット、最大送信ユニットに関連する確認パケットです）。 -vオプションが3回（-vvvなどのNT：セキュリティインデックス」（「セキュリティインデックス」）および「サービスインデックス」（「サービスID」）がAFSアプリケーション型パケットの「サービスインデックス」（「サービスID」）が印刷されます。 例外（NT：Abortパケットを表すデータパケットの場合、このパケットがいくつかの例外が発生したことを受信者に通知するために使用されるため、TCPDUMPにエラー番号（エラーコード）を印刷するため、理解できます。
ただし、Ubikビーコンパケット（NT：Ubik灯台表示パケットの場合、Ubikは特別な通信プロトコル、ビーコンパケット、灯台パケット、および通信の重要な情報を示すいくつかのデータパケットとして理解することができます）、Ubikプロトコルの場合、aftimationはaftimativeを意味するため、エラー番号は印刷されません。 AFSは大量のデータと多くのパラメーターを要求しているため、TCPDumpのSnaplenは比較的大きくなる必要があります。 AFS応答パッケージは、RPCを識別するリモートコールを表示しません。
（サービスインデックス）受信した応答パッケージと一致する場合。 KIP AppleTalkプロトコル （UDPのNT | RT：DDPは、DDP、AppleTalkデータ配信プロトコルとして理解できます。
KIP Appletalkプロトコルスタックをサポートするのは、ネットワークレイヤープロトコルと同等であり、DDP自体がUDPを介して送信されます。
つまり、UDPに実装された他のネットワークに使用されるネットワークレイヤーは、Appleによって開発された完全なネットワークプロトコルスタックです。 AppleTalk DDPパケットはUDPパケットにカプセル化されており、それらの脱カプセル化（NT：デコードに相当）と対応する情報ダンプもDDPパケットルールに従います。
（NT：カプセル化、カプセル化、エンコードに相当、脱カプセル化、デコード、ダンプ、ダンプ、通常は情報の印刷を指します）。 /etc/atalk.namesファイルには、AppleTalkネットワークとNode数値識別子の間の対応が通常次のとおりです。
番号名 1.254エーテル
16.1 ICSD-NET
1.254.110エース 最初の2行は、2つのAppleTalkネットワークがあることを示しています。
ネットワークのIDには通常、2つのバイトしかありません。これは2つの識別の主な違いでもあります）（NT：1.254.110は、エーテルネットワーク上のACEホストとして理解できます）。
識別子とその対応する名前は、上記のコンテンツに加えて、空白の行とコメント行（「＃」から始まる行も含まれています。 AppleTalkの完全なネットワークアドレスは、次の形式で表示されます。
net.host.port 以下は特定のディスプレイです。
144.1.209.2> ICSD-NET.112.220
Office.2> ICSD-NET.112.220
JSSMAG.149.235> ICSD-NET.2
（/etc/atalk.namesファイルが存在しない場合、または対応するAppleTalkホスト/ネットワークのエントリがない場合、パケットのネットワークアドレスが数値形式で表示されます）。 最初の行では、ネットワーク144.1のノード209がNBPアプリケーションデータパケットをノード112に送信します。
（NT | RT：NBP、名前バインディングプロトコル、名前バインディングプロトコル、データからのNBPサーバーは、ポート2でこのサービスを提供します。
「DDPポート2」は、輸送層のポート2に対応する「DDP」と理解できます。この点は決定されておらず、追加する必要があります。 2番目の行は最初の行に似ていますが、ソースのすべてのアドレスが「オフィス」で識別できることを除きます。
3番目の行は、JSSMAGネットワーク上のノード149は、ICSD-NETネットワーク上のすべてのノードの235（NBPポート）にデータパケットを送信します。
AppleTalkネットワークにアドレスにノードがない場合、それはブロードキャストアドレスを意味するため、ノード識別とネットワーク識別は /etc/atalk.namesとは異なることが好ましいです。
NT：それ以外の場合、AはX.portを識別できません。Xが、指定されたホストxのネットワーク上のすべてのホストのポートポートを参照するかどうかを判断できません。 TCPDUMPは、NBP（名前のバインディングプロトコル）とATP（AppleTalk Transport Protocol）パケットを解決できます。
このプロトコルが共通名を登録しない場合、そのプロトコル番号のみが印刷されます）とパケットのサイズ。 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-NETのノード112は、ポート220（NT：
ここでの名前は、このクエリリクエストのシリアル番号が190です。 2番目の行は次のとおりです。ネットワークJSSMAGのノード209は、ポート2からICSD-NET.112ノードのポート220に応答します。リソース名「RM1140」を備えた「レーザーライター」リソースがあり、ポート250のリソースを変更するサービスを提供します。 3番目の行は、最初の行リクエストへの応答でもあります。ノードTechPitは、ポート2を介してICSD-NET.112ノードのポート220に応答します。リソース名「TechPit」を備えた「レーザーライター」リソースがあり、ポート186のリソースを変更するサービスを提供します。 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：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がセッション番号12266のリクエストパケットをノードヘリオスに送信し、ヘリオスにリクエストすることを示しています。
8つのパケットに応答します（これらの8つのパケットのシーケンス番号は0-7です（NT：シーケンス番号はセッション番号とは異なり、後者は完全な送信の数、
前者は、伝送の各パケットの数です。通常、送信と呼ばれます。 Heliosは、8 512バイトのパケットに応答します。
ブラケットの数字は、パケットのデータのサイズを示していますが、これにはATPのヘッダーが含まれていません。
データパケットが設定されていることを示すEOMフラグ。 次の行9は、JSSMAG.209がヘリオスに別のリクエストを行ったことを示しています。シーケンス番号3と5でパケットを再送信してください。ヘリオスはこれら2つのパケットを再び受信した後、セッションを積極的に（リリース）します。 最後の行では、JSSMAG.209はリクエストパケットをHeliosに送信して、リクエストパケットの「*」を開始します。
（NT：XOは、このセッションのように理解できますが、他のパーティがパケットを繰り返し送信した場合でも、パケットは受信者に1回だけ処理されます。
受信機はそれを1回だけ処理します。これには、特別に設計されたパケット受信と処理メカニズムが必要です）。 IPパケットが粉砕されました （NT：IPパケットを複数のIPパケットに分割することを指します） 次の2つのディスプレイ形式には、断片化されたIPパケット（NT：つまり、大きなIPパケットが壊れた後に生成された小さなIPパケット）には2つの表示形式があります。
（フラグID：size@offset+）
（frag id：size@offset）
（最初の形式は、このフラグメントの後に後続のフラグメントがあることを示します。2番目の形式は、このフラグメントが最後のフラグメントであることを示します。） IDは壊れた数値を表します（NT：以下から、各小さなフラグメントが同じデータパケットから壊れているかどうかを区別するために、壊れた数値が各大きなIPパケットに割り当てられて壊れます）。
サイズは、このフラグメントのサイズを示し、フラグメントヘッダーデータを含めていません。
データだけでなく、ヘッダーやデータを含むIPパケット全体が壊れています）。 各フラグメントにより、TCPDUMPは対応する出力印刷を生成します。
IPヘッダーは最初のフラグメントに配置されます。そのため、TCPDUMPは最初のフラグメントの情報を表示し、その後のフラグメントには高レベルのプロトコルヘッダー情報を表示します。
CSNETネットワークを通過するFTPアプリケーション通信フラグメント（NT：CSNET接続は、CSNETネットワークで確立された接続として理解できます）：
arizona.ftp-data> rtsg.1170：。
アリゾナ> rtsg ：（ frag 595a：204@328）
rtsg.1170> arizona.ftp-data： 注目すべき点がいくつかあります:
最初の行と2行目が印刷され、アドレスの後にポート番号はありません。
これは、TCPプロトコル情報が最初のフラグメントに配置されているため、このフラグメントに対応するTCPパケットのシーケンス番号がわかりません。 第二に、最初の行の情報から、アリゾナは308バイトのユーザーデータをRTSGに送信する必要があることがわかります。 ET（NT：HOLE、HOLE、データパケット間のシーケンス番号が上下に接続されていないことを意味します）、512データはしばらく混乱させるのに十分です（NT：実際、308に焦点を合わせてください。
壊れたデータの総量に注意しないでください）。 パケット（nt | rt：IPパケットを参照）が壊れていないフラグがある場合、 '（df）に表示されます。 タイムスタンプ TCPDUMPのすべての出力印刷ラインには、デフォルトでタイムスタンプ情報が含まれます。
タイムスタンプ情報の表示形式は次のとおりです
HH：MM：SS.FRAC（NT：時間：分：秒：（NT：FRACは不明、補足する必要があります））
このタイムスタンプの精度は、カーネルが最初に対応するパケット（NT：SAW、パケットで操作できる）を最初に確認する時間を反映して、カーネル時間の精度と一致しています。
データパケットが物理ラインからカーネルに渡される時間と、このパケットにカーネルが使用する割り込み処理時間は含まれていません。 コマンドの使用 TCPDUMPはコマンドラインメソッドを使用し、そのコマンド形式は次のとおりです。
tcpdump [-addefllnnopqrstuuvxx] [-c count] [-c file_size] [-f file] [-i interface] [-m module] [-m secret] [-r file] [-s snaplen] [-t type] [-w file] [-w filecount] [-e spi@ipad algo] tcpdumpの簡単なオプションの紹介
: : : : : : : : : : : : : : : tcpdump条件付き式 この式は、どのパケットが印刷されないかを決定するために、ネットワーク上のすべてのパケットが印刷されます。 式は、式を構成する基本的な要素として理解できる1つ以上の「式要素」で構成されています。
: : : : : : : : : : : : : : : 上記の「プリミティブ」に加えて、「プリミティブ」には他の形式があります。 式は、キーワードを介して接続することもできます。たとえば、比較的複雑な条件付き式を構成することができます。 Linuxシステム））。 表現の利便性のために、「TCP DSTポートFTPまたはFTP-DATAまたはドメイン」など、同じ修飾子を省略できますドメイン（ポート53））。 括弧と対応する演算子の助けを借りて、式要素を組み合わせることができます（ブラケットはシェルの特殊文字であるため、シェルスクリプトまたは端子で使用する場合は括弧を脱ぐ必要があります。 有効なオペレーターは次のとおりです。
ネガティブ操作（ `！ 'または` no `'）
操作（ `&& 'または` and'）
または操作（ `|| 'または`または'） ネガティブオペレーターは、操作または操作の優先順位と同じです。 'および'オペレーターは、フロントとバックの式要素を並列に配置する代わりに、明示的に記述する必要があります（NT：The 'および' 2つの中央の演算子は省略できません）。 識別子の前にキーワードがない場合、式の解析プロセス中に最近使用されたキーワード（多くの場合、識別子に最も近いキーワード）が使用されます。
ホストとエースではありません
これは、次の単純化された表現です。
ホストとホストのエースではありません
（ホストvsまたはエース）の代わりに。（NT：最初の2つは、必要なパケットがホストVSからではなく、またはエースから送信されることを意味します。 整個條件表達式可以被當作一個單獨的字符串參數也可以被當作空格分割的多個參數傳入tcpdump, 后者更方便些. 通常, 如果表達式中包含元字符(nt: 如正則表達式中的'*', '.'以及shell中的'('等字符)， 最好還是使用單獨字符串的方式傳入. 這時,整個表達式需要被單引號括起來. 多參數的傳入方式中, 所有參數最終還是被空格串聯在一起, 作為一個字符串被解析. 附錄:tcpdump的表達元 (nt: True 在以下的描述中含義為: 相應條件表達式中只含有以下所列的一個特定表達元, 此時表達式為真, 即條件得到滿足) dst host host
如果IPv4/v6 數據包的目的域是host, 則與此對應的條件表達式為真.host 可以是一個ip地址, 也可以是一個主機名.
src host host
如果IPv4/v6 數據包的源域是host, 則與此對應的條件表達式為真.
host 可以是一個ip地址, 也可以是一個主機名.
host host
如果IPv4/v6數據包的源或目的地址是host, 則與此對應的條件表達式為真.以上的幾個host 表達式之前可以添加以下關鍵字:ip, arp, rarp, 以及ip6.比如:
ip host host
也可以表達為:
ether proto \ip and host host(nt: 這種表達方式在下面有說明, 其中ip之前需要有\來轉義,因為ip 對tcpdump 來說已經是一個關鍵字了.)
如果host 是一個擁有多個IP 的主機, 那么任何一個地址都會用于包的匹配(nt: 即發向host 的數據包的目的地址可以是這幾個IP中的任何一個, 從host 接收的數據包的源地址也可以是這幾個IP中的任何一個).
ether dst ehost
如果數據包(nt: 指tcpdump 可抓取的數據包, 包括ip 數據包, tcp數據包)的以太網目標地址是ehost,則與此對應的條件表達式為真. Ehost 可以是/etc/ethers 文件中的名字或一個數字地址(nt: 可通過man ethers 看到對/etc/ethers 文件的描述, 樣例中用的是數字地址)
ether src ehost
如果數據包的以太網源地址是ehost, 則與此對應的條件表達式為真.
ether host ehost
如果數據包的以太網源地址或目標地址是ehost, 則與此對應的條件表達式為真.
gateway host
如果數據包的網關地址是host, 則與此對應的條件表達式為真. 需要注意的是, 這里的網關地址是指以太網地址, 而不是IP 地址(nt | rt: Ie, 例如, 可理解為'注意'.the Ethernet source or destination address, 以太網源和目標地址, 可理解為, 指代上句中的'網關地址' ).host 必須是名字而不是數字, 并且必須在機器的'主機名-ip地址'以及'主機名-以太地址'兩大映射關系中有其條目(前一映射關系可通過/etc/hosts文件, DNS 或NIS得到, 而后一映射關系可通過/etc/ethers 文件得到. nt: /etc/ethers并不一定存在, 可通過man ethers 看到其數據格式, 如何創建該文件, 未知,需補充).也就是說host 的含義是ether host ehost 而不是host host, 并且ehost必須是名字而不是數字.
目前, 該選項在支持IPv6地址格式的配置環境中不起作用(nt: configuration, 配置環境, 可理解為,通信雙方的網絡配置).
dst net net
如果數據包的目標地址(IPv4或IPv6格式)的網絡號字段為net, 則與此對應的條件表達式為真.
net 可以是從網絡數據庫文件/etc/networks 中的名字, 也可以是一個數字形式的網絡編號.
一個數字IPv4 網絡編號將以點分四元組(比如, 192.168.1.0), 或點分三元組(比如, 192.168.1 ), 或點分二元組(比如, 172.16), 或單一單元組(比如, 10)來表達;
對應于這四種情況的網絡掩碼分別是:四元組:255.255.255.255(這也意味著對net 的匹配如同對主機地址(host)的匹配:地址的四個部分都用到了),三元組:255.255.255.0, 二元組: 255.255.0.0, 一元組:255.0.0.0.
對于IPv6 的地址格式, 網絡編號必須全部寫出來(8個部分必須全部寫出來); 相應網絡掩碼為:
ff:ff:ff:ff:ff:ff:ff:ff, 所以IPv6 的網絡匹配是真正的'host'方式的匹配(nt | rt | rc:地址的8個部分都會用到,是否不屬于網絡的字節填寫0, 需接下來補充), 但同時需要一個網絡掩碼長度參數來具體指定前面多少字節為網絡掩碼(nt: 可通過下面的net net/len 來指定)
src net net
如果數據包的源地址(IPv4或IPv6格式)的網絡號字段為net, 則與此對應的條件表達式為真.
net net
如果數據包的源或目的地址(IPv4或IPv6格式)的網絡號字段為net, 則與此對應的條件表達式為真.
net net mask netmask
如果數據包的源或目的地址(IPv4或IPv6格式)的網絡掩碼與netmask 匹配, 則與此對應的條件表達式為真.此選項之前還可以配合src和dst來匹配源網絡地址或目標網絡地址(nt: 比如src net net mask 255.255.255.0).該選項對于ipv6 網絡地址無效.
net net/len
如果數據包的源或目的地址(IPv4或IPv6格式)的網絡編號字段的比特數與len相同, 則與此對應的條件表達式為真.此選項之前還可以配合src和dst來匹配源網絡地址或目標網絡地址(nt | rt | tt: src net net/24, 表示需要匹配源地址的網絡編號有24位的數據包).
dst port port
如果數據包(包括ip/tcp, ip/udp, ip6/tcp or ip6/udp協議)的目的端口為port, 則與此對應的條件表達式為真.port 可以是一個數字也可以是一個名字(相應名字可以在/etc/services 中找到該名字, 也可以通過man tcp 和man udp來得到相關描述信息). 如果使用名字, 則該名字對應的端口號和相應使用的協議都會被檢查. 如果只是使用一個數字端口號,則只有相應端口號被檢查(比如, dst port 513 將會使tcpdump抓取tcp協議的login 服務和udp協議的who 服務數據包, 而port domain 將會使tcpdump 抓取tcp協議的domain 服務數據包, 以及udp 協議的domain 數據包)(nt | rt: ambiguous name is used 不可理解, 需補充).
src port port
如果數據包的源端口為port, 則與此對應的條件表達式為真.
port port
如果數據包的源或目的端口為port, 則與此對應的條件表達式為真.
dst portrange port1-port2
如果數據包(包括ip/tcp, ip/udp, ip6/tcp or ip6/udp協議)的目的端口屬于port1到port2這個端口范圍(包括port1, port2), 則與此對應的條件表達式為真. tcpdump 對port1 和port2 解析與對port 的解析一致(nt:在dst port port 選項的描述中有說明).
src portrange port1-port2
如果數據包的源端口屬于port1到port2這個端口范圍(包括port1, port2), 則與此對應的條件表達式為真.
portrange port1-port2
如果數據包的源端口或目的端口屬于port1到port2這個端口范圍(包括port1, port2), 則與此對應的條件表達式為真.
以上關于port 的選項都可以在其前面添加關鍵字:tcp 或者udp, 比如:
tcp src port port
這將使tcpdump 只抓取源端口是port 的tcp數據包.
less length
如果數據包的長度比length 小或等于length, 則與此對應的條件表達式為真. 這與'len <= length' 的含義一致.
greater length
如果數據包的長度比length 大或等于length, 則與此對應的條件表達式為真. 這與'len >= length' 的含義一致.
ip proto protocol
如果數據包為ipv4數據包并且其協議類型為protocol, 則與此對應的條件表達式為真.
Protocol 可以是一個數字也可以是名字, 比如:icmp6, igmp, igrp(nt: Interior Gateway Routing Protocol,內部網關路由協議), pim(Protocol Independent Multicast, 獨立組播協議, 應用于組播路由器),ah, esp(nt: ah, 認證頭, esp 安全負載封裝, 這兩者會用在IP包的安全傳輸機制中), vrrp(Virtual Router Redundancy Protocol, 虛擬路由器冗余協議), udp, or tcp. 由于tcp , udp 以及icmp是tcpdump 的關鍵字,所以在這些協議名字之前必須要用\來進行轉義(如果在C-shell 中需要用\\來進行轉義). 注意此表達元不會把數據包中協議頭鏈中所有協議頭內容全部打印出來(nt: 實際上只會打印指定協議的一些頭部信息, 比如可以用tcpdump -i eth0 'ip proto \tcp and host 192.168.3.144', 則只打印主機192.168.3.144 發出或接收的數據包中tcp 協議頭所包含的信息)
ip6 proto protocol
如果數據包為ipv6數據包并且其協議類型為protocol, 則與此對應的條件表達式為真.
注意此表達元不會把數據包中協議頭鏈中所有協議頭內容全部打印出來
ip6 protochain protocol
如果數據包為ipv6數據包并且其協議鏈中包含類型為protocol協議頭, 則與此對應的條件表達式為真. 比如, ip6 protochain 6
將匹配其協議頭鏈中擁有TCP 協議頭的IPv6數據包.此數據包的IPv6頭和TCP頭之間可能還會包含驗證頭, 路由頭, 或者逐跳尋徑選項頭.
由此所觸發的相應BPF(Berkeley Packets Filter, 可理解為, 在數據鏈路層提供數據包過濾的一種機制)代碼比較繁瑣,
并且BPF優化代碼也未能照顧到此部分, 從而此選項所觸發的包匹配可能會比較慢.
ip protochain protocol
與ip6 protochain protocol 含義相同, 但這用在IPv4數據包.
ther broadcast
如果數據包是以太網廣播數據包, 則與此對應的條件表達式為真. ether 關鍵字是可選的.
ip broadcast
如果數據包是IPv4廣播數據包, 則與此對應的條件表達式為真. 這將使tcpdump 檢查廣播地址是否符合全0和全1的一些約定,并查找網絡接口的網絡掩碼(網絡接口為當時在其上抓包的網絡接口).
如果抓包所在網絡接口的網絡掩碼不合法, 或者此接口根本就沒有設置相應網絡地址和網絡， 亦或是在linux下的'any'網絡接口上抓包(此'any'接口可以收到系統中不止一個接口的數據包(nt: 實際上, 可理解為系統中所有可用的接口)),網絡掩碼的檢查不能正常進行.
ether multicast
如果數據包是一個以太網多點廣播數據包(nt: 多點廣播, 可理解為把消息同時傳遞給一組目的地址, 而不是網絡中所有地址,后者為可稱為廣播(broadcast)), 則與此對應的條件表達式為真. 關鍵字ether 可以省略. 此選項的含義與以下條件表達式含義一致:`ether[0] & 1 != 0'(nt: 可理解為, 以太網數據包中第0個字節的最低位是1, 這意味這是一個多點廣播數據包).
ip multicast
如果數據包是ipv4多點廣播數據包, 則與此對應的條件表達式為真.
ip6 multicast
如果數據包是ipv6多點廣播數據包, 則與此對應的條件表達式為真.
ether proto protocol
如果數據包屬于以下以太協議類型, 則與此對應的條件表達式為真.
協議(protocol)字段, 可以是數字或以下所列出了名字: ip, ip6, arp, rarp, atalk(AppleTalk網絡協議),
aarp(nt: AppleTalk Address Resolution Protocol, AppleTalk網絡的地址解析協議),
decnet(nt: 一個由DEC公司所提供的網絡協議棧), sca(nt: 未知, 需補充),
lat(Local Area Transport, 區域傳輸協議, 由DEC公司開發的以太網主機互聯協議),
mopdl, moprc, iso(nt: 未知, 需補充), stp(Spanning tree protocol, 生成樹協議, 可用于防止網絡中產生鏈接循環),
ipx（nt: Internetwork Packet Exchange, Novell 網絡中使用的網絡層協議）, 或者
netbeui(nt: NetBIOS Extended User Interface，可理解為, 網絡基本輸入輸出系統接口擴展).
protocol字段可以是一個數字或以下協議名之一:ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat,
mopdl, moprc, iso, stp, ipx, 或者netbeui.
必須要注意的是標識符也是關鍵字, 從而必須通過'\'來進行轉義.
SNAP：子網接入協議（SubNetwork Access Protocol）)
在光纖分布式數據網絡接口(其表達元形式可以是'fddi protocol arp'), 令牌環網(其表達元形式可以是'tr protocol arp'),
以及IEEE 802.11 無線局域網(其表達元形式可以是'wlan protocol arp')中, protocol
標識符來自802.2 邏輯鏈路控制層頭,
在FDDI, Token Ring 或802.1頭中會包含此邏輯鏈路控制層頭.
當以這些網絡上的相應的協議標識為過濾條件時, tcpdump只是檢查LLC頭部中以0x000000為組成單元標識符(OUI, 0x000000
標識一個內部以太網)的一段'SNAP格式結構'中的protocol ID 域, 而不會管包中是否有一段OUI為0x000000的'SNAP格式結構'(nt: SNAP, SubNetwork Access Protocol,子網接入協議). 以下例外:
iso tcpdump 會檢查LLC頭部中的DSAP域(Destination service Access Point, 目標服務接入點)和
SSAP域(源服務接入點).(nt: iso 協議未知, 需補充)
stp 以及netbeui
tcpdump 將會檢查LLC 頭部中的目標服務接入點(Destination service Access Point);
atalk
tcpdump 將會檢查LLC 頭部中以0x080007 為OUI標識的'SNAP格式結構', 并會檢查AppleTalk etype域.
(nt: AppleTalk etype 是否位于SNAP格式結構中, 未知, 需補充).
此外, 在以太網中, 對于ether proto protocol 選項, tcpdump 會為protocol 所指定的協議檢查以太網類型域(the Ethernet type field), 但以下這些協議除外:
iso, stp, and netbeui
tcpdump 將會檢查802.3 物理幀以及LLC 頭(這兩種檢查與FDDI, TR, 802.11網絡中的相應檢查一致);
(nt: 802.3, 理解為IEEE 802.3, 其為一系列IEEE 標準的集合. 此集合定義了有線以太網絡中的物理層以及數據鏈路層的媒體接入控制子層. stp 在上文已有描述)
atalk
tcpdump 將會檢查以太網物理幀中的AppleTalk etype 域, 同時也會檢查數據包中LLC頭部中的'SNAP格式結構'
(這兩種檢查與FDDI, TR, 802.11網絡中的相應檢查一致)
aarp tcpdump 將會檢查AppleTalk ARP etype 域, 此域或存在于以太網物理幀中, 或存在于LLC(由802.2 所定義)的
'SNAP格式結構'中, 當為后者時, 該'SNAP格式結構'的OUI標識為0x000000;
(nt: 802.2, 可理解為, IEEE802.2, 其中定義了邏輯鏈路控制層(LLC), 該層對應于OSI 網絡模型中數據鏈路層的上層部分.
LLC 層為使用數據鏈路層的用戶提供了一個統一的接口(通常用戶是網絡層). LLC層以下是媒體接入控制層(nt: MAC層,
對應于數據鏈路層的下層部分).該層的實現以及工作方式會根據不同物理傳輸媒介的不同而有所區別(比如, 以太網, 令牌環網,
光纖分布數據接口(nt: 實際可理解為一種光纖網絡), 無線局域網(802.11), 等等.)
ipx tcpdump 將會檢查物理以太幀中的IPX etype域, LLC頭中的IPX DSAP域，無LLC頭并對IPX進行了封裝的802.3幀,
以及LLC 頭部'SNAP格式結構'中的IPX etype 域(nt | rt: SNAP frame, 可理解為, LLC 頭中的'SNAP格式結構'.
該含義屬初步理解階段, 需補充).
decnet src host
如果數據包中DECNET源地址為host, 則與此對應的條件表達式為真.
(nt:decnet, 由Digital Equipment Corporation 開發, 最早用于PDP-11 機器互聯的網絡協議)
decnet dst host
如果數據包中DECNET目的地址為host, 則與此對應的條件表達式為真.
(nt: decnet 在上文已有說明)
decnet host host
如果數據包中DECNET目的地址或DECNET源地址為host, 則與此對應的條件表達式為真.
(nt: decnet 在上文已有說明)
ifname interface
如果數據包已被標記為從指定的網絡接口中接收的, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
on interface
與ifname interface 含義一致.
rnr num
如果數據包已被標記為匹配PF的規則, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
rulenum num
與rulenum num 含義一致.
reason code
如果數據包已被標記為包含PF的匹配結果代碼, 則與此對應的條件表達式為真.有效的結果代碼有: match, bad-offset,
fragment, short, normalize, 以及memory.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
rset name
如果數據包已被標記為匹配指定的規則集, 則與此對應的條件表達式為真.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
ruleset name
與rset name 含義一致.
srnr num
如果數據包已被標記為匹配指定的規則集中的特定規則(nt: specified PF rule number, 特定規則編號, 即特定規則),
則與此對應的條件表達式為真.(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為
OpenBSD中的防火墻程序))
subrulenum num
與srnr 含義一致.
action act
如果包被記錄時PF會執行act指定的動作, 則與此對應的條件表達式為真. 有效的動作有: pass, block.
(此選項只適用于被OpenBSD中pf程序做過標記的包(nt: pf, packet filter, 可理解為OpenBSD中的防火墻程序))
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
與以下表達元含義一致:
ether proto p
p是以上協議中的一個.
lat, moprc, mopdl
與以下表達元含義一致:
ether proto p
p是以上協議中的一個. 必須要注意的是tcpdump目前還不能分析這些協議.
vlan [vlan_id]
如果數據包為IEEE802.1Q VLAN 數據包, 則與此對應的條件表達式為真.
(nt: IEEE802.1Q VLAN, 即IEEE802.1Q 虛擬網絡協議, 此協議用于不同網絡的之間的互聯).
如果[vlan_id] 被指定, 則只有數據包含有指定的虛擬網絡id(vlan_id), 則與此對應的條件表達式為真.
要注意的是, 對于VLAN數據包, 在表達式中遇到的第一個vlan關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移). 在VLAN網絡體系中過濾數據包時, vlan [vlan_id]表達式可以被多次使用. 關鍵字vlan每出現一次都會增加
4字節過濾偏移(nt: 過濾偏移, 可理解為上面的解碼偏移).
例えば：
vlan 100 && vlan 200
表示: 過濾封裝在VLAN100中的VLAN200網絡上的數據包再例如:
vlan && vlan 300 && ip
表示: 過濾封裝在VLAN300 網絡中的IPv4數據包, 而VLAN300網絡又被更外層的VLAN封裝
mpls [label_num]
如果數據包為MPLS數據包, 則與此對應的條件表達式為真.
(nt: MPLS, Multi-Protocol Label Switch, 多協議標簽交換, 一種在開放的通信網上利用標簽引導數據傳輸的技術).
如果[label_num] 被指定, 則只有數據包含有指定的標簽id(label_num), 則與此對應的條件表達式為真.
要注意的是, 對于內含MPLS信息的IP數據包(即MPLS數據包), 在表達式中遇到的第一個MPLS關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移). 在MPLS網絡體系中過濾數據包時, mpls [label_num]表達式可以被多次使用. 關鍵字mpls每出現一次都會增加
4字節過濾偏移(nt: 過濾偏移, 可理解為上面的解碼偏移).
例えば：
mpls 100000 && mpls 1024
表示: 過濾外層標簽為100000 而層標簽為1024的數據包再如:
mpls && mpls 1024 && host 192.9.200.1
表示: 過濾發往或來自192.9.200.1的數據包, 該數據包的內層標簽為1024, 且擁有一個外層標簽.
pppoed
如果數據包為PPP-over-Ethernet的服務器探尋數據包(nt: Discovery packet,
其ethernet type 為0x8863),則與此對應的條件表達式為真.
(nt: PPP-over-Ethernet, 點對點以太網承載協議, 其點對點的連接建立分為Discovery階段(地址發現) 和
PPPoE 會話建立階段, discovery 數據包就是第一階段發出來的包. ethernet type
是以太幀里的一個字段，用來指明應用于幀數據字段的協議)
pppoes
如果數據包為PPP-over-Ethernet會話數據包(nt: ethernet type 為0x8864, PPP-over-Ethernet在上文已有說明, 可搜索關鍵字'PPP-over-Ethernet'找到其描述), 則與此對應的條件表達式為真.
要注意的是, 對于PPP-over-Ethernet會話數據包, 在表達式中遇到的第一個pppoes關鍵字會改變表達式中接下來關鍵字所對應數據包中數據的開始位置(即解碼偏移).
例えば：
pppoes && ip
表示: 過濾嵌入在PPPoE數據包中的ipv4數據包
tcp, udp, icmp
與以下表達元含義一致:
ip proto p or ip6 proto p
其中p 是以上協議之一(含義分別為: 如果數據包為ipv4或ipv6數據包并且其協議類型為tcp,udp, 或icmp則與此對應的條件表達式為真)
iso proto protocol
如果數據包的協議類型為iso-osi協議棧中protocol協議, 則與此對應的條件表達式為真.(nt: [初解]iso-osi 網絡模型中每層的具體協議與tcp/ip相應層采用的協議不同. iso-osi各層中的具體協議另需補充)
protocol 可以是一個數字編號, 或以下名字中之一:
clnp, esis, or isis.
(nt: clnp, Connectionless Network Protocol, 這是OSI網絡模型中網絡層協議, esis, isis 未知, 需補充)
clnp, esis, isis
是以下表達的縮寫
iso proto p
其中p 是以上協議之一
l1, l2, iih, lsp, snp, csnp, psnp
為IS-IS PDU 類型的縮寫.
(nt: IS-IS PDU, Intermediate system to intermediate system Protocol Data Unit, 中間系統到中間系統的協議數據單元. OSI(Open Systems Interconnection)網絡由終端系統, 中間系統構成.
終端系統指路由器, 而終端系統指用戶設備. 路由器形成的本地組稱之為'區域'（Area）和多個區域組成一個'域'（Domain）.
IS-IS 提供域內或區域內的路由. l1, l2, iih, lsp, snp, csnp, psnp 表示PDU的類型, 具體含義另需補充)
vpi n
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且其虛擬路徑標識為n, 則與此對應的條件表達式為真.
(nt: ATM, Asychronous Transfer Mode, 實際上可理解為由ITU-T(國際電信聯盟電信標準化部門)提出的一個與
TCP/IP中IP層功能等同的一系列協議, 具體協議層次另需補充)
vci n
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且其虛擬通道標識為n, 則與此對應的條件表達式為真.
(nt: ATM, 在上文已有描述)
lane
如果數據包為ATM LANE 數據包, 則與此對應的條件表達式為真. 要注意的是, 如果是模擬以太網的LANE數據包或者
LANE邏輯單元控制包, 表達式中第一個lane關鍵字會改變表達式中隨后條件的測試. 如果沒有指定lane關鍵字, 條件測試將按照數據包中內含LLC(邏輯鏈路層)的ATM包來進行.
LLC
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備,
如果數據包為ATM數據包, 并且內含LLC則與此對應的條件表達式為真
oamf4s
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是Segment OAM F4 信元(VPI=0 并且VCI=3), 則與此對應的條件表達式為真.
(nt: OAM, Operation Administration and Maintenance, 操作管理和維護,可理解為:ATM網絡中用于網絡管理所產生的ATM信元的分類方式.
ATM網絡中傳輸單位為信元, 要傳輸的數據終究會被分割成固定長度(53字節)的信元,
(初理解: 一條物理線路可被復用, 形成虛擬路徑(virtual path). 而一條虛擬路徑再次被復用, 形成虛擬信道(virtual channel)).
通信雙方的編址方式為:虛擬路徑編號(VPI)/虛擬信道編號(VCI)).
OAM F4 flow 信元又可分為segment 類和end-to-end 類, 其區別未知, 需補充.)
oamf4e
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end OAM F4 信元(VPI=0 并且VCI=4), 則與此對應的條件表達式為真.
(nt: OAM 與end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'來定位)
oamf4
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end 或segment OAM F4 信元(VPI=0 并且VCI=3 或者VCI=4), 則與此對應的條件表達式為真.
(nt: OAM 與end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'來定位)
oam
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是end-to-end 或segment OAM F4 信元(VPI=0 并且VCI=3 或者VCI=4), 則與此對應的條件表達式為真.
(nt: 此選項與oamf4重復, 需確認)
metac
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'元信令線路'(nt: VPI=0 并且VCI=1, '元信令線路', meta signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
cc の
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'廣播信令線路'(nt: VPI=0 并且VCI=2, '廣播信令線路', broadcast signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
scで
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'信令線路'(nt: VPI=0 并且VCI=5, '信令線路', signaling circuit, 具體含義未知, 需補充),
則與此對應的條件表達式為真.
ilmic
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'ILMI線路'(nt: VPI=0 并且VCI=16, 'ILMI', Interim Local Management Interface , 可理解為基于SNMP(簡易網絡管理協議)的用于網絡管理的接口)則與此對應的條件表達式為真.
connectmsg
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'信令線路'并且是Q.2931協議中規定的以下幾種消息: Setup, Calling Proceeding, Connect,
Connect Ack, Release, 或者Release Done. 則與此對應的條件表達式為真.
(nt: Q.2931 為ITU(國際電信聯盟)制定的信令協議. 其中規定了在寬帶綜合業務數字網絡的用戶接口層建立, 維護, 取消網絡連接的相關步驟.) metaconnect
如果數據包為ATM數據包, 則與此對應的條件表達式為真. 對于Solaris 操作系統上的SunATM設備, 如果數據包為ATM數據包并且是來自'元信令線路'并且是Q.2931協議中規定的以下幾種消息: Setup, Calling Proceeding, Connect,
Connect Ack, Release, 或者Release Done. 則與此對應的條件表達式為真. expr relop expr
如果relop 兩側的操作數(expr)滿足relop 指定的關系, 則與此對應的條件表達式為真.
relop 可以是以下關系操作符之一: >, <, <=, =, !=.
expr 是一個算術表達式. 此表達式中可使用整型常量(表示方式與標準C中一致), 二進制操作符(+, -, *, /, &, |,
<<, >>), 長度操作符, 以及對特定數據包中數據的引用操作符. 要注意的是, 所有的比較操作都默認操作數是無符號的,
例如, 0x80000000 和0xffffffff 都是大于0的(nt: 對于有符號的比較, 按照補碼規則, 0xffffffff
會小于0). 如果要引用數據包中的數據, 可采用以下表達方式:
proto [expr : size]
proto 的取值可以是以下取值之一:ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp,
tcp, udp, icmp, ip6 或者radio. 這指明了該引用操作所對應的協議層.(ether, fddi, wlan,
tr, ppp, slip and link 對應于數據鏈路層, radio 對應于802.11(wlan,無線局域網)某些數據包中的附帶的
"radio"頭(nt: 其中描述了波特率, 數據加密等信息)).
要注意的是, tcp, udp 等上層協議目前只能應用于網絡層采用為IPv4或IPv6協議的網絡(此限制會在tcpdump未來版本中進行修改). 對于指定協議的所需數據, 其在包數據中的偏移字節由expr 來指定.
以上表達中size 是可選的, 用來指明我們關注那部分數據段的長度(nt:通常這段數據是數據包的一個域)， 其長度可以是1, 2, 或4個字節. 如果不給定size, 默認是1個字節. 長度操作符的關鍵字為len,
這代碼整個數據包的長度.
例如, 'ether[0] & 1 != 0' 將會使tcpdump 抓取所有多點廣播數據包.(nt: ether[0]字節的最低位為1表示數據包目的地址是多點廣播地址). 'ip[0] & 0xf != 5' 對應抓取所有帶有選項的
IPv4數據包. 'ip[6:2] & 0x1fff = 0'對應抓取沒被破碎的IPv4數據包或者其片段編號為0的已破碎的IPv4數據包. 這種數據檢查方式也適用于tcp和udp數據的引用,
即, tcp[0]對應于TCP 頭中第一個字節, 而不是對應任何一個中間的字節.
一些偏移以及域的取值除了可以用數字也可用名字來表達. 以下為可用的一些域(協議頭中的域)的名字: icmptype (指ICMP 協議頭中type域), icmpcode (指ICMP 協議頭code 域), 以及tcpflags(指TCP協議頭的flags 域)
以下為ICMP 協議頭中type 域的可用取值:
icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert,
icmp-routersolicit, icmp-timx-ceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply,
icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.
以下為TCP 協議頭中flags 域的可用取值:tcp-fin, tcp-syn, tcp-rst, tcp-push,
tcp-ack, tcp-urg. 到此這篇關于Linux下tcpdump命令解析及使用詳解的文章就介紹到這了,更多相關Linux tcpdump命令內容請搜索123WORDPRESS.COM以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持123WORDPRESS.COM！ 以下もご興味があるかもしれません:- Linux通過sar命令查看網卡流量
- 詳談linux中sar的使用方法
- Linux コマンド sort、uniq、tr ツールの詳細な説明
- Linux での stat 関数と stat コマンドの使用法の詳細な説明
- Linux の cut コマンドの説明
- Linux常用命令之grep命令用法詳解
- Linux 常用命令操作大全(推薦收藏)
- Linux sar コマンドの使用方法とコード例の分析
| 
