Linux のパケット キャプチャ コマンド tcpdump は何に役立ちますか?

Linux パケット キャプチャ コマンド tcpdump は、ネットワーク送信データをダンプするために使用されます。ネットワーク内で送信されたデータ パケットの「ヘッダー」を完全に傍受し、分析を行うことができます。ネットワーク層、プロトコル、ホスト、ネットワークをサポートしています。フィルタリングして、and、or、not などの論理ステートメントを提供すると、無駄な情報を削除できます。

#関連する推奨事項: 「

Linux ビデオ チュートリアル 」

はじめに

Linux tcpdump コマンドは、ネットワーク伝送データをダンプするために使用されます。

tcpdump コマンドを実行して、指定したネットワーク インターフェイスを通過するパケットのヘッダーを一覧表示します。Linux オペレーティング システムでは、システム管理者である必要があります。

tcpdump を簡単に定義すると、ネットワーク上のトラフィックをダンプする、ユーザーの定義に従ってネットワーク上のデータ パケットを傍受するパケット分析ツールです。 tcpdump は、ネットワーク上で送信されるデータ パケットの「ヘッダー」を完全に傍受し、分析を行うことができます。ネットワーク層、プロトコル、ホスト、ネットワーク、またはポートのフィルタリングをサポートし、不要な情報の削除に役立つ and や or、not などの論理ステートメントを提供します。

実際のコマンド例

デフォルトで開始

tcpdump

Normal状況 次に、

tcpdump を直接起動すると、最初のネットワーク インターフェイス上を流れるすべてのデータ パケットが監視されます。

指定されたネットワーク インターフェイスのデータ パケットを監視します

tcpdump -i eth1

ネットワーク カードを指定しない場合、デフォルトでは、tcpdump は、最初のネットワーク インターフェイス、通常は eth0 ですが、以下の例ではネットワーク インターフェイスを指定していません。

指定したホストのパケットを監視します

日没に出入りするすべてのパケットを出力します。

tcpdump host sundown

を指定することもできますたとえば、ip は、すべての

210.27.48.1

tcpdump host 210.27.48.1

によって送受信されたすべてのデータ パケットを傍受します。

helios と hot または ace の間で通信されたデータ パケットを出力します。

tcpdump host helios and \( hot or ace \)

ホスト 210.27.48.1 とホスト 210.27.48.2 または 210.27.48.3

tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)

の間で通信される他のホスト IP パケットとの通信

tcpdump ip host ace and not helios

ホストを取得したい場合は、210.27.48.1ホストに加えて210.27.48.2#ip 以外のすべてのホストによって通信された ## パケットについては、次のコマンドを使用します:

tcpdump ip host 210.27.48.1 and ! 210.27.48.2

ホストによって送信されたすべてのデータを傍受する

hostname

tcpdump -i eth0 src host hostname

ホストに送信されたすべてのデータ パケットを監視する

hostname

tcpdump -i eth0 dst host hostname

指定したホストとポートのデータ パケットを監視します

ホスト # を取得したい場合は、 ##210.27.48.1

telnet パケットを受信または送信するには、次のコマンド

tcpdump tcp port 23 and host 210.27.48.1

を使用して、このマシンの

udp 123

ポート 123 を監視します。 ntp

tcpdump udp port 123

指定されたネットワークのパケットを監視する

ローカル ホストとバークレーを出力するサービス ポートネットワーク上のホスト間のすべての通信パケット (nt: ucb-ether、ここでは「バークレー ネットワーク」のネットワーク アドレスとして理解できます。この式の本来の意味は次のように表現できます: ucb-ether のネットワーク アドレスを出力します。 packets)

tcpdump net ucb-ether

ゲートウェイ スナップを通過するすべての FTP パケットを出力します (式は一重引用符で囲まれており、シェルが括弧を誤って解析するのを防ぐことに注意してください)

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

すべての IP パケットを出力します送信元アドレスまたは宛先アドレスがローカル ホストである

(ローカル ネットワークがゲートウェイを介して他のネットワークに接続されている場合、他のネットワークはローカル ネットワークとしてカウントできません。(nt: この文には曲がりくねった翻訳があります) 、補足する必要があります)。localnet は、実際に使用するときはローカル ネットワークの名前に置き換える必要があります)

tcpdump ip and not net localnet

#指定されたプロトコルのデータ パケットを監視します

#印刷 TCP セッションの開始データ パケットと終了データ パケット、およびデータ パケットの送信元または宛先がローカル ネットワーク上のホストではありません。(nt: localnet、ローカル ネットワークの名前に置き換える必要があります)実際に使用する場合はネットワーク))

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

データを含まない SYN、FIN、ACK のみのパケットの代わりに、80、ネットワーク層プロトコルが IPv4、データを含むすべての送信元ポートまたは宛先ポートを出力します。 (式の ipv6 バージョンは演習として使用できます)

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

(nt: ip[2:2] は IP データ パケット全体の長さを表し、(ip[0] &0xf)

成字节数需要乘以4,　即左移2.　(tcp[12]&0xf0)>>4 表示tcp头的长度, 此域的单位也是32bit,　换算成比特数为 ((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头中的'Payload Length' 与 'tcp头的长度'的差值, 并且其中表达方式'ip[]'需换成'ip6[]'.)

打印长度超过576字节, 并且网关地址是snup的IP数据包

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

打印所有IP层广播或多播的数据包， 但不是物理以太网层的广播或多播数据报

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

打印除'echo request'或者'echo reply'类型以外的ICMP数据包( 比如,需要打印所有非ping 程序产生的数据包时可用到此表达式 .
(nt: 'echo reuqest' 与 'echo reply' 这两种类型的ICMP数据包通常由ping程序产生))

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

tcpdump 与wireshark

Wireshark(以前是ethereal)是Windows下非常简单易用的抓包工具。但在Linux下很难找到一个好用的图形化抓包工具。
还好有Tcpdump。我们可以用Tcpdump + Wireshark 的完美组合实现：在 Linux 里抓包，然后在Windows 里分析包。

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)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 or tcp[20:2]=0x4854

0x4745 为"GET"前两个字母"GE",0x4854 为"HTTP"前两个字母"HT"。

tcpdump 对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中，然后再使用其他程序(如Wireshark)进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘。

输出信息含义

首先我们注意一下，基本上tcpdump总的的输出格式为：系统时间 来源主机.端口 > 目标主机.端口 数据包参数

tcpdump 的输出格式与协议有关.以下简要描述了大部分常用的格式及相关例子.

链路层头

对于FDDI网络, '-e' 使tcpdump打印出指定数据包的'frame control' 域, 源和目的地址, 以及包的长度.(frame control域
控制对包中其他域的解析). 一般的包(比如那些IP datagrams)都是带有'async'(异步标志)的数据包，并且有取值0到7的优先级;
比如 'async4'就代表此包为异步数据包，并且优先级别为4. 通常认为,这些包们会内含一个 LLC包(逻辑链路控制包); 这时,如果此包
不是一个ISO datagram或所谓的SNAP包，其LLC头部将会被打印(nt:应该是指此包内含的 LLC包的包头).

对于Token Ring网络(令牌环网络), '-e' 使tcpdump打印出指定数据包的'frame control'和'access control'域, 以及源和目的地址,
外加包的长度. 与FDDI网络类似, 此数据包通常内含LLC数据包. 不管 是否有'-e'选项.对于此网络上的'source-routed'类型数据包(nt:
意译为:源地址被追踪的数据包,具体含义未知,需补充), 其包的源路由信息总会被打印.

对于802.11网络(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定数据包的'frame control域,
包头中包含的所有地址, 以及包的长度.与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 個以上の「変更」が出力されます。「変更」は次の形式で出力されます:
'flag' /-/=n の長さパケット データと圧縮ヘッダーの長さ。
ここで、「フラグ」は次の値を取ることができます:
U (緊急ポインタを表す)、W (バッファ ウィンドウを参照)、A (応答)、S (シーケンス番号) 、I (パッケージ ID)、および増分表現 '=n' は、新しい値を意味します。値、/- は増加または減少を意味します。

たとえば、次の例は、発信圧縮 TCP パケットの出力を示しています。このパケットには接続識別子が含まれています。応答番号は 6 増加します。
シーケンス番号は 49 増加し、パケット ID 番号は 6 増加します。パケット データ長は 3 バイト (オクテクト)、圧縮ヘッダーは次のとおりです。は 6 バイトです (nt: これは特別な圧縮データ パッケージではないようです)。

ARP/RARP パケット

Arp/rarp パッケージの tcpdump の出力情報には、リクエスト タイプが含まれます。およびリクエストに対応するパラメータ。表示形式は簡潔かつ明確です。以下は、rtsg からホスト csam:
への「rlogin」
(リモート ログイン) プロセスの開始時のホスト データ パケットのサンプルです。 arp who-has csam Tell rtsg
arp Reply csam is-at CSAM
最初の行は、csam のイーサネット アドレスを問い合わせるために rtsg が arp パケット (nt: ネットワーク セグメント全体に送信、arp パケット) を送信したことを示します
Csam (nt: 下から見ると Csam です) と独自のイーサネットを使用します。 ネットワーク アドレスが応答しました (この例では、イーサネット アドレスは大文字の名前とインターネット
アドレス (つまり、IP) で識別されます)アドレス) はすべて小文字の名前で識別されます。

tcpdump -n を使用すると、名前識別子の代わりにイーサネット アドレスと IP アドレスを明確に確認できます:
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 を使用すると、最初のデータ パケットがネットワーク全体にブロードキャストされていることがはっきりとわかります。ネットワーク全体、2 番目のデータ パケットはポイントツーポイントです:
RTSG Broadcast 0806 64: arp who-has csam Tell rtsg
CSAM RTSG 0806 64: arp Reply csam is-at CSAM
最初のデータ パケットデータ パケットは次のことを示します。arp パケットの送信元イーサネット アドレスは RTSG、宛先アドレスは完全なイーサネット セグメント、タイプ フィールドの値は 16 進数の 0806 (ETHER_ARP (nt: arp パケット タイプ識別子) を表す)、
パケットの合計の長さは 64 バイトです。

TCP データ パケット

##(注: 以下の説明は、TCP に精通していることを前提としています) RFC-793 で説明されているとおりです。詳しくない場合は、次の説明と tcpdump プログラムはあまり役に立たないかもしれません。(nt: 警告は無視される可能性があります。

読み続けて、必要な場合は戻って読んでください)あまり馴染みがありません。).

通常、tcpdump は次の形式で tcp データ パケットを表示します:

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

