tcpdump write problems in FC4

I just installed FC4 for the first time this weekend. I used FC2 and FC3
pretty regularly, but each release seems to have a weird configuration
change. Anyway, this may be one of those changes. I have a second network
interface set up that i want to capture to a pcap file. I tried running
tcpdump on it and it runs fine:

output (ip's sanatized):
[root@local ~]# tcpdump -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
22:37:06.222272 arp who-has 10.10.17.197 tell 10.10.16.1
22:37:06.228675 IP 10.10.21.155.1079 > ns.asdf.co.asdf.asdf.net.domain:
25359+ PTR? 10.10.255.69.in-addr.arpa. (44)
22:37:06.232918 IP 10.10.21.155.11126 > asdf.dca.asdf.com.nntp: . ack
3694111060 win 1295

....

but when i try to write to a text file it makes a blank file:

[root@local ~]# tcpdump -i eth1 > ./test.dump

also, when i try to write a binary file i get a permission error

[root@local ~]# tcpdump -i eth1 -w ./test.dump
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: test.dump: Permission denied

i'm running it as root and tried saving in my home directory and in the
/var/log directory. tcpdump v: 3.8 and libpcap version 8.3

Does anyone know what could be causing this? I can give u anymore data if
you need it.

Thanks!

Hello,

> I tried running tcpdump on it and it runs fine:
> # tcpdump -i eth1
> [...]
> 22:37:06.222272 arp who-has [...]
Ok, it works.

> but when i try to write to a text file it makes a blank file:
> # tcpdump -i eth1 > ./test.dump
Perhaps, the number of characters to display was not sufficient (less
than 4k for example), so tcpdump did not flush stdout. Try capturing a
lot of packets (for example downloading a file, or using ping -f), to
see if you encounter the same problem.

> also, when i try to write a binary file i get a permission error
> # tcpdump -i eth1 -w ./test.dump
Previous example created test.dump owned by root. Some implementations
of tcpdump drop their privileges to pcap user. So, "-w" option tries to
write as pcap user to a file owner by root.

Please note I don't have FC4 at hand, so I can't confirm these ideas.

Regards,
Laurent Constantin
http://vigilance.aql.fr/ for vulnerabilities
http://www.laurentconstantin.com/ for network tools

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Hello,
>
>> I tried running tcpdump on it and it runs fine:
>> # tcpdump -i eth1
>> [...]
>> 22:37:06.222272 arp who-has [...]
> Ok, it works.
>
>> but when i try to write to a text file it makes a blank file:
>> # tcpdump -i eth1 > ./test.dump
> Perhaps, the number of characters to display was not sufficient (less
> than 4k for example), so tcpdump did not flush stdout. Try capturing a
> lot of packets (for example downloading a file, or using ping -f), to
> see if you encounter the same problem.
>
>> also, when i try to write a binary file i get a permission error
>> # tcpdump -i eth1 -w ./test.dump
> Previous example created test.dump owned by root. Some implementations
> of tcpdump drop their privileges to pcap user. So, "-w" option tries to
> write as pcap user to a file owner by root.
>
> Please note I don't have FC4 at hand, so I can't confirm these ideas.

Great, that got me started. I didn't realize it drops to the rights of
'pcap' user. I am able to use the '-w file' argument. However, i still
can't save the text file. It seems the root user creates the file, and then
tcpdump drops to pcap rights and then it can't write to it. So the
directory is owned by pcap, has 777 rights, but when root creates the file,
pcap can't write to it. Is there any way to get around this?

Thanks,

Hello,

> So the directory is owned by pcap, has 777 rights, but
> when root creates the file, pcap can't write to it.

The good solution would be to get in touch with people having FC4, or
with tcpdump maintainer for FC4.

The bad solution is to use one of these tricks:

Perhaps, setting "umask 0000" before running tcpdump. Then, it has to
be reseted.

Perhaps, creating test.dump owned by pcap before running tcpdump.

Perhaps, editing /etc/passwd to change userid of pcap to 0. This is a
very bad trick, because a vulnerability in tcpdump and Ethereal can be
fatal.

If you have development experience, run "strace tcpdump ..." to see
what the problem is really.

Regards,
Laurent Constantin
http://vigilance.aql.fr/ for vulnerabilities
http://www.laurentconstantin.com/ for network tools

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Hello,
>
>> So the directory is owned by pcap, has 777 rights, but
>> when root creates the file, pcap can't write to it.
>
> The good solution would be to get in touch with people having FC4, or
> with tcpdump maintainer for FC4.
>
> The bad solution is to use one of these tricks:
>
> Perhaps, setting "umask 0000" before running tcpdump. Then, it has to
> be reseted.
>
> Perhaps, creating test.dump owned by pcap before running tcpdump.
>
> Perhaps, editing /etc/passwd to change userid of pcap to 0. This is a
> very bad trick, because a vulnerability in tcpdump and Ethereal can be
> fatal.
>
> If you have development experience, run "strace tcpdump ..." to see
> what the problem is really.

piping the command with 'tee' works. Is there a linux utility that stores
the stdin as a file, but does not display it in stdout?

In article <h92dnUHtw-7OYqTeRVn-(E-Mail Removed)>,
"matt" <(E-Mail Removed)> writes:
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
>> Hello,
>>
>>> So the directory is owned by pcap, has 777 rights, but
>>> when root creates the file, pcap can't write to it.
>>
>> The good solution would be to get in touch with people having FC4, or
>> with tcpdump maintainer for FC4.
.....
>> If you have development experience, run "strace tcpdump ..." to see
>> what the problem is really.
>
> piping the command with 'tee' works. Is there a linux utility that stores
> the stdin as a file, but does not display it in stdout?

dd of=whatever

would be my fist choice if I wanted something other than the shell to
copy stdin to a file called "whatever".

--
Tim Clark