使用Ubuntu，我试图将tcpdump嗅探与来自客户端设备的自我识别“ping”进行同步。 问题在于，通过看起来像tcpdump中的内置延迟，获得精确的启动和停止是困难的。 以下是我的脚本中的关键字：
sudo timeout .5s tcpdump -i wlan0 -e 当我设置超时停止tcpdump（比如在我的例子中）时，比如半秒，没有数据包被返回。 实际上，低于1.1s的任何值都不能返回数据包（而1.1和更长的时间则工作得很好）。
我已经尝试添加-n参数来禁止DNS，但没有任何区别。 我也试过这两个完全不同的WiFi卡（英特尔迅驰和TP-Link N900），以确保它不只是一个硬件“function”。
我不是一个开发人员，但我grep的tcpdump源代码的“延迟”，“延迟”，“超时”，但没有出现这似乎是负责任的。
有任何想法吗？
gnu coreutils timeout.c对没有timer_settime（）的系统有一个回退 – 它将恢复到一秒钟的分辨率：
/* timer_settime() provides potentially nanosecond resolution. setitimer() is more portable (to Darwin for example), but only provides microsecond resolution and thus is a little more awkward to use with timespecs, as well as being deprecated by POSIX. Instead we fallback to single second resolution provided by alarm(). */
也许这就是你的问题。 我不运行Ubuntu的，所以我不能检查第一手，但例如我的openbsd机器只有setitimer（），所以它只会使用全秒钟超时
– 编辑：第二看，它仍然应该等待至less1秒，除非它四舍五入…或以某种方式tcpdump正在得到一个早期的sigterm …也许在间隔期间只有没有数据包？
添加-l到tcpdump选项有帮助吗？ 它使tcpdump行的标准输出缓冲，使得每一行在接收到时立即输出，而不是在输出之前缓冲更多的数据。
默认情况下，tcpdump将尝试在正在通信的IP地址上执行反向DNS查找。 如果tcpdump没有得到对这种DNS查询的响应，那么延迟一秒钟听起来像是一个合理的超时。
将-n添加到tcpdump命令行将禁用DNS查找。 如果将命令更改为： sudo timeout .5s tcpdump -ni wlan0 -e有帮助吗？
我无法重现你的问题。 如果我启动ping -i 0.3 google.com ，然后运行timeout .5s tcpdump -i wlan0 -e我看到了stream量。
Tshark支持在不同的条件下停止捕捉，包括经过的时间。 你可以试试
tshark -a duration:1 -i wlan0 tshark -a duration:2 -i wlan0
如果他们两个显示交通，问题可能是kasperdbuild议的。 如果第一个没有显示stream量，但是第二个显示stream量，那么问题可能出在您的networking硬件或驱动程序上。