src およびdst は、送信元および宛先の IP アドレスと対応するポートです。フラグ flag は、S(SYN)、F(FIN)、P(PUSH、R(RST)、

W (ECN CWT (nt | rep: 不明、補足する必要があります)) または E (ECN-Echo (nt | rep: 不明、補足する必要があります)))、
単一の '.' はフラグ識別子がないことを意味します。 データ セグメント シーケンス番号 (Data-seqno ）は、このパケット内のデータに対応するシーケンス番号空間内の位置を記述します（nt：データ全体がセグメント化されており、
各セグメントにはシーケンス番号があり、すべてのシーケンス番号がシーケンス番号空間を構成します）（ Ack は、同じ接続、同じ方向、ローカル エンドが受信する (相手が送信する) 次の
データ フラグメントのシーケンス番号を記述します。Window は、ローカル エンドで利用可能なデータ受信バッファです。 end. データのサイズ (相手はデータを送信する際にこのサイズに合わせてデータを整理する必要があります)
Urg (緊急) データパケット内に緊急のデータがあることを示します options は tcp のいくつかのオプションを記述しますこれらのオプションは山かっこ ( など) で表されます。

src、dst、flags の 3 つのフィールドが常に表示されます。他のフィールドが表示されるかどうかは、tcp プロトコル ヘッダーの情報によって決まります。 .

これは、trsg から 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 から TCP に送信されることを示します。 csam ホストのポート ログイン上 (nt: udp プロトコルのポートと tcp プロトコルのポートは 2 つの別々のスペースですが、値の範囲は同じです)。S は SYN フラグが設定されていることを意味します。シーケンス番号パケットの番号は 768512 で、データは含まれません (表現形式
は、「first:last(nbytes)」です。これは、「このパッケージ内のデータのシーケンス番号が最初から始まり、最後で終わり、最後を除き、n バイトを含むユーザーの総数は
Data' です。) ピギーバック応答はありません (nt: 以下から、2 行目はピギーバック応答のあるデータ パケットです)、利用可能な受け入れウィンドウのサイズは 4096 バイトであり、要求側 (rtsg) の最大許容値です。
データ セグメント サイズは 1024 バイトです (nt: この情報は、二者間のさらなるネゴシエーションの要求として応答側 csam に送信されます)。
##Csam は基本的に同じ SYN データ パケットで rtsg に応答しましたが、違いは「ピギーバック ACK」(nt: ピギーバック ACK 応答、rtsg の SYN パケットの場合) であることだけです。 ##rtsg も csam の SYN パケットに対する応答として ACK パケットを返しました。'. ' は、このパケットにフラグが設定されていないことを意味します。この応答パケットにはデータが含まれていないため、データ セグメント シーケンス番号はありません

packet. 注意! この ACK パケットのシーケンス番号は、小さな整数 1 です。 はい 次の説明: TCP 接続上のセッションの場合、tcpdump は両端の

初期パケットのシーケンス番号のみを出力します。セッションの、後続の対応するパケットは、最初のパケット シーケンス番号との差を出力するだけです。つまり、最初のシーケンス番号以降のシーケンスは、このセッション上で現在送信されているデータ フラグメントの「相対バイト」位置と見なすことができます。送信される

データ全体のセッション (nt: 両側の最初の位置は 1 です。つまり、「相対バイト」「-S」はこの関数をオーバーライドします。

これにより、送信されるデータの元のシーケンス番号が
になります。印刷するデータ パケット

6 行目の意味: rtsg は 19 バイトを csam データに送信しました (バイトには 2 ～ 20 の番号が付けられ、送信方向は rtsg から csam です)。 7 行目で、
csam は、 rtsg から 21 未満のバイトを受信したことを叫びますが、21 番のバイトは含まれていません。これらのバイトは、csam のソケットの受信バッファに格納されます。これに応じて、

受信バッファcsam のウィンドウ サイズは 19 バイト減少します (nt: は 5 行目と 5 行目から取得できます。7 行目で win 属性値の変化がわかります)。csam はまた、パッケージ内の rtsg に

バイトを送信しました。 7 行目。8 行目と 9 行目で、csam はそれぞれ rtsg に 2 バイトを送信し続けました。1 バイトのデータ パケットが含まれており、このデータ パケットには PUSH フラグが付いています。

If キャプチャされた tcp パケット (nt:ここのスナップショット) が小さすぎるため、tcpdump はヘッダー データを完全に取得できません。この時点で、tcpdump は不完全なヘッダー
を解析しようとし、残りの解析できない部分を '[|tcp]' として表示します。属性情報が偽である場合 (たとえば、その長さ属性が実際にはヘッダーよりも長い、ヘッダーの実際の長さが長いか短いなど)、tcpdump はヘッダー

に対して「[bad opt]」を表示します。いくつかのオプション (nt | rt: 以下から、TCP パケットのヘッダーを指します。このセクションの ip パッケージのいくつかのオプションを参照してください) は、このパッケージに含まれます。

そして、実際の IP の長さ(データ パケットはこれらのオプションに対応するには十分ではありません。tcpdump は「[不正な hdr 長]」を表示します。

特別なフラグ (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 ビットは 3 番目になります。 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|

制御セグメント In のデータ、ビット 1 のみ (

バイト番号 13 が 8 ビットの符号なし文字タイプであり、ネットワークのバイト番号に従ってソートされているとします (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(nt: 1 * 2^6 1×2の6乗を表します。たぶんこれつまり、以下の元の式の指数 7 6... 0 を移動して表現します)

は目標に近いです。なぜなら、次のことがすでに知られているからです。データ パケットが設定されている場合、ヘッダーの 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 が一番下に移動されます。 #これでは、SYN-ACK フラグを含むパケットのみが選択され、その他は破棄されるため、tcpdump のフィルター式として 'tcp[13] 18' を使用することはできません。あなた自身、私たち 目標は、パケットの SYN フラグが設定されている限り、他のフラグを無視することです。

目標を達成するには、バイト 13 のバイナリ値と別の数値を AND する必要があります。 (nt: 論理 AND) を使用して SYN ビットの値を取得します。目標は、SYN が設定されている限り
であるため、それをバイト 13 (nt: 00000010) の SYN 値と結合します。

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'

一重引用符またはバックスラッシュ (ここでは一重引用符が使用されています) は省略できないことに注意してください。省略すると、シェルによる &.

UDP データ パケット ## の解釈や置換ができなくなる可能性があります。 #UDP データ パケットの表示形式は、特定のアプリケーションによって生成されたデータ パケット rwho:

actinide.who > Broadcasting.who: udp 84

意味は: アクチニド ホスト上の誰が udp パケットをブロードキャスト ホスト上のポートに送信したポート (nt: アクチニドとブロードキャストは両方ともインターネット アドレスを指します)。

このパケットはユーザー データを伝送します。

一部の UDP サービスは、パケットの送信元ポートまたは宛先ポート、または表示される上位層プロトコル情報から識別できます。たとえば、ドメイン名サービス リクエスト (DNS リクエスト、RFC-1034/1035 の

) 、および NFS への Sun RPC 呼び出し (NFS サーバー (nt: Sun RPC) に対して開始されるリモート呼び出し、リモート呼び出しについては RFC-1050 で説明されています)。

UDP ネーム サービス リクエスト

(注) : 以下の説明は、ドメイン サービス プロトコル (nt: RFC-103 で説明) に精通していることを前提としています。そうでない場合は、次の説明が聖書であることがわかります (nt: ギリシャ語聖書、

には注意しないでください)怖い場合は読み続けてください))

ネーム サービス リクエストの形式は次のとおりです:

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 を介して渡されます。 packet 送信されたクエリリクエスト

のデータ長は37バイトで、UDPプロトコルやIPプロトコルのヘッダデータは含まれませんが、このクエリ動作はデフォルト値(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 の論理積を表します。

UDP ネーム サービスの応答

name service データ パケットの場合、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)

最初の行は、h2opolo によって送信されたクエリ要求 No. 3 に、helios が 3 つのアンサー レコード (nt | rt: アンサー レコード)、3 つのネーム サーバー レコード、

、および 7 つの追加レコードで応答したことを示します。 (nt: 3 つのアンサー レコードの最初) タイプは A (nt: アドレスを表す) で、そのデータはインターネット アドレス 128.32.137.3.

です。この応答 UDP パケットには 273 バイトのデータが含まれています (UPD および IP ヘッダー データを除く) op フィールドと rcode フィールドは無視されます (nt: op の実際の値は Query、rcode、つまり
応答コードの実際の値は NoError です)、同様に無視されるフィールドはクラス フィールド (nt) | rt: その値は C_IN で、これはタイプ A レコードのデフォルト値でもあります)

2 行目は、h2opolo が送信したクエリリクエスト No.2 に対して helios が応答したことを示しています。応答では、rcode が NXDomain (nt: 存在しないドメインを示す)) としてエンコードされており、アンサーレコードはありません
ただし、権限サーバー レコードを除くネーム サーバー レコードが含まれています (nt | ck: 上記から、ここでの権限レコードは、上記の追加の
レコードに対応します)。「*」は、権限サーバーの応答フラグが設定されていることを示します ( nt: したがって、追加のレコードは権限レコードを表します)。
回答レコードがないため、タイプ、クラス、およびデータ フィールドは無視されます。

フラグ フィールドには、次のような他の文字も含まれる場合があります。 '-'( nt: 再帰クエリを示します。つまり、RA フラグが設定されていません)、'|'(nt: 切り捨てられたメッセージを示します。つまり、TC フラグ
が設定されています)。 nt | ct: ネーム サービスの応答を含む UDP パケットとして理解できます。tcpdump はこのタイプのパケットのデータを解析する方法を知っています)' 'question' セクションにはエントリ
が含まれていません (nt: 各エントリの意味, を追加する必要があります)、'[nq]' が出力されます。

ネームサーバーのリクエストおよびレスポンスのデータ量は比較的大きく、デフォルトのキャプチャ長は 68 バイトであることに注意してください ( nt: snaplen、理解できます (tcpdump の設定オプションでは、
パケットの内容全体をキャプチャするには十分ではない可能性があります。ネームサーバーの負荷を詳しく調べる必要がある場合は、tcpdump の -s を使用して snaplen 値を展開できます) option.

SMB/CIFS デコード

tcpdump は、SMB/CIFS/NBT 関連アプリケーションのパケットの内容をすでにデコードできます (nt: それぞれ ' Server Message Block Common '、'Internet File System'
'NETBIOS の略で、TCP/IP 上に実装されたネットワーク プロトコル'。これらのサービスは通常、UDP ポート 137/138 と TCP ポート 139 を使用します。IPX およびNetBEUI SMB データ パケットの
デコード機能は引き続き使用できます (注: NetBEUI は NETBIOS の拡張バージョンです)。

tcpdump は、必要に応じて、デフォルトで最も単純なモードで対応するデータ パケットのみをデコードします。詳細なデコード 情報は -v 起動オプションを使用して表示できます。-v は非常に詳細な情報を生成することに注意してください。
たとえば、単一の SMB パケットの場合、1 画面以上の情報が生成されるため、これはオプション、必要な場合にのみ使用してください。

SMB パケット形式と各フィールドの意味については、www.cifs.org または samba.org の pub/samba/specs/ ディレクトリを参照してください。ミラー サイト Linux の場合 Andrew Tridgell (tridge@samba.org) によって提供された SMB パッチ
(nt | rt: patch)

NFS リクエストとレスポンス

Sun NFS の tcpdump (ネットワーク ファイル システム) 要求および応答の UDP パケットは次の形式で出力されます:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: Reply stat len演算結果

以下は特定の出力データのセットです
ushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs >ushi.6709: Reply ok 40 readlink "../ var"
ushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs >ushi.201b:
Reply ok 128 lookup fh 9, 74/4134.3150

出力の最初の行は次のようになります: ホストの寿司が「交換リクエスト」(nt: トランザクション) をホスト wrl に送信しました。このリクエストの ID は 6709 (ホスト名の後には、exchange
送信元ポート番号ではなくリクエスト ID 番号が続くことに注意してください。このリクエスト データは 112 バイトであり、UDP ヘッダーと IP ヘッダーの長さは含まれません。操作タイプは readlink (nt: thatつまり、この操作は読み取りシンボリック リンク操作です)、
操作パラメーターは fh 21,24/10.73165 (nt: 実際の操作環境に応じて次のように解析できます。fd は記述がファイル ハンドルであることを意味します) 、21、24 は、このハンドルに対応するデバイスのマスター/スレーブ デバイス番号ペアを意味します。10 は、このハンドルに対応する i ノード番号を表します (nt: 各ファイルはオペレーティング システムの i ノードに対応します。 unix 系システム)、
73165 は数字です (nt: このリクエストを識別するものとして理解できます。乱数、特定の意味を追加する必要があります))。

2 行目で、wrl が応答しました。 'ok' で、sushi が読み取りたいシンボリック リンクの実際のディレクトリを結果フィールドに返します (nt : つまり、sushi が読み取る必要があるシンボリック リンクは実際にはディレクトリです)。 3 行目は、「fh 9,74/4096.6878」で記述されたディレクトリ内の「xcolors」ファイルを見つけるために、寿司が wrl を再度要求することを示しています。必須 各行に表示されるデータの意味は、ファイルの

タイプによって異なることに注意してください。 opフィールド(nt:異なるopsに対応する引数の意味が異なります)であり、その形式はNFSプロトコルに準拠し、簡潔さと明瞭さを追求しています。

tcpdumpの-vオプション(冗長出力オプション)が設定されている場合例:
ushi.1372a > wrl.nfs:

148 read fh 21,11/12.195 8192 bytes @ 24576

wrl.nfs >ushi.1372a:
返信 ok 1472 読み取り REG 100664 ids 417/0 sz 29388

(-v オプションは通常、IP ヘッダーの TTL、ID、長さ、および断片化フィールドも出力しますが、この例ではすべて省略されています (nt: は、簡潔にするために削除されたものと理解できます) ))
最初の行では、sushi はファイル 21,11/12.195 (nt: 形式は上記で説明) からオフセット 24576 バイトから始まる 8192 バイトのデータを読み取るように wrl を要求します。
Wrl 応答は正常に読み取られました。 2 行目は応答要求の開始フラグメントにすぎないため、1472 バイトのみが含まれます (他のデータは後続の応答フラグメントに含まれますが、これらのパケットには NFS
ヘッダーがなくなり、UDP ヘッダー情報も空になります) (nt: ソースと宛先が存在する必要があります)、これにより、これらのフラグメントはフィルター条件を満たさないため、印刷されません) ファイル データ情報の表示に加えて、-v オプションは、
追加の表示ファイルも表示します。属性情報: ファイルタイプ (ファイルタイプ、「REG」は通常のファイルを意味します)、ファイルモード (ファイルアクセスモード、8 進表記)、uid と gid (nt: ファイル所有者と
グループ所有者)、ファイルサイズ (ファイルsize).

-v フラグが複数回指定された場合 (nt: -vv など)、tcpdump はより詳細な情報を表示します。

必須 多くの情報があることに注意してください。 tcpdump の snaplen (nt:キャプチャ長) が短すぎる場合、詳細情報が表示されません。
'-s 192' を使用して snaplen を増やすことができます。 NFS アプリケーションのネットワーク負荷 (nt: トラフィック) を監視するために使用されます。

NFS 応答パケットは、以前の対応する要求パケット (nt: RPC 操作) に厳密に従っていません。そのため、tcpdump は、最後に受信した A一連のリクエスト パケットを受信し、その
交換シーケンス番号 (nt: トランザクション ID) を介して対応するリクエスト パケットと照合します。これにより、応答パケットが遅すぎて、対応するリクエストの追跡範囲を超えた場合に問題が発生する可能性があります。 packet by tcpdump,
この応答パケットは分析されません。

#AFS 要求と応答

AFS(nt: Andrew File System, Transarc、不明、追加必要) リクエストとレスポンスには次のプロトコルがあります

src.sport > dst.dport: rx packet-type

src.sport > dst.dport: rx packet -type サービス呼び出し call-name args
src.sport > dst.dport: rx packet-type サービス応答 call-name args

elvis.7001 > pike.afsfs:

rx data fs 呼び出し rename 古い fid 536876964/ 1/1 ".newsrc.new"
新しい fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs Reply rename

最初の行では、ホスト elvis が RX データ パケットを pike に送信しました。

これはファイル サービスの要求パケットです (nt: RX データ パケット、データ パケットの送信は、要求するパケットの送信と理解できます)
元のディレクトリ記述子は 536876964 /1/1、元のファイル名は '.newsrc.new'、新しいディレクトリ記述子は 536876964/1/1、新しいファイル名は '.newsrc' です。
ホスト pike は、この名前変更操作に対して RPC 要求を作成しました。応答 (応答は、例外パケットではなくデータ コンテンツを含むパケットであるため、名前変更操作が成功したことを示します)。

一般的に言えば、すべての ' AFS RPC 要求には、表示時に名前が付けられます (nt: decode, decode)。この名前は、多くの場合、RPC 要求の操作名です。

さらに、これらの RPC 要求の一部のパラメーターにも名前が付けられます。表示されるとき (nt | rt: decode, decode 、一般的に言えば、名前付けも非常に簡単です。たとえば、

興味深いパラメータは、直接「interesting」と表示されます。意味は発音が難しく、再翻訳する必要があります).

この表示形式は、「一目で理解できる」ことを本来の目的としていますが、AFS や RX の動作原理に詳しくない人にとってはあまり役に立たないかもしれません。 (nt: 心配しないでください。文章で書くと怖くなるので、読み続けてください)。

-v (冗長) フラグが繰り返し指定された場合 (nt: -vv など)、tcpdump は確認パケット（nt：応答パケットとは別のパケットとして理解できます）と追加ヘッダ情報
（nt：確認パケットの追加ヘッダ情報だけでなく、すべてのパケットとして理解できます）を出力します。例: RX コール ID (リクエスト パケット内の「リクエスト コール」の ID)、

コール番号 (「リクエスト コール」番号)、シーケンス番号 (nt: パケット シーケンス番号)、

シリアル番号(nt | rt: パケット内のデータに関連する別のシリアル信号と理解できます。具体的な意味は補足する必要があります)、パケットの識別を要求します。(nt: 次の段落は繰り返しの説明なので、
は省略します) )、さらに、確認パケット内の MTU ネゴシエーション情報も出力されます (nt: 確認パケットは、要求パケットに対する確認パケット、最大送信単位、最大送信単位)。 -v オプションを 3 回繰り返すと (nt: -vvv など)、「セキュリティ インデックス」 (「セキュリティ インデックス」) と「サービス インデックス」 (「サービス ID」) が出力されます。

異常なデータ パケット (nt: アボート パケット。このパケットは例外が発生したことを受信者に通知するために使用されると理解できます) の場合、tcpdump はエラー コードを出力します。
ただし、Ubik ビーコン パケットの場合は ( nt: Ubik ビーコン表示パケット、Ubik は特別な通信プロトコルとして理解できます。ビーコン パケット、灯台データ パケットは、通信における
キー情報を示す一部のデータ パケットとして理解できます)、エラー番号は出力されません。 Ubik プロトコルの場合、異常なデータ パケットはエラーを示すのではなく、肯定的な応答 (nt: つまり、賛成票) を示します。

AFS は大量のデータを要求し、多くのパラメーターがあるため、 tcpdump が必要です snaplen は比較的大きいです。通常、tcpdump を開始するときにオプション '-s 256' を設定して、AFS アプリケーションの通信負荷を
監視することで snaplen を増やすことができます。

AFS 応答パケットは表示されませんRPC を識別するリモートのタイプ 呼び出し したがって、tcpdump は最近の期間の要求パケットを追跡し、呼び出し番号 (呼び出し番号) とサービス ID
(サービス インデックス) を通じて受信した応答パケットを照合します。パケットは最近の期間の要求パケット用ではないため、tcpdump はパケットを解析できません。

KIP AppleTalk プロトコル

(nt | rt: UDP の DDP は、DDP、AppleTalk データ配信プロトコル、
は KIP AppleTalk プロトコル スタックをサポートするネットワーク層プロトコルに相当し、DDP 自体は UDP を通じて送信され、
はネットワークであると理解できます。他のネットワーク用に UDP 上に実装された層、KIP AppleTalk は、Apple によって開発されたネットワーク プロトコル スタックの完全なセットです)。

AppleTalk DDP パケットは UDP パケットにカプセル化され、そのカプセル化解除 (nt: デコードに相当) と、対応する情報のダンプも DDP パケット ルールに従います。
(nt:encapsulate、カプセル化、エンコードと同等、カプセル化解除、カプセル化解除、デコードと同等、ダンプ、ダンプ、通常はその情報の出力を指します)。

/etc/atalk.names ファイルには、AppleTalk ネットワークおよびノー​​ドの数値識別子と名前の間の対応関係が含まれています。ファイル形式は通常次のようになります:
番号名

1.254 ether
16.1 icsd- net
1.254.110 ace

最初の 2 行は、AppleTalk ネットワークが 2 つあることを示し、3 行目は特定のネットワーク上のホストを示します (ホストは 3 バイトで識別されます
ネットワークの識別子は通常 2 バイトしかありません。これが 2 つの識別子の主な違いでもあります) (nt: 1.254.110 はイーサ ネットワーク上のエース ホストとして理解できます)。
ギャップが必要です。識別子とそれに対応する名前の間は空白で区切ります。上記の内容に加えて、/etc/atalk.names には空白行とコメント行 ('#' で始まる行) も含まれます。

AppleTalk の完全なネットワーク アドレス次の形式で表示されます:
net.host.port

以下は具体的な表示です:
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

(/etc/atalk.names ファイルが存在しない場合、または対応する AppleTalk ホスト/ネットワークのエントリがない場合

最初の行では、ネットワーク 144.1 上のノード 209 が、ポート 2 を介して icsd-net をリッスンしているネットワーク上のノード 112 に NBP アプリケーション パケットを送信します。ポート 220
(nt | rt: NBP、名前バインディング プロトコル、名前バインディング プロトコル。データの観点から見ると、NBP サーバーはこのサービスをポート 2 で提供します。
「DDP ポート 2」は次のように理解できます。 「DDP 対応トランスポート層ポート 2」、DDP 自体には port の概念がありません。この点は未確定なので補足する必要があります)。

2 行目は 1 行目と似ていますが、すべてのアドレスが異なる点が異なります。送信元は「office」で識別できます。
3 行目は次のことを示しています: jssmag ネットワーク上の 149 ノードは 235 を介して icsd-net ネットワーク上のすべてのノードのポート 2 (NBP ポート) にデータ パケットを送信しました。
AppleTalk ネットワークでは、アドレスにノードがない場合はブロードキャスト アドレスを意味するため、/etc/atalk.names.# 内のノード識別子とネットワーク識別子を区別するのが最善です。 ## nt: それ以外の場合、識別子 x.port の場合、x がネットワーク上のすべてのホストのポートを参照しているのか、または指定されたホストのポートを参照しているのかを判断することはできません x).

tcpdump は NBP を解析できます(Name Binding Protocol) および 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 を介してネットワーク内のすべてのノードのポート 2 に「LaserWriter」の名前を送信しました。 jssmag クエリ要求 (nt :

ここでの名前は、プリンターなどのリソースの名前として理解できます。このクエリ リクエストのシーケンス番号は 190.
です。

2 行目は次のことを示しています: ネットワーク jssmag のノード 209 が、ポート 2 を介して icsd-net.112 ノードのポート 220 に応答しました: 「LaserWriter」リソースがあり、そのリソース名
は「RM1140」です。ポート 250 でリソース変更サービスを提供します。この応答のシーケンス番号は 190 で、前にクエリされたシーケンス番号に対応します。

3 行目は、1 行目の要求に対する応答でもあります: Node techpitポート 2 経由で icsd を要求 -net.112 ノードのポート 220 が応答しました: 「LaserWriter」リソースがあり、そのリソース名
は「techpit」で、リソース変更サービスはポート 186 で提供されます。 シーケンス番号この応答の 190 は、以前に照会されたシーケンス番号に対応します。

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 > p- 応答 12266: 2 (512) 0xae040000
helios.132 & gt; jssmag.209.165: 応答 12266: 3 (512) 0xae04000000

stelos.132 & GT; JSSMAG.209.165: ATP-Resp 12 266: 5 (512 ) 0xae040000
helios.132 & gt; jssmag.209.165 : ATP-Resp 12266: 6 (512) 0xae040040000
helios.132 & gt; jssmag.209.165: ATP-Resp*12266: 7 (512) 0x 0X ae040000
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> 0xae030 002

最初の行は、ノード Jssmag.209 がセッション番号 12266 の要求パケットをノード helios に送信し、helios
に 8 つのデータ パケット (これら 8 つのデータ パケットのシーケンス番号は 0 ～ 7) で応答するよう要求したことを示しています。 (nt: シーケンス番号はセッション番号とは異なります。後者は完全な送信の番号です。

前者は送信内の各データ パケットの番号です。トランザクション、セッションは通常、送信とも呼ばれます) ). 行末の 16 進数は、リクエスト パケットの「userdata」フィールドの値を表します (nt: 以下から、これはすべてのユーザー データを出力するわけではありません)。

Helios が応答しました。 8 つの 512 バイト データ パケットを含むセッション番号 (nt: 12266) に続く数字は、セッション内のデータ パケットのシーケンス番号を示します。
カッコ内の数字は、データ パケットのシーケンス番号を示します。 atp ヘッダーを含まないデータ。シーケンス番号 7 のパケットの外側に '*' 記号 (8 行目) があり、

はパケットの EOM フラグが設定されていることを示します。(nt: EOM, Endメディアの、セッションのデータ応答が完了したことを示すものとして理解できます)

次の行 9 は、Jssmag.209 が helios に別のリクエストを行ったことを示します: シーケンス番号 3 と 5 データ パケットを再送信してください.Helios は、この リクエストを受信した後、2 つのデータ パケットを再送信しました。jssmag.209 がこれら 2 つのデータ パケットを再度受信した後、セッションをアクティブに終了 (解放) しました。最後の行で、jssmag.209 は、 helios への次のセッションを開始するためのリクエスト パケット。リクエスト パケット内の '*' は、パケットの XO フラグが設定されていないことを示します。

(nt: XO、正確に 1 回、この中で理解されますセッションでは、データ パケットは受信側で 1 回だけ処理されます。相手がデータ パケットを繰り返し送信したとしても、

受信側は 1 回だけ処理します。これには、特別に設計されたデータ パケットの受信と処理の使用が必要です。

#IP パケットのフラグメンテーション

(nt: IP パケットを複数の IP パケットに分割することを指します)

フラグメント化された IP データ パケット (nt: 大きな IP データ パケットが分割された後に生成される小さな IP データ パケット) には、次の 2 つの表示形式があります。

(frag id:size@offset)### (frag id:size@offset) ### (最初の形式は、このフラグメントの後に後続のフラグメントがあることを示します。2 番目の形式は、このフラグメントが最後のフラグメントであることを示します。)######id ​​はフラグメント番号を表します (nt : 以下に示すように、それぞれの大きいフラグメント化される IP パケットには、それぞれの小さなフラグメントが同じデータ パケットからフラグメント化されているかどうかを区別するために、フラグメンテーション番号が割り当てられます。### サイズは、フラグメントのヘッダー データを除いた、このフラグメントのサイズを示します。オフセットは、ヘッダー データのオフセットを表します。元の IP パケット全体のこのフラグメントに含まれるデータ ((nt: 次の観点から、 ### IP データ パケットは、データだけが分割されるわけではなく、ヘッダーとデータを含む全体としてフラグメント化されます)。# ##

每个碎片都会使tcpdump产生相应的输出打印. 第一个碎片包含了高层协议的头数据(nt:从下文来看, 被破碎IP数据包中相应tcp头以及
IP头都放在了第一个碎片中 ), 从而tcpdump会针对第一个碎片显示这些信息, 并接着显示此碎片本身的信息. 其后的一些碎片并不包含高层协议头信息, 从而只会在显示源和目的之后显示碎片本身的信息. 以下有一个例子: 这是一个从arizona.edu 到lbl-rtsg.arpa途经CSNET网络(nt: CSNET connection 可理解为建立在CSNET 网络上的连接)的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: . ack 1536 win 2560

有几点值得注意:
第一, 第二行的打印中, 地址后面没有端口号.
这是因为TCP协议信息都放到了第一个碎片中, 当显示第二个碎片时, 我们无法知道此碎片所对应TCP包的顺序号.

第二, 从第一行的信息中, 可以发现arizona需要向rtsg发送308字节的用户数据, 而事实是, 相应IP包经破碎后会总共产生512字节
数据(第一个碎片包含308字节的数据, 第二个碎片包含204个字节的数据, 这超过了308字节). 如果你在查找数据包的顺序号空间中的
一些空洞(nt: hole,空洞, 指数据包之间的顺序号没有上下衔接上), 512这个数据就足够使你迷茫一阵(nt: 其实只要关注308就行,
不必关注破碎后的数据总量).

一个数据包(nt | rt: 指IP数据包)如果带有非IP破碎标志, 则显示时会在最后显示'(DF)'.(nt: 意味着此IP包没有被破碎过).

时间戳

tcpdump的所有输出打印行中都会默认包含时间戳信息.
时间戳信息的显示格式如下
hh:mm:ss.frac　(nt: 小时:分钟:秒.(nt: frac未知, 需补充))
此时间戳的精度与内核时间精度一致,　反映的是内核第一次看到对应数据包的时间(nt: saw, 即可对该数据包进行操作).　
而数据包从物理线路传递到内核的时间, 以及内核花费在此包上的中断处理时间都没有算进来.

命令使用

tcpdump采用命令行方式，它的命令格式为：

tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
           [ -C file_size ] [ -F file ]
           [ -i  ] [ -m module ] [ -M secret ]
           [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
           [ -W filecount ]
           [ -E spi@ipaddr algo:secret,...  ]
           [ -y datalinktype ] [ -Z user ]
           [ expression ]

tcpdump的简单选项介绍

-A  以ASCII码方式显示每一个数据包(不会显示数据包中链路层头部信息). 在抓取包含网页数据的数据包时, 可方便查看数据(nt: 即Handy  capturing web pages).

-c  count
    tcpdump将在接受到count个数据包后退出.

-C  file-size (nt: 此选项用于配合-w file 选项使用)
    该选项使得tcpdump 在把原始数据包直接保存到文件中之前, 检查此文件大小是否超过file-size. 如果超过了, 将关闭此文件,另创一个文件继续用于原始数据包的记录. 新创建的文件名与-w 选项指定的文件名一致, 但文件名后多了一个数字.该数字会从1开始随着新创建文件的增多而增加. file-size的单位是百万字节(nt: 这里指1,,000个字节,并非1,,576个字节, 后者是以1024字节为1k, 1024k字节为1M计算所得, 即1M= ＊  ＝ ,,)

-d  以容易阅读的形式,在标准输出上打印出编排过的包匹配码, 随后tcpdump停止.(nt | rt: human readable, 容易阅读的,通常是指以ascii码来打印一些信息. compiled, 编排过的. packet-matching code, 包匹配码,含义未知, 需补充)

-dd 以C语言的形式打印出包匹配码.

-ddd 以十进制数的形式打印出包匹配码(会在包匹配码之前有一个附加的前缀).

-D  打印系统中所有tcpdump可以在其上进行抓包的网络接口. 每一个接口会打印出数字编号, 相应的接口名字, 以及可能的一个网络接口描述. 其中网络接口名字和数字编号可以用在tcpdump 的-i flag 选项(nt: 把名字或数字代替flag), 来指定要在其上抓包的网络接口.

    此选项在不支持接口列表命令的系统上很有用(nt: 比如, Windows 系统, 或缺乏 ifconfig -a 的UNIX系统); 接口的数字编号在windows  或其后的系统中很有用, 因为这些系统上的接口名字比较复杂, 而不易使用.

    如果tcpdump编译时所依赖的libpcap库太老,-D 选项不会被支持, 因为其中缺乏 pcap_findalldevs()函数.

-e  每行的打印输出中将包括数据包的数据链路层头部信息

-E  spi@ipaddr algo:secret,...

    可通过spi@ipaddr algo:secret 来解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,IPsec 封装安全负载, IPsec可理解为, 一整套对ip数据包的加密协议, ESP 为整个IP 数据包或其中上层协议部分被加密后的数据,前者的工作模式称为隧道模式; 后者的工作模式称为传输模式 . 工作原理, 另需补充).

    需要注意的是, 在终端启动tcpdump 时, 可以为IPv4 ESP packets 设置密钥(secret）.

    可用于加密的算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者没有(none).默认的是des-cbc(nt: des, Data Encryption Standard, 数据加密标准, 加密算法未知, 另需补充).secret 为用于ESP 的密钥, 使用ASCII 字符串方式表达. 如果以 0x 开头, 该密钥将以16进制方式读入.

    该选项中ESP 的定义遵循RFC2406, 而不是 RFC1827. 并且, 此选项只是用来调试的, 不推荐以真实密钥(secret)来使用该选项, 因为这样不安全: 在命令行中输入的secret 可以被其他人通过ps 等命令查看到.

    除了以上的语法格式(nt: 指spi@ipaddr algo:secret), 还可以在后面添加一个语法输入文件名字供tcpdump 使用(nt：即把spi@ipaddr algo:secret,... 中...换成一个语法文件名). 此文件在接受到第一个ESP　包时会打开此文件, 所以最好此时把赋予tcpdump 的一些特权取消(nt: 可理解为, 这样防范之后, 当该文件为恶意编写时,不至于造成过大损害).

-f  显示外部的IPv4 地址时(nt: foreign IPv4 addresses, 可理解为, 非本机ip地址), 采用数字方式而不是名字.(此选项是用来对付Sun公司的NIS服务器的缺陷(nt: NIS, 网络信息服务, tcpdump 显示外部地址的名字时会用到她提供的名称服务): 此NIS服务器在查询非本地地址名字时,常常会陷入无尽的查询循环).

    由于对外部(foreign)IPv4地址的测试需要用到本地网络接口(nt: tcpdump 抓包时用到的接口)及其IPv4 地址和网络掩码. 如果此地址或网络掩码不可用, 或者此接口根本就没有设置相应网络地址和网络掩码(nt: linux 下的  网络接口就不需要设置地址和掩码, 不过此接口可以收到系统中所有接口的数据包), 该选项不能正常工作.

-F  file
    使用file 文件作为过滤条件表达式的输入, 此时命令行上的输入将被忽略.

-i  

    指定tcpdump 需要监听的接口.  如果没有指定, tcpdump 会从系统接口列表中搜寻编号最小的已配置好的接口(不包括 loopback 接口).一但找到第一个符合条件的接口, 搜寻马上结束.

    在采用2.2版本或之后版本内核的Linux 操作系统上,  这个虚拟网络接口可被用来接收所有网络接口上的数据包(nt: 这会包括目的是该网络接口的, 也包括目的不是该网络接口的). 需要注意的是如果真实网络接口不能工作在模式(promiscuous)下,则无法在这个虚拟的网络接口上抓取其数据包.

    如果 -D 标志被指定, tcpdump会打印系统中的接口编号，而该编号就可用于此处的interface 参数.

-l  对标准输出进行行缓冲(nt: 使标准输出设备遇到一个换行符就马上把这行的内容打印出来).在需要同时观察抓包打印以及保存抓包记录的时候很有用. 比如, 可通过以下命令组合来达到此目的:
    ``tcpdump  -l  |  tee dat 或者 ``tcpdump  -l   > dat  &  tail  -f  dat.(nt: 前者使用tee来把tcpdump 的输出同时放到文件dat和标准输出中, 而后者通过重定向操作, 把tcpdump的输出放到dat 文件中, 同时通过tail把dat文件中的内容放到标准输出中)

-L  列出指定网络接口所支持的数据链路层的类型后退出.(nt: 指定接口通过-i 来指定)

-m  module
    通过module 指定的file 装载SMI MIB 模块(nt: SMI，Structure of Management Information, 管理信息结构MIB, Management Information Base, 管理信息库. 可理解为, 这两者用于SNMP(Simple Network Management Protoco)协议数据包的抓取. 具体SNMP 的工作原理未知, 另需补充).

    此选项可多次使用, 从而为tcpdump 装载不同的MIB 模块.

-M  secret  如果TCP 数据包(TCP segments)有TCP-MD5选项(在RFC 2385有相关描述), 则为其摘要的验证指定一个公共的密钥secret.

-n  不对地址(比如, 主机地址, 端口号)进行数字表示到名字表示的转换.

-N  不打印出host 的域名部分. 比如, 如果设置了此选现, tcpdump 将会打印 而不是 .

-O  不启用进行包匹配时所用的优化代码. 当怀疑某些bug是由优化代码引起的, 此选项将很有用.

-p  一般情况下, 把网络接口设置为非模式. 但必须注意 , 在特殊情况下此网络接口还是会以模式来工作； 从而,  的设与不设, 不能当做以下选现的代名词: 或  (nt: 前者表示只匹配以太网地址为host 的包, 后者表示匹配以太网地址为广播地址的数据包).

-q  快速(也许用更好?)打印输出. 即打印很少的协议相关信息, 从而输出行都比较简短.

-R  设定tcpdump 对 ESP/AH 数据包的解析按照 RFC1825而不是RFC1829(nt: AH, 认证头, ESP， 安全负载封装, 这两者会用在IP包的安全传输机制中). 如果此选项被设置, tcpdump 将不会打印出域(nt: relay prevention field). 另外,由于ESP/AH规范中没有规定ESP/AH数据包必须拥有协议版本号域,所以tcpdump不能从收到的ESP/AH数据包中推导出协议版本号.

-r  file
    从文件file 中读取包数据. 如果file 字段为  符号, 则tcpdump 会从标准输入中读取包数据.

-S  打印TCP 数据包的顺序号时, 使用绝对的顺序号, 而不是相对的顺序号.(nt: 相对顺序号可理解为, 相对第一个TCP 包顺序号的差距,比如, 接受方收到第一个数据包的绝对顺序号为232323, 对于后来接收到的第2个,第3个数据包, tcpdump会打印其序列号为1, 2分别表示与第一个数据包的差距为1 和 . 而如果此时-S 选项被设置, 对于后来接收到的第2个, 第3个数据包会打印出其绝对顺序号:, ).

-s  snaplen
    设置tcpdump的数据包抓取长度为snaplen, 如果不设置默认将会是68字节(而支持网络接口分接头(nt: NIT, 上文已有描述,可搜索关键字找到那里)的SunOS系列操作系统中默认的也是最小值是96).68字节对于IP, ICMP(nt: Internet Control Message Protocol,因特网控制报文协议), TCP 以及 UDP 协议的报文已足够, 但对于名称服务(nt: 可理解为dns, nis等服务), NFS服务相关的数据包会产生包截短. 如果产生包截短这种情况, tcpdump的相应打印输出行中会出现[|proto]的标志（proto 实际会显示为被截短的数据包的相关协议层次). 需要注意的是, 采用长的抓取长度(nt: snaplen比较大), 会增加包的处理时间, 并且会减少tcpdump 可缓存的数据包的数量， 从而会导致数据包的丢失. 所以, 在能抓取我们想要的包的前提下, 抓取长度越小越好.把snaplen 设置为0 意味着让tcpdump自动选择合适的长度来抓取数据包.

-T  type
    强制tcpdump按type指定的协议所描述的包结构来分析收到的数据包.  目前已知的type 可取的协议为:
    aodv (Ad-hoc On-demand Distance Vector protocol, 按需距离向量路由协议, 在Ad hoc(点对点模式)网络中使用),
    cnfp (Cisco  NetFlow  protocol),  rpc(Remote Procedure Call), rtp (Real-Time Applications protocol),
    rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol),
    tftp (Trivial File Transfer Protocol, 碎文件协议), vat (Visual Audio Tool, 可用于在internet 上进行电
    视电话会议的应用层协议), 以及wb (distributed White Board, 可用于网络会议的应用层协议).

-t     在每行输出中不打印时间戳

-tt    不对每行输出的时间进行格式处理(nt: 这种格式一眼可能看不出其含义, 如时间戳打印成1261798315)

-ttt   tcpdump 输出时, 每两行打印之间会延迟一个段时间(以毫秒为单位)

-tttt  在每行打印的时间戳之前添加日期的打印

-u     打印出未加密的NFS 句柄(nt: handle可理解为NFS 中使用的文件句柄, 这将包括文件夹和文件夹中的文件)

-U    使得当tcpdump在使用-w 选项时, 其文件写入与包的保存同步.(nt: 即, 当每个数据包被保存时, 它将及时被写入文件中,而不是等文件的输出缓冲已满时才真正写入此文件)

      -U 标志在老版本的libcap库(nt: tcpdump 所依赖的报文捕获库)上不起作用, 因为其中缺乏pcap_cump_flush()函数.

-v    当分析和打印的时候, 产生详细的输出. 比如, 包的生存时间, 标识, 总长度以及IP包的一些选项. 这也会打开一些附加的包完整性检测, 比如对IP或ICMP包头部的校验和.

-vv   产生比-v更详细的输出. 比如, NFS回应包中的附加域将会被打印, SMB数据包也会被完全解码.

-vvv  产生比-vv更详细的输出. 比如, telent 时所使用的SB, SE 选项将会被打印, 如果telnet同时使用的是图形界面,
      其相应的图形选项将会以16进制的方式打印出来(nt: telnet 的SB,SE选项含义未知, 另需补充).

-w    把包数据直接写入文件而不进行分析和打印输出. 这些包数据可在随后通过-r 选项来重新读入并进行分析和打印.

-W    filecount
      此选项与-C 选项配合使用, 这将限制可打开的文件数目, 并且当文件数据超过这里设置的限制时, 依次循环替代之前的文件, 这相当于一个拥有filecount 个文件的文件缓冲池. 同时, 该选项会使得每个文件名的开头会出现足够多并用来占位的0, 这可以方便这些文件被正确的排序.

-x    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据(但不包括连接层的头部).总共打印的数据大小不会超过整个数据包的大小与snaplen 中的最小值. 必须要注意的是, 如果高层协议数据没有snaplen 这么长,并且数据链路层(比如, Ethernet层)有填充数据, 则这些填充数据也会被打印.(nt: so  link  layers  that pad, 未能衔接理解和翻译, 需补充 )

-xx   tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据, 其中包括数据链路层的头部.

-X    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据(但不包括连接层的头部).这对于分析一些新协议的数据包很方便.

-XX   当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据, 其中包括数据链路层的头部.这对于分析一些新协议的数据包很方便.

-y    datalinktype
      设置tcpdump 只捕获数据链路层协议类型是datalinktype的数据包

-Z    user
      使tcpdump 放弃自己的超级权限(如果以root用户启动tcpdump, tcpdump将会有超级用户权限), 并把当前tcpdump的用户ID设置为user, 组ID设置为user首要所属组的ID(nt: tcpdump 此处可理解为tcpdump 运行之后对应的进程)

      此选项也可在编译的时候被设置为默认打开.(nt: 此时user 的取值未知, 需补充)

tcpdump条件表达式

  该表达式用于决定哪些数据包将被打印. 如果不给定条件表达式, 网络上所有被捕获的包都会被打印,否则, 只有满足条件表达式的数据包被打印.(nt: all packets, 可理解为, 所有被指定接口捕获的数据包).

  表达式由一个或多个'表达元'组成(nt: primitive, 表达元, 可理解为组成表达式的基本元素). 一个表达元通常由一个或多个修饰符(qualifiers)后跟一个名字或数字表示的id组成(nt: 即, 'qualifiers id').有三种不同类型的修饰符:type, dir以及 proto.

type 修饰符指定id 所代表的对象类型, id可以是名字也可以是数字. 可选的对象类型有: host, net, port 以及portrange(nt: host 表明id表示主机, net 表明id是网络, port 表明id是端而portrange 表明id 是一个端口范围).  如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分别表示主机 foo,网络 128.3, 端口 20, 端口范围 6000-6008). 如果不指定type 修饰符, id默认的修饰符为host.

dir 修饰符描述id 所对应的传输方向, 即发往id 还是从id 接收（nt: 而id 到底指什么需要看其前面的type 修饰符）.可取的方向为: src, dst, src 或 dst, src并且dst.(nt:分别表示, id是传输源, id是传输目的, id是传输源或者传输目的, id是传输源并且是传输目的). 例如, 'src foo','dst net 128.3', 'src or dst port ftp-data'.(nt: 分别表示符合条件的数据包中, 源主机是foo, 目的网络是128.3, 源或目的端口为 ftp-data).如果不指定dir修饰符, id 默认的修饰符为src 或 dst.对于链路层的协议,比如SLIP(nt: Serial Line InternetProtocol, 串联线路网际网络协议), 以及linux下指定'any' 设备, 并指定'cooked'(nt | rt: cooked 含义未知, 需补充) 抓取类型, 或其他设备类型,可以用'inbound' 和 'outbount' 修饰符来指定想要的传输方向.

proto 修饰符描述id 所属的协议. 可选的协议有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp以及 upd.(nt | rt: ether, fddi, tr, 具体含义未知, 需补充. 可理解为物理以太网传输协议, 光纤分布数据网传输协议,以及用于路由跟踪的协议.  wlan, 无线局域网协议; ip,ip6 即通常的TCP/IP协议栈中所使用的ipv4以及ipv6网络层协议;arp, rarp 即地址解析协议,反向地址解析协议; decnet, Digital Equipment Corporation开发的, 最早用于PDP-11 机器互联的网络协议; tcp and udp, 即通常TCP/IP协议栈中的两个传输层协议).

    例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'分别表示 '从以太网地址foo 来的数据包','发往或来自128.3网络的arp协议数据包', '发送或接收端口为21的tcp协议数据包', '发送或接收端口范围为7000-7009的udp协议数据包'.

    如果不指定proto 修饰符, 则默认为与相应type匹配的修饰符. 例如, 'src foo' 含义是 '(ip or arp or rarp) src foo' (nt: 即, 来自主机foo的ip/arp/rarp协议数据包, 默认type为host),`net bar' 含义是`(ip  or  arp  or rarp) net bar'(nt: 即, 来自或发往bar网络的ip/arp/rarp协议数据包),`port 53' 含义是 `(tcp or udp) port 53'(nt: 即, 发送或接收端口为53的tcp/udp协议数据包).(nt: 由于tcpdump 直接通过数据链路层的 BSD 数据包过滤器或 DLPI(datalink provider interface, 数据链层提供者接口)来直接获得网络数据包, 其可抓取的数据包可涵盖上层的各种协议, 包括arp, rarp, icmp(因特网控制报文协议),ip, ip6, tcp, udp, sctp(流控制传输协议).

    对于修饰符后跟id 的格式,可理解为, type id 是对包最基本的过滤条件: 即对包相关的主机, 网络, 端口的限制;dir 表示对包的传送方向的限制; proto表示对包相关的协议限制)

    'fddi'(nt: Fiber Distributed Data Interface) 实际上与'ether' 含义一样: tcpdump 会把他们当作一种''指定网络接口上的数据链路层协议''. 如同ehter网(以太网), FDDI 的头部通常也会有源, 目的, 以及包类型, 从而可以像ether网数据包一样对这些域进行过滤. 此外, FDDI 头部还有其他的域, 但不能被放到表达式中用来过滤

    同样, 'tr' 和 'wlan' 也和 'ether' 含义一致, 上一段对fddi 的描述同样适用于tr(Token Ring) 和wlan(802.11 wireless LAN)的头部. 对于802.11 协议数据包的头部, 目的域称为DA, 源域称为 SA;而其中的 BSSID, RA, TA 域(nt | rt: 具体含义需补充)不会被检测(nt: 不能被用于包过虑表达式中).

  除以上所描述的表达元('primitive')， 还有其他形式的表达元, 并且与上述表达元格式不同. 比如: gateway, broadcast, less, greater以及算术表达式(nt: 其中每一个都算一种新的表达元). 下面将会对这些表达元进行说明.

  表达元之间还可以通过关键字and, or 以及 not 进行连接, 从而可组成比较复杂的条件表达式. 比如,`host foo and not port ftp and not port ftp-data'(nt: 其过滤条件可理解为, 数据包的主机为foo,并且端口不是ftp(端口21) 和ftp-data(端口20, 常用端口和名字的对应可在linux 系统中的/etc/service 文件中找到)).

  为了表示方便, 同样的修饰符可以被省略, 如'tcp dst port ftp or ftp-data or domain' 与以下的表达式含义相同'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.(nt: 其过滤条件可理解为,包的协议为tcp, 目的端口为ftp 或 ftp-data 或 domain(端口53) ).

  借助括号以及相应操作符,可把表达元组合在一起使用(由于括号是shell的特殊字符, 所以在shell脚本或终端中使用时必须对括号进行转义, 即'(' 与')'需要分别表达成'\(' 与 '\)').

  有效的操作符有:

 否定操作 (`!' 或 `not')
 与操作(`&&' 或 `and')
 或操作(`||' 或 `or')

  否定操作符的优先级别最高. 与操作和或操作优先级别相同, 并且二者的结合顺序是从左到右. 要注意的是, 表达'与操作'时,

前後の式要素を単に並べるのではなく、「and」演算子を明示的に記述する必要があります (nt: 2 つの間の「and」演算子は省略できません)。識別子が前にある場合 キーワードがない場合は、式の解析中に最後に使用されたキーワード (通常は左から右に識別子に最も近いキーワード) が使用されます。たとえば、

not host vs and ace

は、次の式の簡略化:
not host vs and host ace
not (host vs or ace) の代わりに。(nt: 最初の 2 つは、必要なデータ パケットがホスト vs から送信されたものではなく、ホスト vs に送信されたものではないことを示しますが、 from または ace に送信されます。後者は、データ パケットが vs または ac から送信されない限り、要件を満たしていることを意味します)

条件式全体は、別個の文字列パラメーターとして扱うことも、次のこともできます。スペースで区切る必要があります。複数のパラメータを tcpdump に渡す方が便利です。通常、式にメタ文字 (nt: 正規表現の '*'、'.'、シェルの '(' など) が含まれる場合、次のようにするのが最善です。別の文字列として渡します。このとき、式全体を一重引用符で囲む必要があります。複数のパラメータを渡す方法では、最終的にすべてのパラメータがスペースで連結され、文字列として解析されます。

付録: tcpdump の式要素(nt: 以下の説明では True を意味します。対応する条件式には次の内容のみが含まれます。列の特定の式要素、式が true、つまり条件が満たされた場合)

dst host host

IPv4/v6 パケットの宛先ドメインが host の場合、対応する条件式が true になります。 host は IP アドレスまたはホスト名です。

src host host
IPv4/v6 パケットの送信元ドメインが host の場合、対応する条件式は true です。
host は IP アドレスまたはホスト名です。ホスト名。
host host

IPv4/v6 パケットの送信元アドレスまたは宛先アドレスが host の場合、対応する条件式は true になります。次のキーワードを上記の host 式の前に追加できます。 ip、arp、rarp、および ip6。例:

ip host host

は次のように表すこともできます:
ether proto \ip and host host (nt: この式については以下で説明します。ここで、ip はip はすでに tcpdump のキーワードであるため、\ でエスケープする必要があります。)

host が IP アドレスを持つ複数のホストを持つホストの場合、パケットのマッチングには任意のアドレスが使用されます (nt: つまり、ホストに送信されるデータ パケットの宛先アドレスは、これらの IP のいずれかになります。また、ホストから受信されるデータ パケットの送信元アドレスも、これらの IP のいずれかになります)。

ether dst ehost

データ パケット (nt: ip データ パケット、tcp データ パケットなど、tcpdump がキャプチャできるデータ パケットを指します) イーサネットの場合、ターゲット アドレスが ehost の場合、対応する条件式は true です。ehost は、次の名前にすることができます。 /etc/ethers ファイルまたは数値アドレス (nt: このように、man ethers を通じて /etc/ethers ファイルの説明を確認できます。この例では数値アドレスを使用しています)

ether src ehost

データ パケットのイーサネット送信元アドレスが ehost の場合、対応する条件式は true です。

イーサ ホスト ehost

データ パケットのイーサネット送信元アドレスまたは宛先アドレスが ehost の場合、対応する条件式は式が true です。

ゲートウェイ ホスト

データ パケットのゲートウェイ アドレスがホストである場合、対応する条件式は true です。ここでのゲートウェイ アドレスは、イーサネット アドレスを指しており、イーサネット アドレスを指すことに注意してください。 IP アドレス (nt | rt: たとえば、

'
Note' と理解できます。イーサネットの送信元アドレスまたは宛先アドレス、イーサネットの送信元および宛先アドレスは、前の文の 'ゲートウェイ アドレス' を参照していると理解できます。host は数値ではなく名前でなければなりません。マシンの 'ホスト名-IP アドレス #' および 'ホスト名-イーサネット アドレス '2 つの主要なマッピング関係にエントリがあります (前者のマッピング関係は /etc/hosts ファイル、DNS または NIS を通じて取得でき、後者のマッピング関係は /etc/ethers ファイルを通じて取得できます)。 nt: /etc/ethers は必ずしも存在するわけではなく、そのデータ形式は man ethers で確認できます。このファイルの作成方法は不明なので補足が必要です。つまり host 意味は host ではなく ether host ehost ですhost および ehost は、番号ではなく名前である必要があります。現在、このオプションは、IPv6 アドレス形式 (nt: 構成、構成環境、 のネットワーク構成として理解できます) をサポートする構成環境では機能しません。 dst net net
データ パケットの宛先アドレス (IPv4 または IPv6 形式) のネットワーク番号フィールドが net の場合、対応する条件式は true です。 net には、ネットワーク データベース ファイル /etc/networks の名前を指定することも、数値のネットワーク番号を指定することもできます。

数値の IPv4 ネットワーク番号は、ドット区切りの 4 つ組 (例: 192.168.1.0)、またはドット区切りの 3 つ組 (例: 192.168.##) になります。 #1 )、またはドット付きタプル (例: 172.16)、または単一ユニット グループ (例: 10) を使用して表現します。

ネットワークこれら 4 つの状況に対応するマスクは次のとおりです。 4 タプル:

255.255.255.255 (これは、 net のマッチングがホスト アドレス ( host ) のマッチングと同じであることも意味します。アドレスの 4 つの部分すべてが使用されます)、トリプレット: 255.255.255.0、タプル: 255.255.0.0 、1 タプル: 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

If データパケットの送信元アドレス (IPv4 またはIPv6 形式) はネットワークです。番号フィールドが net の場合、対応する条件式は true です。

net net

If 送信元アドレスまたは宛先アドレス (IPv4 または IPv6 形式) のネットワーク番号フィールドデータ パケットが net の場合、次と同じです。この対応する条件式は true です。

net ネット マスク netmask

データ パケットの送信元アドレスまたは宛先アドレス (IPv4 または IPv6 形式) のネットワーク マスクの場合ネットマスクに一致し、対応する条件が一致します。 式が true です。このオプションは、送信元ネットワーク アドレスまたは宛先ネットワーク アドレス (nt: src net ネット マスク

255.255
.# など) と一致させるために、src および dst とともに使用することもできます。 ##255.0) このオプションは、ipv6 ネットワーク アドレスには無効です。net net/len送信元アドレスまたは宛先アドレスのネットワーク番号フィールドのビット数 (IPv4 または IPv6 形式)データ パケットの ) が len と同じである場合、対応する条件式が true である場合、このオプションを src および dst とともに使用して、送信元ネットワーク アドレスまたは宛先ネットワーク アドレス (nt | rt | tt: src net) と一致させることもできます。 net/

24

、送信元アドレスのネットワーク番号を一致させる必要があることを示します。24 ビットのデータ パケットがあります)。
dst port portデータ パケット (ip/tcp、ip/udp、ip6/tcp、または ip6/udp プロトコルを含む) がポートである場合、この対応する条件式は true と同じです。ポートは番号または名前にすることができます (対応する名前は可能です) /etc/services で見つかるか、man tcp および man udp を通じて関連する説明情報を取得できます。name を使用すると、名前に対応するポート番号と、使用される対応するプロトコルがチェックされます。数値ポートのみの場合は、番号が使用されると、対応するポート番号のみがチェックされます (たとえば、dst ポート

513

では、tcpdump が tcp プロトコルのログイン サービス パケットと udp プロトコルの who サービス パケットを取得します)ポート ドメインにより、tcpdump は tcp プロトコルのドメイン サービス パケットと udp プロトコルのドメイン パケットをキャプチャします) (nt | rt: 使用されているあいまいな名前
is は理解できないため、補足する必要があります) .src port portデータ パケットの送信元ポートが port の場合、対応する条件式は true です。

port port
If は、データ パケットの送信元ポートまたは宛先ポートです。データ パケットが port の場合、対応する条件式は true です。

dst portrange port1-port2
データ パケット (ip/tcp、ip/udp、ip6/tcp、または ip6/udp プロトコルを含む) の場合、宛先ポートが port1 から port2 までのポート範囲 (port1、port2 を含む) に属している場合、対応する条件式が true である tcpdump は port1 と port2 および port を解析する 解析は一貫している (nt: dst port port オプションの説明で説明) ).

src portrange port1-port2
データ パケットの送信元ポートが port1 から port2 までのポート範囲 ( port1 、 port2 を含む) に属する場合、対応する条件式は true になります。

#portrange port1-port2

データ パケットの送信元ポートまたは宛先ポートが port1 から port2 までのポート範囲 (port1、port2 を含む) に属する場合、対応する条件式は true になります。

上記のポート オプションの前にキーワード: tcp または udp を付けることができます。例:

tcp src port port

これにより、tcpdump はソース ポートが port である TCP データ パケットのみをキャプチャします。

less length

データ パケットの長さが length 未満であるか、length と等しい場合、対応する条件式は true です。これは、
'

len < の意味と一致します。 ;= 長さ
'.

greater length
データ パケットの長さが length より大きいか length と等しい場合、対応する条件式が true になります。これは 'len >= と同じです。 length' は同じ意味です。

ip proto protocol
データ パケットが ipv4 データ パケットで、そのプロトコル タイプがプロトコルの場合、対応する条件式は true になります。 .
プロトコルには、icmp6、igmp、igrp (nt: Interior Gateway Routing Protocol、内部ゲートウェイ ルーティング プロトコル)、pim (Protocol Independent Multicast、マルチキャスト ルーターに適用される独立したマルチキャスト プロトコル) などの番号または名前を指定できます。 、ah、esp (nt: ah、認証ヘッダー、esp セキュリティ ペイロード カプセル化。どちらも IP パケットの安全な送信メカニズムで使用されます)、vrrp (仮想ルーター冗長プロトコル、仮想ルーター冗長プロトコル)、udp、または tcp . tcp、udp、および icmp は tcpdump のキーワードであるため、これらのプロトコル名の前に \ を使用してエスケープする必要があります (C シェルで \\ を使用してエスケープする必要がある場合)。この式要素はすべてのプロトコルを出力するわけではないことに注意してください。データ パケット内のプロトコル ヘッダー チェーンのヘッダー内容 (nt: 実際には、指定されたプロトコルの一部のヘッダー情報のみが出力されます。たとえば、 tcpdump -i eth0 'ip を使用できます) proto \tcp およびホスト 192.168.3.144' の場合、ホスト 192.168.3.144## によって送受信されるデータ パケット内の TCP プロトコル ヘッダーのみ# 表示されます。情報が含まれます)

ip6 プロト プロトコル

データ パケットが ipv6 データ パケットで、そのプロトコル タイプがプロトコルの場合、対応する条件式は true です。
この式は注意してください。要素は、データ パケット内のプロトコル ヘッダー チェーン内のすべてのプロトコル ヘッダーの内容を出力しません。

ip6 プロトチェーン プロトコル

データ パケットが ipv6 データ パケットであり、そのプロトコル チェーンに次のタイプのプロトコル ヘッダーが含まれている場合。たとえば、

ip6 protochain

6 は、プロトコル ヘッダー チェーンに TCP プロトコル ヘッダーを持つ IPv6 パケットと一致します。このパケットの IPv6 ヘッダーと TCP ヘッダーには、検証ヘッダー、ルーティング ヘッダー、またはホップバイホップ ルーティング オプション ヘッダーも含まれる場合があります。
これによってトリガーされる対応する BPF (Berkeley Packets Filter) は、パケット フィルタリングを提供すると理解できます。データ リンク層 (メカニズム) コードは比較的複雑で、
および BPF 最適化コードはこの部分の処理に失敗するため、このオプションによってトリガーされるパケット マッチングは遅くなる可能性があります。

ipプロトチェーン プロトコル

と ip6 プロトチェーン プロトコルの意味は同じですが、これは IPv4 データ パケットに使用されます。

イーサ ブロードキャスト

データ パケットがイーサネット ブロードキャスト データ パケットの場合、対応する条件式は true です。ether キーワードはオプションです。

ipブロードキャスト

パケットが IPv4 ブロードキャスト パケットの場合、対応する条件式は true です。これにより、tcpdump はブロードキャスト アドレスがすべて 0 に一致するかどうかを確認します。およびすべて 1 いくつかの規則に従って、ネットワーク インターフェイスのネットワーク マスクを探します (ネットワーク インターフェイスは、その時点でパケットがキャプチャされるネットワーク インターフェイスです)。

If ネットワーク インターフェイスのネットワーク マスクキャプチャされたパケットが不正であるか、インターフェイスが単純ではありません。対応するネットワーク アドレスとネットワークが設定されていないか、パケットが

'any' でキャプチャされています。 Linux 上のネットワーク インターフェイス (this' any'このインターフェイスは、システム内の複数のインターフェイスからデータ パケットを受信できます (nt: 実際には理解できます)システム内で使用可能なすべてのインターフェイスとして))、ネットワーク マスク チェックは正常に続行できません。

イーサ マルチキャスト

データ パケットがイーサネット マルチキャスト パケット (nt: マルチキャスト) の場合、配信していると理解できます。ネットワーク内ではなく、同時に宛先アドレスのグループにメッセージを送信します すべてのアドレス (後者はブロードキャストと呼ぶことができます) について、対応する条件式が true です キーワード ether は省略できます このオプションの意味は次のとおりです次の条件式の意味と一致します: `ether[
0] & 1 != 0'(nt : イーサネット データ パケットの 0 番目のバイトとして理解できます。最下位ビットは 1 です。これは、これが マルチキャスト パケットであることを意味します)。

ip multicast

パケットが ipv4 マルチキャスト パケットの場合

ip6 multicast

データ パケットが ipv6 マルチキャスト データ パケットの場合、対応する条件式は true です。

イーサ プロトコル プロトコル
データ パケットが次のイーサネット プロトコル タイプに属している場合、対応する条件式は true です。
プロトコル フィールド。以下にリストされている番号または名前を指定できます: ip 、 ip6、arp 、rarp、atalk (AppleTalk ネットワーク プロトコル)、
aarp (nt: AppleTalk Address Resolution Protocol、AppleTalk ネットワークのアドレス解決プロトコル)、
decnet (nt: DEC スタックによって提供されるネットワーク プロトコル)、sca( nt: 不明、補足する必要があります)、
lat(ローカル エリア ト​​ランスポート、地域トランスポート プロトコル、DEC によって開発されたイーサネット ホスト相互接続プロトコル)、
mopdl、moprc、iso(nt: 不明、追加する必要があります) 、stp (スパニング ツリー プロトコル、スパニング ツリー プロトコル。ネットワーク内のリンク ループを防ぐために使用できます)、
ipx (nt: Internetwork Packet Exchange、Novell ネットワークで使用されるネットワーク層プロトコル)、または
netbeui (nt : NetBIOS 拡張ユーザー インターフェイス (ネットワーク基本入出力システム インターフェイス拡張として理解できます)。

プロトコル フィールドには、数値または次のプロトコル名のいずれかを指定できます: ip、ip6、arp、rarp 、atalk、aarp、decnet、sca、lat、
mopdl、moprc、iso、stp、ipx、または netbeui。
識別子はキーワードでもあるため、渡す必要があることに注意してください。'\' でエスケープします。

(SNAP: SubNetwork Access Protocol)

光ファイバー分散データ ネットワーク インターフェイス (その表現メタ形式は ## です) #'fddi プロトコル arp')、トークン リング ネットワーク (式要素の形式は 'tr プロトコル arp# にすることができます) ##')、 および IEEE 802.11
無線 LAN (式要素形式は 'wlan プロトコル arp ')、プロトコル識別子は、FDDI、トークンリング、または802
の802.2論理リンク制御層ヘッダーから取得されます。1つのヘッダーにはこれが含まれます論理リンク制御層ヘッダー。
これらのネットワーク上の対応するプロトコル識別子がフィルター条件として使用される場合、tcpdump はコンポーネント ユニット識別子として 0x000000 を持つ LLC ヘッダー (OUI 、0x000000

#) のみをチェックします。 ##内部イーサネットを識別します)

'SNAP 形式構造
' のプロトコル ID フィールドのセグメントの代わりに、セクションがあるかどうかを確認します。 OUI が 0x000000 のパッケージ'SNAP 形式構造'
(nt: SNAP 、サブネットワーク アクセス プロトコル、サブネット アクセス プロトコル) 以下の例外: iso tcpdump は、DSAP フィールド (宛先サービス アクセス ポイント、ターゲット サービス アクセス ポイント) および ## を LLC ヘッダーでチェックします。 # SSAP ドメイン (ソース) (nt: iso プロトコルは不明なので補足する必要があります) stp および netbeui

tcpdump は、LLC ヘッダーの宛先サービス アクセス ポイント (宛先サービス) をチェックします。

atalk

tcpdump は、OUI 識別子として 0x080007 を持つ LLC ヘッダー内の

'

SNAP 形式構造

#'## をチェックします。 AppleTalk etype フィールドをチェックします。 (nt: AppleTalk etype が SNAP 形式構造にあるかどうかは不明ですが、補足する必要があります)。 さらに、イーサネットでは、ether プロト プロトコル オプションについて、tcpdump イーサネット タイプ フィールドは、次のプロトコルを除き、protocol で指定されたプロトコルについてチェックされます: iso、stp、および netbeui tcpdump は 802.
3
物理フレームおよび LLC ヘッダー (これら 2 つのチェックは、FDDI、TR、
802
.11 ネットワークの対応するチェックと一致します);
(nt:
802.3
、IEEE ## として理解されます) #802.3, これは IEEE 標準の集合です。この集合は、有線イーサネット ネットワークのデータ リンク層の物理層とメディア アクセス コントロール サブレイヤを定義します。stp 上で説明) atalk
tcpdump は、イーサネット物理フレームの AppleTalk etype フィールドをチェックし、データ パケットの LLC ヘッダーの ' もチェックします。 ' (これら 2 つのチェックは、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: 実際には光ファイバー ネットワークとして理解できます)、無線 LAN (
802.11
) など)ipx tcpdump は物理イーサネット フレームの IPX etype をチェックします。フィールド、LLC ヘッダーの IPX DSAP フィールド、LLC ヘッダーと IPX カプセル化なしの 802.3 フレーム、

および LLC ヘッダー

'
SNAP フォーマット構造 ##'# の IPX etype フィールド## (nt | rt: SNAP フレーム。LLC ヘッダーの 'SNAP フォーマット構造として理解できます。' . この意味は、予備的な理解の段階であり、補足する必要があります)。decnet src hostデータ パケット内の DECNET 送信元アドレスが host の場合、対応する条件式は true です。
(nt:decnet 、Digital Equipment Corporation によって開発され、PDP-

11

マシン相互接続に最初に使用されたネットワーク プロトコル)

decnet dst hostデータ パケット内の DECNET 宛先アドレスが host の場合、対応する条件式は true です。(nt: decnet は上で説明しています)

decnet host host
データ パケット内の DECNET 宛先アドレスまたは DECNET 送信元アドレスが host の場合、対応する条件式が true です。
(nt: decnet は上で説明しています)

ifname
interface

データ パケットが指定されたネットワーク インターフェイスから受信済みとしてマークされている場合、対応する条件式は true です。

(このオプションは、OpenBSD の pf プログラム (nt: pf、パケット フィルター、OpenBSD のファイアウォール プログラムとして理解できます) によってマークされたパケットにのみ適用されます)) on
interface

は ifname

interface.
rnr numif と同じ意味を持ちます。パケットが PF ルールに一致するとマークされている場合、対応する条件式は true です。(このオプションは、OpenBSD の pf プログラムによってマークされたパケットにのみ適用されます (nt: pf、パケット フィルター、OpenBSD のファイアウォール プログラムとして理解されます))

rulenum num
は、rulenum num と同じ意味です。

理由コード

パケットが PF の一致する結果コードを含むものとしてマークされている場合、対応する条件式は true です。有効な結果コードは次のとおりです。 match、bad-offset、
fragment、

short

、normalize、memory.
(このオプションは、OpenBSD の pf プログラムによってマークされたパケットにのみ適用されます (nt: pf、パケット フィルター、 OpenBSD のファイアウォール プログラムとして理解できます))
rset nameパケットが指定されたルール セットに一致するとマークされている場合、対応する条件式は true です。
(このオプションOpenBSD の pf プログラムによってマークされたパケットにのみ適用されます (nt: pf、OpenBSD のファイアウォール プログラムとして理解できるパケット フィルター) )

ルールセット名
rset 名と同じ意味です。

srnr num

指定されたルール セット内の特定のルールに一致するようにパケットがマークされている場合 (nt: 指定された PF ルール番号、特定のルール番号、つまり特定のルール)、
は、対応する条件式が true であることを意味します (このオプションは、OpenBSD の pf プログラムによってマークされたパケットにのみ適用されます (nt: pf、パケット フィルター、

OpenBSD ではファイアウォール プログラムとして理解されます))

subrulenum num
は srnr と同じ意味です。

action act

パケットが記録される場合、PF は act で指定されたアクションを実行します。対応する条件式が true です。有効なアクションは次のとおりです: pass 、block.
(このオプションは、OpenBSD の pf プログラムによってマークされたパケットにのみ適用されます (nt: pf、パケット フィルター、OpenBSD のファイアウォール プログラムとして理解できます))

ip, ip6, arp 、rarp、atalk、aarp、decnet、iso、stp、ipx、netbeui
は、次の式と同じ意味を持ちます:
ether proto p

p は、上記のプロトコルの 1 つです。 #lat, moprc, mopdl

は次の式と同じ意味を持ちます:
ether proto p
p は上記のプロトコルのいずれかです。tcpdump は現在これらのプロトコルを分析できないことに注意してください。

vlan [vlan_id]
データ パケットが IEEE802.1Q VLAN データ パケットの場合、対応する条件式は true です。
(nt: IEEE802.1Q VLAN、つまり IEEE802.1Q 仮想ネットワーク プロトコル、このプロトコルは異なるネットワーク間の相互接続に使用されます)。
[vlan_id] が指定されている場合、指定された仮想ネットワーク ID (vlan_id) がデータのみに含まれ、対応する条件式が true になります。
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 データ パケットの場合、対応する条件式は true です。
(nt: MPLS、マルチプロトコル ラベル スイッチ、マルチプロトコル ラベル交換、ラベルを使用する技術オープン通信ネットワークでのデータ送信をガイドするため)。

[label_num] が指定されている場合、データには指定されたラベル ID (label_num) のみが含まれており、対応する条件式は true になります。

これは、 MPLS 情報を含む IP データ パケット (つまり、MPLS データ パケット) の場合、式内で最初に出現する MPLS キーワードによって、式内の後続のキーワードが変更されることに注意してください。データ パケット内のデータの開始位置
は、対応するMPLS ネットワーク システムでデータ パケットをフィルタリングする場合、mpls [label_num] 式を複数回使用できます。キーワード mpls が出現するたびに、
4 バイト フィルタが追加されます。 offset (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,

its Ethernet type is 0x8863) の場合、対応する条件式は true です。
(nt: PPP-over-イーサネット、ポイントツーポイント イーサネット ベアラー プロトコル、ポイントツーポイント接続の確立は、ディスカバリ フェーズ (アドレス検出) と
PPPoE セッション確立フェーズに分かれており、ディスカバリ パケットは最初のフェーズで送信されるパケットです。 ethernet type
は、フレーム データ フィールドに適用されるプロトコルを示すために使用される Ethernet フレーム内のフィールドです)

pppoes

データ パケットが PPP-over-Ethernet セッション データ パケット (nt:イーサネット タイプは 0x8864 です。PPP-over-Ethernet については上で説明しました。

keyword
'
PPP-over-Ethernet'を検索して見つけます。 PPP-over-Ethernet セッション データ パケットの場合、最初の pppoes キーワードによって条件式が変更されることに注意してください。式内の次のキーワードに対応するデータ パケット内のデータの開始位置 (つまり、デコード オフセット)。

例:
pppoes && ip

意味: 埋め込まれた ipv4 データ パケットをフィルタリングするPPPoE データ パケットの

tcp、udp、icmp
は、次の式と同じ意味を持ちます。

ip proto p または ip6 proto p

ここで、p は上記のプロトコルのいずれか (意味は次のとおりです。データ パケットが ipv4 または ipv6 データ パケットで、そのプロトコル タイプが tcp、udp、または icmp の場合、対応する条件式
が true)

iso proto protocol
Ifデータ パケットのプロトコル タイプが iso-osi プロトコル スタックのプロトコル プロトコルである場合、対応する条件式が true です。(nt: [初期解] iso-osi ネットワーク モデル内のすべての

レイヤーの特定のプロトコルはtcp/ip の対応する層で使用されるプロトコルとは異なります。iso-osi の各層の特定のプロトコルを補足する必要があります)

protocol には数値または次の名前のいずれかを指定できます:
clnp、esis、または isis.

(nt: clnp、コネクションレス ネットワーク プロトコル、これは OSI ネットワーク モデルのネットワーク層プロトコルです。esis、isis は不明なので補足する必要があります)

clnp、esis、isis
は、次の式

iso proto p

の略語です。ここで、p は上記のプロトコルのいずれかです。

l1、l2、iih、lsp、snp、csnp、psnp
は IS-IS PDU タイプの略称です。
(nt: IS-IS PDU、中間システム間プロトコル データ ユニット、中間システム
中間システムまでのプロトコル データの単位 OSI (Open Systems Interconnection) ネットワークは、エンド システムと中間システムで構成されます
エンド システムはルータを指し、エンド システムはユーザ機器を指しますルーターによって形成されるローカル グループは 'Area' (エリア) と呼ばれ、複数のエリアが ' ドメインを形成します。 ' (ドメイン).
IS-IS は、ドメイン内またはエリア内ルーティングを提供します。l1、l2、iih、lsp、snp、csnp、psnp は、PDU のタイプを示します。特定の意味を補足する必要があります)

vpi n
データ パケットが ATM データ パケットである場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、
If データ パケットpacket が ATM データ パケットであり、その仮想パス識別子が n である場合、対応する条件式は true になります。
(nt: ATM、非同期転送モード。実際には、ITU によって提案された TCP/IP プロトコルとして理解できます。 T (国際電気通信連合電気通信標準化部門) IP 層で同等の機能を持つ一連のプロトコル。特定のプロトコル レベルを補足する必要がある)

vci n

データ パケットが ATM データ パケットの場合の場合、対応する条件式は true です。システム上の Solaris 操作 SunATM デバイスの場合、
データ パケットが ATM パケットであり、その仮想チャネル識別子が n の場合、対応する条件式は true です。
(nt : ATM、上記で説明しました )

lane

データ パケットが ATM LANE データ パケットの場合、対応する条件式が true になります。ただし、シミュレートされたイーサネット LANE データ パケットの場合は、注意が必要です。または
LANE 論理ユニット制御パケットの場合、式の最初のレーン キーワードにより、式内の後続の条件のテストが変更されます。
でレーン キーワードが指定されていない場合、条件テストは LLC (論理リンク) に基づいて行われます。データ パケット ATM パケットに含まれる層)。

llc

データ パケットが ATM パケットである場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、
If theデータ パケットが ATM データ パケットであり、LLC を含む場合、対応する条件式は true

oamf4s

データ パケットが ATM データ パケットである場合、対応する条件式は true Solaris の場合 SunATM デバイスの場合オペレーティング システム上で、パケットが ATM パケット
であり、セグメント OAM F4 セル (VPI=
0 および VCI=3) である場合、これは次の条件式に相当します。 true.

(nt: OAM、Operation Administration and Maintenance、運用管理と保守。これは次のように理解できます。ATM ネットワークにおけるネットワーク

管理のために生成される ATM セルの分類 Method.

ATM ネットワークの伝送単位はセルであり、伝送されるデータは最終的に固定長 (53 バイト) のセルに分割されます。

(初期理解: 物理回線は二重化可能)仮想パス (
virtual パス) を形成します。そして、仮想パスは再び再利用されて仮想チャネル (仮想 チャネル) を形成します。通信する双方の当事者のアドレス指定方法は次のとおりです。 :仮想パス番号 (VPI)/仮想チャネル番号 (VCI)).

OAM F4 フローセルはセグメント クラスとエンドツーエンド クラスに分類できますが、その違いは不明なので補足する必要があります。 )

oamf4e

パケットが ATM パケットである場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケットである場合
および end -to -end OAM F4 セル (VPI=
0 および VCI=4) の場合、対応する条件式は true です。(nt: OAM およびエンドツーエンド OAM F4上で説明したように、
'oamf4s' を検索して見つけることができます)

oamf4

if データ パケットがATM データ パケット、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、データ パケットが ATM データ パケット
であり、エンドツーエンドまたはセグメント OAM F4 セル (VPI=##) である場合、 #0
および VCI=3 または VCI=4) の場合、対応する条件式は true です。(nt: OAM エンドツーエンド OAM F4 は上で説明したように、'
oamf4s' を検索して見つけます)oam

データ パケットが ATM データ パケットの場合Solaris オペレーティング システム上の SunATM デバイスの場合、データ パケットが ATM データ パケット

であり、エンドツーエンドまたはセグメント OAM F4 セル (VPI=
0##) である場合、対応する条件式は true です。 # および VCI=
3 または VCI=4) の場合、対応する条件式は true です。(nt : このオプションは oamf4 と重複しているため、確認が必要です)

metac
パケットが ATM パケットである場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケット
で、'## からのものである場合、 #メタシグナリング ライン'(nt: VPI=0 および VCI=1, 'メタシグナリング回路'、メタシグナリング回路、具体的な意味は不明なので補足する必要があります)、その後、対応する条件式が真となります。

bcc

パケットが ATM パケットである場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケットである場合
および
'Broadcast信号線 #'(nt: VPI=0 および VCI=2, 'ブロードキャスト信号回路'、ブロードキャスト シグナリング回路、具体的な意味は不明なので補足する必要があります)、その後、対応する条件式は true になります。

sc

If the packet is ATM パケットの場合、対応する条件式は true です。Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケット
であり、
' 信号回線## からのものである場合、 #'(nt: VPI=0 および VCI=5, '信号回路' 、シグナリング回路、具体的な意味は不明なので補足する必要があります)、then 対応する条件式は true です。
ilmic

データ パケットが ATM データ パケットの場合、対応する条件式Solaris オペレーティング システム上の SunATM デバイスの場合、データ パケットが ATM データ パケット

であり、
'
ILMI 行 ' からのものである場合(nt: VPI=0 および VCI=16、'ILMI'、暫定ローカル管理インターフェイス、 SNMP (Simple Network Management Protocol) に基づいたネットワーク管理用のインターフェイス)対応する条件式が true であると理解できます。

connectmsg

パケットが ATM パケットの場合、 Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケット

であり、
'
シグナリング ライン '## からのものである場合、対応する条件式は true です。 # および Q.2931 プロトコルで指定されている次のメッセージです: Setup、Calling Proceeding、Connect、Connect Ack、Release、または Release Done。対応する条件式は true です。(nt: Q.2931
は、ITU (国際電気通信連合) によって開発されたシグナリング プロトコルであり、ブロードバンド総合サービス デジタル ネットワークのユーザー インターフェイス層が、
ネットワーク接続の関連手順を確立、維持、およびキャンセルすることを規定しています。 metaconnect
データ パケットが ATM データ パケットの場合、対応する条件式は True になります。Solaris オペレーティング システム上の SunATM デバイスの場合、パケットが ATM パケット

であり、

'

meta-signaling line' および Q.2931 プロトコルで指定されている次のメッセージです: Setup、Calling Proceeding、Connect、Connect Ack 、Release、または Release Done。対応する条件式は true です。expr relop expr
relop の両側のオペランド (expr) が relop で指定された関係を満たす場合、対応する条件式は true になります。 .

relop は、次の関係演算子のうちの 1 つです: >、<、<=、=、!=.

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、linkがデータリンク層、radioが802.11(wlan、無線LANに対応) ) 一部のデータ パケットに添付された
"radio" ヘッダー (nt: ボー レート、データ暗号化、その他の情報を説明します)。
tcp や udp などの上位層プロトコルは、現在、ネットワーク層が IPv4 または IPv6 プロトコルを採用しているネットワークにのみ適用できることに注意してください (この制限は、tcpdump
の将来のバージョンで変更される予定です)。必要なデータ、パケット データ内のそのオフセット バイトは expr で指定されます。

上記の式のサイズはオプションであり、対象となるデータ セグメントの部分の長さを示すために使用されます (nt:通常、このデータ部分
はデータ パケットのフィールドです)、その長さは 1、2、または 4 バイトです。サイズが指定されていない場合、デフォルトは 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 プロトコル ヘッダー コード フィールドを参照)、および tcpflags (TCP プロトコル ヘッダーの flags フィールドを参照)

ICMP プロトコルの type フィールドで使用可能な値は次のとおりです。 header:
icmp-echoreply、icmp-unreach、icmp-sourcequench、icmp-redirect、icmp-echo、icmp-routeradvert、
icmp-routersolicit、icmp-timx-ceed、icmp-paraamprob、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 は何に役立ちますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。