On Jul 20, 2004, at 5:05 AM, Tomas Kukosa wrote:
Hello WinPcap team,
have not you thought about any common way for support of other than NDIS drivers?
Yes, they have - I think 3.1 beta has support for Endace DAG cards as well.
But is is the support only for one specific driver.
I ment some way of extensions which does not need neither WinPcap changes nor WinPcap recompilation.
Note also that libpcap 0.8 has at least some hooks for that - a pcap_t has pointers to functions to use to perform various functions.
My ideas are (see attached file):
PowerPoint isn't necessarily the best format for that purpose, although fortunately I'm at work now and we have a site license for Office for OS X.
The PDF is attached too for non-Windows WinPcap users :-). (Yes I know that some parts are common with libpcap.)
1) support for user extension drivers providing the same interface as npf.sys
2) support for user extension DLLs providing the interface similar to calling npf.sys with CreateFile/CloseHandle/ReadFile/WriteFile/DeviceIoControl functions
Doing that in libpcap would probably be possible (and wouldn't require that the drivers behave similarly to npf.sys), but it wouldn't expose those devices through packet.dll. Packet.dll is, I think, primarily considered a "helper library' for WinPcap, rather than an API that people should be using, so that might be OK.
I thought about extensions for the WinPcap not for the libpcap.
The other possibility would be to create any API from WinPcap.dll/libpcap to extension libraries but it would required many changes.
The proposed way requires least changes in the WinPcap (I made some of that changes for version 2.3).
3) mapping of rpcap devices to dummy local devices (it is not real extension)
What's the reason for doing that?
e.g. - the application using WinPcap does not support rpacap - you want to see some remote adapter in your local list because you use it very often - you do not want to disturb user with choosing of remote adapter
wpcap_ext.pdf
Description: Adobe PDF document
