Here is some additional debugging. I stuck this in an strace (tshark -ni eth5 -c1 ) and I don't even see it
attempt to remove the /tmp/etherXXXX . In contrast, I did the same thing on my hosts that
are running 99.5 and they don't ever attempt to even reference the temp files (see straces below).
Another thing I noticed is that if I do a tshark -v on my hosts that run 99.5 I see this:
tshark -v
No log handling enabled - turning on stderr logging
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
Cannot find module (UDP-MIB): At line 0 in (none)
Cannot find module (SNMPv2-MIB): At line 0 in (none)
Cannot find module (SNMPv2-SMI): At line 0 in (none)
Cannot find module (UCD-SNMP-MIB): At line 0 in (none)
TShark 0.99.5
Note the "No log handling enabled". What does this mean? Is perhaps the reason for the
difference in behavior? This is the stock version that centOS 5.0 came with. I do not see this with
the 99.7 package which is what gets installed if I do a yum update.
strace on 99.7 (tmp file leftover) starting from the "capturing" print statement:
write(2, "Capturing on eth5\n", 18Capturing on eth5) = 18
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=25464, ...}) = 0
mmap(NULL, 25464, PROT_READ, MAP_SHARED, 5, 0) = 0x2aaab37c5000
close(5) = 0
futex(0x34a4d4af18, FUTEX_WAKE, 2147483647) = 0
pipe([5, 6]) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaaac9490) = 3429
close(6) = 0
read(5, "F\0\0\25", 4) = 4
read(5, "/tmp/etherXXXXsPkS2t\0", 21) = 21
stat("/tmp/etherXXXXsPkS2t", {st_mode=S_IFREG|0600, st_size=114, ...}) = 0
open("/tmp/etherXXXXsPkS2t", O_RDONLY) = 6
fcntl(6, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(6, {st_mode=S_IFREG|0600, st_size=114, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab37cc000
lseek(6, 0, SEEK_CUR) = 0
read(6, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377377\0\0\1\0\0\0\311\234\204H\324=\7\0"..., 16384) = 114
read(6, "", 12288) = 0
lseek(6, 0, SEEK_SET) = 0
read(6, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0\311\234\204H\324=\7\0"..., 4096) = 114
lseek(6, 0, SEEK_SET) = 0
read(6, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0\311\234\204H\324=\7\0"..., 4096) = 114
read(6, "", 4096) = 0
lseek(6, 0, SEEK_SET) = 0
read(6, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0", 24) = 24
open("IOR.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
read(5, "P\0\0\2", 4) = 4
read(5, "1\0", 2) = 2
read(6, "\311\234\204H\324=\7\0J\0\0\0J\0\0\0\0\33\r\355<\200\0\27\313\26Fy\10\0E\20"..., 4096) = 90
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab37cd000
write(1, " 0.000000
87.88.130.113 -> 72.5"..., 125) = 125
read(5, "D\0\0\2", 4) = 4
read(5, "0\0", 2) = 2
read(5, "", 4) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3429
write(2, "1 packets captured\n", 191 packets captured) = 19
close(6) = 0
munmap(0x2aaab37cc000, 4096) = 0
munmap(0x2aaaaf72e000, 593920) = 0
exit_group(0) = ?
Strace on 99.5 with NO temp file left over:
write(2, "Capturing on eth5\n", 18Capturing on eth5) = 18
recvfrom(4, "\0\33\r\3458\300\0\220i\351\343\360\10\0E\0\0(\371O@\0"..., 65535, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if7, pkttype=PACKET_OTHERHOST, addr(6)={1, 009069e9e3f0}, [18]) = 60
ioctl(4, SIOCGSTAMP, 0x7fff54095330) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab2daf000
write(1, " 0.000000
190.80.231.250 -> 209"..., 93) = 93
getsockopt(4, SOL_PACKET, PACKET_STATISTICS, "A\6\0\0Q\5\0\0", [8]) = 0
write(2, "1361 packets dropped\n", 211361 packets dropped) = 21
close(4) = 0
write(2, "1 packets captured\n", 191 packets captured) = 19
munmap(0x2aaaac8c7000, 434176) = 0
exit_group(0) = ?
Process 7006 detached
On Mon, Jul 21, 2008 at 10:05 AM, Dan Murphy <
danmurphy@xxxxxxxxx> wrote:
same results. Files are left behind in /tmp
On Mon, Jul 21, 2008 at 9:49 AM, Luis EG Ontanon <
luis@xxxxxxxxxxx> wrote:
Have you tried to run it as an unprivileged user?
(dumpcap should be setuid-root making sure that the
unprivileged-user's group can run it, it is designed to run like
that).
Does it forget to erase the files then?
\Lego
On Mon, Jul 21, 2008 at 3:18 PM, Dan Murphy <
danmurphy@xxxxxxxxx> wrote:
> permissions on /tmp
> drwxrwxrwt 4 root root 2584576 Jul 21 13:11 /tmp
>
> permissions on the file do not change from during capture to after:
> -rw------- 1 root root 35590 Jul 21 13:11 etherXXXXLraXXe
>
> umask:
> 0022
>
> id:
> uid=0(root)
>
>
> Thanks,
> Dan
>
> On Mon, Jul 21, 2008 at 7:56 AM, Luis EG Ontanon <
luis@xxxxxxxxxxx> wrote:
>>
>> Lets get on this:
>>
>> What are the perms on:
>> - /tmp
>> - the /tmp/XXXX files while capturing
>> - the /tmp/XXXX files once left there
>>
>> Are you running as root or as an unpriviledged user [ id -a ]?
>> What's your [ umask ]?
>>
>> \Lego
>>
>>
>> On Mon, Jul 21, 2008 at 5:43 AM, Dan Murphy <
danmurphy@xxxxxxxxx> wrote:
>> > I'm running CentOS 5.0 X64 on all these hosts.
>> > #uname -a
>> > Linux lmon1.mia1.plx 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:28 EDT
>> > 2007
>> > x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > No matter how it exits it leaves
>> > these files behind. I pasted this in a previous email but even just
>> > running
>> > it like this:
>> > #tshark -ni eth5 -c 5
>> > It captures 5 packets then exists cleanly leaving the temp file behind.
>> > If
>> > I don't use the count
>> > and just ^C it leaves them behind as well.
>> >
>> >
>> > Thanks,
>> > Dan
>> >
>> > On Sun, Jul 20, 2008 at 11:28 PM, Stephen Fisher
>> > <
stephentfisher@xxxxxxxxx>
>> > wrote:
>> >>
>> >> On Sat, Jul 19, 2008 at 12:26:46PM -0400, Dan Murphy wrote:
>> >>
>> >> > Am I the only person that has reported this behavior or the only
>> >> > person that it's actually become an issue for? Is this the expected
>> >> > behavior of tshark?
>> >>
>> >> Wireshark/tshark is supposed to clean up these temporary files after it
>> >> is done with them. They've been a part of Wireshark/Ethereal for a
>> >> long
>> >> time, including version
0.99.5. I don't see the problem on my system,
>> >> although it is saving the temporary files into /var/tmp instead of /tmp
>> >> as in your case. How are you terminating tshark? A ^C for me allows
>> >> for the cleanup of the temporary file. What type of Unix are you
>> >> running?
>> >>
>> >>
>> >> Steve
>> >> _______________________________________________
>> >> Wireshark-users mailing list
>> >>
Wireshark-users@xxxxxxxxxxxxx
>> >>
https://wireshark.org/mailman/listinfo/wireshark-users
>> >
>> >
>> > _______________________________________________
>> > Wireshark-users mailing list
>> >
Wireshark-users@xxxxxxxxxxxxx
>> >
https://wireshark.org/mailman/listinfo/wireshark-users
>> >
>> >
>>
>>
>>
>> --
>> This information is top security. When you have read it, destroy yourself.
>> -- Marshall McLuhan
>> _______________________________________________
>> Wireshark-users mailing list
>>
Wireshark-users@xxxxxxxxxxxxx
>>
https://wireshark.org/mailman/listinfo/wireshark-users
>
>
> _______________________________________________
> Wireshark-users mailing list
>
Wireshark-users@xxxxxxxxxxxxx
>
https://wireshark.org/mailman/listinfo/wireshark-users
>
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-users
