Hi,
----- Original Message -----
From: "Guy Harris" <[EMAIL PROTECTED]>
To: "Loris Degioanni" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "winpcap"
<[EMAIL PROTECTED]>
Sent: Thursday, September 20, 2001 10:38 PM
Subject: Re: [tcpdump-workers] windump and winpcap
> > ... 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.
I'm meaning only the former. We plan to keep on the work on the drivers and
the low-level dlls, but I think that the integration of our changes of
libpcap and tcpdump would allow a better synchronization of the windows
version and would require less (often unuseful) work on our side.
> > 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.
Yes, sorry. "pcap-win32.c" is actually in the top-level libpcap directory
for coherence with the libpcap source-code structure.
> > - 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()".
So, you mean that it is better to put the other functions inside libpcap,
for example in pcap-win32.c?
> "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.
Yes, but libpcap is by definition a library to do "bad" things. :-)
Seriously, we added this function because we often need raw packets
generation for our tests, and at the moment there is not an 'official'
method to generate packets that works on all the Win32 platforms (raw
sockets are supported only by win2K/winXP).
> "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.
I think that solution number 2 is better for portability of libpcap-based
prgrams.
> "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]".)
Ok,
I'm going to let the beta versions of winpcap and windump on the web for
some days, in order to see if they have macroscopic bugs. Then I will
proceed to create the patches.
Loris.
> -
> 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
-
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
