[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] XORP, Win32, libpcap, and MSVCRT.DLL
From:       Guy Harris <guy () alum ! mit ! edu>
Date:       2005-06-07 21:25:09
Message-ID: B64EA248-D6A4-4D5E-A7B5-179C95BE0544 () alum ! mit ! edu
[Download RAW message or body]


On Jun 7, 2005, at 3:49 AM, Bruce M Simpson wrote:

>  1) Compatibility of WinPcap vs libpcap -- it would be nice if we
>     could build both Win32 and UNIX versions from the same libpcap  
> tree,
>     but this is something we can work around at XORP makefile level;

Build Win32 and UNIX versions of XORP, or of libpcap?

If libpcap, what are the problems that prevent using standard libpcap/ 
WinPcap, built (if necessary) and installed (if necessary) from their  
source trees?

>     as I understand it from the current thread, WinPcap and libpcap  
> are
>     pretty much separate projects -- it would be nice if they could be
>     re-integrated in the same way as libevent and libdnet are.

"Re-integrated" in what sense?

The WinPcap developers track what's done in libpcap, and contribute  
back their changes to the shared portions of the code.

However, unlike UN*Xes, which have a native packet capture mechanism  
that libpcap uses, Windows doesn't - WinPcap also includes drivers  
for Windows OT (95, 98, Me) and NT (NT4, W2K, WXP, W2K3) and  
libraries that talk to the driver, with the actual libpcap portion  
implemented atop the API provided by the library.

"Re-integrating" them would involve incorporating the driver and  
libraries into libpcap - you'd have to ask the WinPcap developers if  
that'd be acceptable - or having separate "packet driver" and  
"libpcap" projects, with the former being the driver and library for  
the driver.  However, that'd run the risk of making the "packet  
driver" API a published API, and the WinPcap developers don't want  
that - they want to be able to change that API from release to  
release, if necessary, with the libpcap code changed to match.

It appears that libevent doesn't need to make additions of that sort  
to Windows.  Libdnet handles that by assuming that the "packet  
driver" API is a published API; if it changes in a future WinPcap  
version, libdnet runs the risk of breaking.

>  2) Support for link-layer frame injection across most UNIX  
> platforms and
>     Win32 using libpcap.

WinPcap's had that for a while; I checked support for that on UN*X  
platforms into libpcap a while ago.

> So basically to make that happen we need a libpcap which is portable
> to Windows

The current libpcap source is probably portable to "Windows+the  
WinPcap driver and library", or could be made so; it's not portable  
to Windows without the driver and library (well, I guess you could  
use it to read and write savefiles, but that's about it).

> and is capable of link layer writes.

WinPcap is capable of that, and libpcap 0.9 will be capable of that  
as well.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[prev in list] [next in list] [prev in thread] [next in thread]