は最適SNAPLENはPCAPライブキャプチャ

Question

インターフェースから盗聴するpcap_open_liveを使用するため、私はBUFSIZ（<stdio.h>）に「マジックナンバー」の範囲の、SNAPLEN値として様々な数字を使用した例をたくさん見てきました。

はそれがSNAPLENとして、我々はからキャプチャしているインターフェイスのMTUを設定するにはより多くの意味を成しませんか？ このようにして、一度に多くのパケットをPCAPバッファに収めることができました。 MRUがMTUに等しいと仮定することは安全ですか？

そうでない場合は、SNAPLEN値を設定するための非エキゾチックな方法は何ですか？

おかげ

Answer 1

MTUは、リンク層に渡すことができ、最大ペイロードサイズです。リンク層ヘッダーは含まれていません。たとえば、イーサネット上では1514または1518ではなく1500になり、フルサイズのイーサネットパケットをキャプチャするのに十分な大きさではありません。

はまた、そのような802.11無線情報のradiotapヘッダとして任意のメタデータ・ヘッダが含まれていません。

アダプタが断片化/セグメンテーション/リアセンブリオフロードのいずれかの形式を実行している場合、アダプタに渡されたパケットまたはアダプタから受信されたパケットは、まだ断片化またはセグメント化されていないか、または再アセンブリされている可能性があります。 多くは MTUより大きいかもしれません。

固定サイズのパケットスロットを持つ、LinuxのメモリマップされたTPACKET_V1およびTPACKET_V2キャプチャメカニズムにのみ適用されるPCAPバッファ内のより多くのパケットをフィッティングする場合。他のキャプチャメカニズムではすべてのパケットに最大サイズのスロットが予約されないため、スナップショットの長さを短くすることは重要ではありません。 TPACKET_V1とTPACKET_V2では、スナップショットの長さを短くすることで違いがありますが、少なくともEthernetの場合、libpcap 1.2.1はイーサネットに適したバッファスロットサイズを選択することができます。 （TPACKET_V3は固定サイズのパケット単位のスロットを持っていないようですが、この場合はこの問題はありませんが、正式にリリースされたカーネルにしか現れず、libpcapにまだサポートされていません）。