Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've been experimenting with tcpdump, and I've found some very bizarre filesystem behavior. It doesn't look to be a tcpdump problem as I'll explain in a second.

The following command produces no file:

tcpdump -w test.pcap

Yet this command produces the PCAP file as expected:

tcpdump -w - > test.pcap

At first I figured that tcpdump must be encountering some error when writing the file that the shell wasn't, so I straced and found that the writes were occurring just fine!

open("test.pcap", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff9bf5cb000
rt_sigaction(SIGUSR1, {0x4557d0, [], SA_RESTORER, 0x7ff9bea2ab60}, {SIG_DFL, [], 0}, 8) = 0 
write(2, "tcpdump: ", 9tcpdump: )                = 9 
write(2, "listening on eth0, link-type EN1"..., 73listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes) = 73
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0001\2\210P\34\3\3\0"..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\232\241\4\17X\213\f9+\225\35\t\364QF\223\242\7\217Y\226\373l\231vQ\354\223\250i\336."..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\34\226\346%\354\210\342\331\377\373\222d\261\0\5\207wX\6i`\0U\260\350\260\300\250\0\16\335\241"..., 4096) = 4096

test.pcap gets opened as file descriptor 4, and then several writes occur to that descriptor with the syscall reporting that the requested number of bytes was in fact written.

Even so, no file is created. I scoured the filesystem for test.pcap and found nothing.

What could produce this behavior?

tcpdump version 4.3.0
libpcap version 1.3.0
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Linux persephone 3.4.9-gentoo #1 SMP Wed Oct 3 10:02:39 EDT 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux
share|improve this question
1  
Q: "What could produce this behavior?" A: "A bug or broken hardware". That probably wasn't useful. But, you need to tell us the basic system details for us to have any hope of being useful. Like, say, what filesystem is this? –  derobert Oct 24 '12 at 17:55
    
Are you sure you're looking in the right directory? Might tcpdump's current directory be in some weird state, like shadowed by a mount? –  Gilles Oct 24 '12 at 21:59
    
@derobert I tried to include all the relevant info; of course I'd forget the filesystem. It's JFS. –  Michael Shick Oct 24 '12 at 22:39
    
@Gilles I searched the whole filesystem for the pcap file to no avail. The shadowing idea is interesting, but nothing is being mounted in the meantime. –  Michael Shick Oct 24 '12 at 22:47
    
@MichaelShick Can you reproduce this? Even if you run tcpdump in a different directory? –  Gilles Oct 24 '12 at 22:49

1 Answer 1

up vote 2 down vote accepted

tcpdump is doing something else to the file. You don't say what the full command-line is; perhaps you have a -G in there.

Possible ways to investigate further:-

  1. Keep looking through the strace output: maybe you'll find a rename or unlink.
  2. While tcpdump is running, run ln test.pcap pin.test.pcap and you'll be able to tell if the file was unlinked later.
  3. While tcpdump is running, find its process ID and ls -l /proc/${pid}/fd to see if you can spot the link to the open file's full pathname. (This is the approach that actually worked, from @Gilles' comment.)
share|improve this answer
    
I did post the full command line in both cases; no extra arguments to worry about. Nothing but write()s to the descriptor. No close(), but I can't imagine that's it. Finally I like the link idea, but it fails because the file doesn't exist at any point. –  Michael Shick Oct 24 '12 at 22:40
1  
@MichaelShick What does ls -l /proc/12345/fd show while tcpdump is running, where 12345 is the PID of tcpdump? –  Gilles Oct 24 '12 at 22:49
    
@Gilles That's it! 4 -> /var/lib/tcpdump/test.pcap I guess updatedb && locate 'test.pcap' didn't pick up on it. Also thanks for a new trick for my Linux diagnosis arsenal! –  Michael Shick Oct 25 '12 at 0:51
    
@MichaelShick for future reference, the best way to search the entire filesystem is with find. Many locate implementations hide files which aren't visible to all users. –  derobert Oct 25 '12 at 5:27
    
@derobert normally I do use find, it was a clumsy oversight on my part. That locate behavior makes a lot of sense, actually. Thanks. –  Michael Shick Oct 25 '12 at 13:23

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.