Guy Harris wrote:
> > The problem of converting the sniffer/spoofer to dump on stdout
> > directly
>
> ...but I wasn't suggesting that you do that.
>
> I was just suggesting that what it send over the TCP connection be a
> byte stream in tcpdump format.
I see your point -- looks like I didn't have my brain turned on last time.
The idea of using tcpdump archive format to communicate to the clients is
actually quite attractive. The only serious problem I see is the fact
that savefile.c uses FILE pointers instead of file descriptors. This
introduces the possibility of buffering that would need to be turned off
for me. Unfortunately, there is no way to access the FILE pointer of the
savefile unless you know that pcap_dumper_t* is actually a FILE*.
Another problem is the potential performance impact: pcap_dump() issues
two fwrite() calls to send the header and data portion of the packet; with
buffering disabled, this means two write() calls. A writev() would be
preferable.
The other issue I have is the one of generality. With your proposal, you
require that the input be in a certain predetermined format. With a
callback function, the user is free to do whatever he wants. You could
easily write your proposed pcap_fdopen() as a wrapper around a
callback-based solution; however, the reverse is not true.
In terms of required code changes, I think that a callback buys you a
cleaner implementation -- you can make the pcap_read() and
pcap_offline_read() functions static and access them via the callback --
this eliminates the `if (p->sf.rfile != NULL)' tests scattered around
libpcap and makes the code a bit cleaner. Of course, this is just my
opinion.
Uros
--
Uros Prestor
[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
