pcap_open_liveインターフェイスからスニッフィングするために使用する場合、 ( ) から「マジック ナンバー」SNAPLENまで、さまざまな数値を値として使用する多くの例を見てきました。BUFSIZ<stdio.h>
キャプチャ元のインターフェイスの MTU を SNAPLEN として設定する方が理にかなっているのではないでしょうか? このようにして、PCAP バッファにより多くのパケットを一度に収めることができます。MRU が MTU と等しいと仮定しても安全ですか?
それ以外の場合、SNAPLEN 値を設定する非エキゾチックな方法はありますか?
ありがとう
MTU は、リンク層に渡すことができる最大のペイロードサイズです。これにはリンク層ヘッダーが含まれていないため、たとえば、イーサネットでは 1514 または 1518 ではなく 1500 になり、フルサイズのイーサネット パケットをキャプチャするのに十分な大きさにはなりません。
さらに、802.11 無線情報の radiotap ヘッダーなどのメタデータ ヘッダーは含まれません。
また、アダプタがフラグメンテーション/セグメンテーション/再アセンブリのオフロードを何らかの形で実行している場合、アダプタに渡された、またはアダプタから受信されたパケットは、まだフラグメント化またはセグメント化されていないか、再アセンブルされている可能性があり、そのため、はるかに大きくなる可能性があります。 MTUよりも。
PCAP バッファにより多くのパケットを収めることに関しては、これは、固定サイズのパケット スロットを持つ、Linux のメモリ マップされた TPACKET_V1 および TPACKET_V2 キャプチャ メカニズムにのみ適用されます。他のキャプチャ メカニズムでは、すべてのパケットに対して最大サイズのスロットが予約されないため、スナップショットの長さが短くても問題ありません。TPACKET_V1 と TPACKET_V2 の場合、スナップショットの長さを短くすると違いが生じる可能性がありますが、少なくともイーサネットの場合、libpcap 1.2.1 は、イーサネットに適切なバッファ スロット サイズを選択するために最善を尽くします。(TPACKET_V3 には固定サイズのパケットごとのスロットがないように見えます。その場合、この問題は発生しませんが、最近公式にリリースされたカーネルにのみ表示され、libpcap ではまだサポートされていません。)