38

Linuxでlibpcapを使用してパケットをスニッフィングしています。各パケットで取得するヘッダーは次のようになります。

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};

さて、caplenはキャプチャしたデータの長さであり、lenはワイヤ上のパケットの長さであると私は理解しています。場合によっては（たとえば、pcapデバイスを開くときにsnaplenを低く設定しすぎる場合）、パケットの一部のみをキャプチャする場合があります。その長さは「caplen」ですが、「len」は元の長さです。したがって、caplenはlen以下である必要がありますが、lenより大きくなることはありません。

それは適切な理解ですか？一部のマシンではcaplen>lenを使用しています

4

3 に答える 3

25

少なくともpcapのmanページに基づいて、あなたの理解は正しいです。

caplenは、キャプチャで使用できるデータの量です。lenはパケットの実際の長さでした。

私はあなたにcaplen>lenを与えるようなケースを知りません。私のスナップレンは十分に高いので、私は通常それらが等しいように見えます。

于 2009-09-29T16:11:30.170 に答える
6

はい、あなたの理解は正しいです。Caplenは常にLenよりも小さいです。パケット全体をキャプチャする必要がない場合もあります。しかし、チャンスがあれば、なぜパケット全体をキャプチャしないのでしょうか。大量のネットワークトラフィックでは、それは良い考えではないからです。回線上に表示されるパケット全体をキャプチャしないと、実際に貴重なデータが失われるのではないでしょうか。いいえ。実際には、目的によって異なります。プロトコルと宛先のアプリケーションに基づいてパケットを分類する場合は、約14バイト（イーサネット）+ 20バイト（Ip）+さらに20（Tcp）が必要です。したがって、プロトコルに基づいてパケットを分類するために必要なデータは明らかに54バイトだけなので、処理サイズをpcappkthdr->lenからpcappkthdr->caplenに減らすことで多くの負荷と時間を節約できます:)

パケット内のヘッダーが破損している場合（つまり、headerlength値が何らかの理由で混乱している場合）、キャプチャされた長さはパケットの実際の長さよりも長くなります。

于 2013-01-02T16:22:25.790 に答える
3

caplen> lenの場合、それはバグです。どのバージョンのlibpcapを使用していますか？

于 2013-01-05T22:21:28.483 に答える