tcpdump
のmanページを確認すると、バッファがいっぱいの場合、カーネルがパケットをドロップする可能性があります。私は疑問に思っていました:
マニュアルページから(簡単に参照できるように):
「カーネルによってドロップされた」パケット(これは、OSがその情報をアプリケーションに報告した場合に、tcpdumpが実行されているOSのパケットキャプチャメカニズムによって、バッファースペースの不足のためにドロップされたパケットの数です。そうでない場合は、0として報告されます。
Tcpdumpには、キャプチャバッファサイズを設定するオプション_-B
_があります。次に、値はpcap_set_buffer_size()
関数を介してlibpcap(tcpdumpが実際のパケットキャプチャを行うために使用するライブラリ)に渡されます。 Tcpdumpのマンページでは、-Bでバッファーサイズを指定する単位を指定していませんが、 source からはKiBのようです。
pcap_set_buffer_size()
のマニュアルページでは、デフォルトのバッファサイズ(この関数が呼び出されない場合に使用される)を指定していませんが、 libpcap source から、これは2 MiBのようです。少なくともLinuxでは(ただし、システムに依存している可能性が高い)。
パケットのバッファリングとドロップに関しては、それに応じてsnaplen(_-s
_)パラメータを設定することにも注意を払う必要があります。 _man tcpdump
_:
_-s Snarf snaplen bytes of data from each packet rather than the
default of 65535 bytes. Packets truncated because of a limited snapshot
are indicated in the output with ``[|proto]'', where proto is the name of
the protocol level at which the truncation has occurred. Note that taking
larger snapshots both increases the amount of time it takes to
process packets and, effectively, decreases the amount of packet buffering.
This may cause packets to be lost. You should limit snaplen to the
smallest number that will capture the protocol information you're
interested in. Setting snaplen to 0 sets it to the default of 65535, for
back-wards compatibility with recent older versions of tcpdump.
_
つまり、固定バッファーサイズでは、snaplenサイズを小さくすることで、バッファーに収まる(したがってドロップされない)パケットの数を増やすことができます。