> ... I'm asking if you are interested in joining the win32 code with the
> sources of tcpdump and libpcap.
Are you suggesting that we pick up only the changes to tcpdump and
libpcap, or are you also suggesting that we pick up the drivers and
packet.dll?
The former makes sense to me; the latter, though, might not make as much
sense, as you're probably better maintainers of that lower-level stuff
than tcpdump.org are.
> Consider that:
> - the win32 code can be easily located, because the new files are in the
> win32 subdirectories and the changes to the original files are inside
> "#define WIN32" statements
Actually, I'd be inclined to have "pcap-win32.c" in the top-level
libpcap directory, along with the other "pcap-XXX.c" files.
> - the win32 extensions to libpcap (that include functions like pcap_setbuff)
> are kept in a separate, independent file.
The only one of the functions listed at
http://netgroup-serv.polito.it/winpcap/docs/pcapman.htm#wpcap
that's truly Win32-specific is "pcap_getevent()".
"pcap_sendpacket()":
int pcap_sendpacket(pcap_t *p, u_char *buf, int size) this
simple function allows to send a raw packet to the network using
wpcap instead of accessing directly the underlying APIs. p is
the interface that will be used to send the packet, buf contains
the data of the packet to send (including the various headers),
size is the dimension of the buffer pointed by buf. The MAC CRC
needs not to be calculated and added to the packet, because it
is transparently put after the end of the data portion by the
network interface.
could probably be implemented fairly easily in most, if not all, of the
UNIX "pcap-XXX.c" files as well. About the only reason I could see
*not* to do that would be worries that it'd make it easier for people to
write programs to put Bad Packets on a network.
"pcap_setbuff()":
pcap_setbuff() sets the size of the driver's circular buffer
associated with the adapter p to dim bytes. Return value is 0
when the call succeeds, -1 otherwise. If an old buffer was
already created with a previous call to pcap_setbuff(), the old
buffer is deleted and the packets contained are discarded.
Using pcap_open_live() to open an adapter, the associated buffer
is 1MB by default.
if you replace "the driver's circular buffer" with "the buffering
provided by the packet capture mechanism") could be implemented on at
least some other platforms - for example, on Linux and IRIX, where the
raw-capture device is a socket, it might correspond to an SO_RCVBUF
"setsockopt()" call.
Unfortunately, it can't be implemented on systems using BPF, even though
BPF has an ioctl to set the buffer size on the BPF device, as that ioctl
can only be done before the BPF device is bound to a network interface,
and "pcap_open_live()" binds the device to the specified interface.
To fix that, we'd need a "pcap_open_live_extended()" call, or something
such as that, taking a buffer-size argument.
So I'd be inclined either to
1) supply "pcap_setbuff()" only on platforms where it can be
implemented
or
2) supply, on platforms where it can't be implemented, a version
that returns -1 and sets "errno" to something such as EINVAL.
"pcap_setmode()" and "pcap_setmintocopy()" aren't Win32-specific -
they're currently specific to the WinPcap capture mechanism, but other
OSes could conceivably implement them. They'd be Win32-only, unless and
until other capture mechanisms implement them.
> If you think that the win32 code can be included, I can upgrade the porting
> to the latest CVS snapshot and then send you the patches.
I think the Win32 changes to tcpdump and libpcap can be included. (If
you send me the patches, send them to "[EMAIL PROTECTED]" rather than to
"[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
