You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The -G option behavior differs from the documentation (tcpdump manual).
The manual says it will rotate the dump file every -G n seconds.
The rotation period is actually the time to first packet captured plus n seconds. i.e. n count down begins at time of the first captured packet.
If there is a capture filter or the network load is light, then the n seconds period start time could be delayed. Thus the times of subsequent rotations are also delayed. This delay is accumulative with each rotation. Causing the rotation time to drift out. Thus each capture file covers the time period of time to first captured packet plus n seconds. Not just n seconds.
Example:
If a capture is started at 13:00:00 with options -w time -W 24 -G 3600, and a capture filter that results in considerable time gaps between captured packets. Instead of each rotation being at the top of every hour they will drift off. By the 24th rotation it could be off by a considerable amount. Rotating at say maybe 12:10:37 instead of the expected time of 12:00:00.
It would be nice if there was an option to rotate at specific times. A cron like time specifier (minute hour, day, etc.). Or at least grab the current time at tcpdump launch and base the n seconds on that rather then first packet captured time. Or maybe subtract the time between launch/rotation to first packet capture.
tcpdump version 4.9.2
libpcap version 1.5.3
The text was updated successfully, but these errors were encountered:
The -G option behavior differs from the documentation (tcpdump manual).
The manual says it will rotate the dump file every -G n seconds.
The rotation period is actually the time to first packet captured plus n seconds. i.e. n count down begins at time of the first captured packet.
If there is a capture filter or the network load is light, then the n seconds period start time could be delayed. Thus the times of subsequent rotations are also delayed. This delay is accumulative with each rotation. Causing the rotation time to drift out. Thus each capture file covers the time period of time to first captured packet plus n seconds. Not just n seconds.
Example:
If a capture is started at 13:00:00 with options -w time -W 24 -G 3600, and a capture filter that results in considerable time gaps between captured packets. Instead of each rotation being at the top of every hour they will drift off. By the 24th rotation it could be off by a considerable amount. Rotating at say maybe 12:10:37 instead of the expected time of 12:00:00.
It would be nice if there was an option to rotate at specific times. A cron like time specifier (minute hour, day, etc.). Or at least grab the current time at tcpdump launch and base the n seconds on that rather then first packet captured time. Or maybe subtract the time between launch/rotation to first packet capture.
tcpdump version 4.9.2
libpcap version 1.5.3
The text was updated successfully, but these errors were encountered: