6

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?

dlanced
  • 247
  • 1
  • 4
  • 13
  • Turns out it makes a difference exactly which Ubuntu version you are using. I found this problem exists in Ubuntu 14.04, but it does not exist in Ubuntu 12.04. Which exact version of Ubuntu are you using? – kasperd Jan 11 '15 at 14:25
  • Related: http://askubuntu.com/questions/570885/can-tcpdump-on-ubuntu-14-04-show-packets-in-real-time – kasperd Jan 11 '15 at 14:26
  • 1
    I had a similar issue. The following flag helped: `--immediate-mode`. Source: https://unix.stackexchange.com/questions/229327/sniffing-packets-realtime/229336#229336 – vasilyrud Feb 04 '19 at 18:45

4 Answers4

2

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

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • This answer was written before I was aware of the difference between libpcap behavior in Ubuntu 12.04 and Ubuntu 14.04. Now that I have upgraded some systems to Ubuntu 14.04 myself, I see the problem as well. My recommendation to try with `-n` still applies. But there is a more fundamental issue, which I do not yet have an answer for. – kasperd Jan 11 '15 at 14:24
2

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?

pete
  • 723
  • 1
  • 7
  • 16
  • 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 '14 at 14:05
  • I will explore your coreutils observation a bit more...thanks. – dlanced Apr 30 '14 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: http://www.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 '14 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 '14 at 16:22
2

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.

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
0

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.

sciurus
  • 12,678
  • 2
  • 31
  • 49
  • 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 '14 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 '14 at 14:31
  • Does `timeout 1s tshark` show traffic? Why is it important to capture for less than a second? – sciurus Apr 30 '14 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 '14 at 16:07