Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

Does adding -l to tcpdump options help? It makes the standard output of tcpdump line buffered, so that every line is output as soon as it is received, instead of buffering more data before output.

share|improve this answer
1  
Great idea. Unfortunately, it made no difference - thanks. –  dlanced Apr 30 at 13:59

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?

share|improve this answer
    
Right now there are literally close to fifty devices broadcasting within range (we're testing tablets for a deployment), so I really doubt that nothing is coming through in that first second. –  dlanced Apr 30 at 14:05
    
I will explore your coreutils observation a bit more...thanks. –  dlanced Apr 30 at 14:05
    
I came across this, i won't lie i am completely unfamiliar with libpcap and its implementation, but you'll find it interesting: tcpdump.org/manpages/pcap.3pcap.html scroll to the part 'read timeout' - it seems your suspicion is correct, pcap implements a timeout - i don't know what its default is, its not set within tcpdump...from reading, it seems possible you're losing packets through this mechanism. sorry i can't be more helpful –  pete Apr 30 at 15:18
    
Thanks @pete. I also have to admit that I don't completely understand that section, but I appreciate the link. It's worth doing a bit of digging... –  dlanced Apr 30 at 16:22

By default tcpdump will attempt to perform reverse DNS lookups on the IP addresses, which are communicating. A one second delay sounds like a reasonable timeout in case tcpdump does not get a response to such DNS lookups.

Adding -n to the tcpdump command line will disable the DNS lookups. Does it help if you change the command into this: sudo timeout .5s tcpdump -ni wlan0 -e

share|improve this answer

I can't reproduce your problem. If I start ping -i 0.3 google.com and then run timeout .5s tcpdump -i wlan0 -e I see the traffic.

Tshark supports stopping a capture under different conditions, including elapsed time. You could try

tshark -a duration:1 -i wlan0
tshark -a duration:2 -i wlan0

If both of them show traffic, the problem is probably what kasperd suggests. If the first one does not show traffic but the second does, maybe the problem is with your network hardware or it's driver.

share|improve this answer
    
kasperd's suggestion "-ni" didn't improve the result. I've taken a quick look at tshark, but I'll have to wait until tomorrow to do it justice. Thanks to both of you! –  dlanced Apr 29 at 20:54
    
tshark -a duration:1 does show traffic, while timeout 1s tcpdump does not. Unfortunately, tshark only seems to handle whole integers for its duration value so it's not a replacement for tcpdump. –  dlanced Apr 30 at 14:31
    
Does timeout 1s tshark show traffic? Why is it important to capture for less than a second? –  sciurus Apr 30 at 15:31
    
I don't know why I didn't think of that: 'timeout .5s tshark' also shows traffic! This may be something to work with! (We're trying to increase our detection speed by coordinating pings and sniffs to fractions of a second...) –  dlanced Apr 30 at 16:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.