Bash – One second delay before tcpdump returns packets

bashlinux-networkingtcpdumpwifi

Using Ubuntu, I'm trying to sync tcpdump sniffing with self-identifying "pings" from a client device. The problem is that getting precise starts and stops is made difficult by what looks like a built-in delay in tcpdump. Here's the key line from my script:

sudo timeout .5s tcpdump -i wlan0 -e

When I set timeout to stop tcpdump after, say, half a second (as in my example), no packets are returned. In fact, any value lower than 1.1s fails to return packets (while 1.1 and longer work wonderfully).

I've tried adding the -n argument to suppress DNS but that made no difference. I also tried this with two entirely different wifi cards (Intel Centrino and TP-Link N900) to make sure that it wasn't just a hardware "feature".

I'm not a developer, but I grep-ed the tcpdump source code for "delay", "latency", and "timeout" but nothing came up that seemed responsible.

Any ideas?

Best Answer

gnu coreutils timeout.c has a fallback for systems without timer_settime() - it will revert to single-second resolution:

/* 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().  */

perhaps thats your issue. i don't run ubuntu so i can't check firsthand, but for example my openbsd machine only has setitimer(), so it would only use full-second timeouts for me

--edit: on second look it still should wait atleast 1 second, unless its rounding down...or somehow tcpdump is getting an early sigterm ...and maybe there are just no packets during the interval?

Related Topic