[tcpdump-workers] Adding loopback adapter detection for Windows
hsluoyb at gmail.com
Mon Jan 25 07:19:22 EST 2016
I successfully built libpcap on Windows using CMake 3.4.1 and generated
wpcap.dll, but it is unusable: After I substitute my built wpcap.dll with
the original wpcap.dll in Npcap/WinPcap. Wireshark said: "Unable to load
WinPcap (wpcap.dll); you will not be able to capture packets". So I think
there must be anything wrong with my build process.
My libpcap is latest trunk, path is J:\npcap\wpcap\libpcap.
Here're my steps:
1) Modified the CMakeLists.txt Line 3 from
set( PROJECT_NAME pcap )
set( PROJECT_NAME wpcap )
I thought the output binary should be wpcap.dll instead of pcap.dll, so I
just changed it, I don't know if this is the correct move..
2) Open the GUI of CMake 3.4.1, source path is: J:/npcap/wpcap/libpcap,
build binary path is: J:/npcap/wpcap/PRJ. Compiler is: Visual Studio 8
2005. Then I clicked "Configure" button and "Generate" button. Logs are
The C compiler identification is MSVC 14.0.50727
The CXX compiler identification is MSVC 14.0.50727
Check for working C compiler using: Visual Studio 8 2005
Check for working C compiler using: Visual Studio 8 2005 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 8 2005
Check for working CXX compiler using: Visual Studio 8 2005 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Use STATIC runtime
Packet capture mechanism type: win32
Find-interfaces mechanism type: win32
Lexical analyzer generator: C:/cygwin64/bin/flex.exe
Parser generator: C:/cygwin64/bin/bison.exe
3) Open the generated J:\npcap\wpcap\PRJ\wpcap.sln with MSVC 2005. Then
build the solution with configuration "Release" "Win32". (I don't know how
to generate both "Win32" and "x64" using CMake, it's inconvenient to only
have one platform in one sln).
4) Copied the built wpcap.dll to my Win8.1 x86 VM's system32 folder,
replaced the original wpcap.dll. It has Npcap/WinPcap installed beforehand.
Then got the error when launching Wireshark.
I think this is so smooth, not any porting job. Also I didn't use WinPcap
specific files like the Win32-Extensions folder, so I think my steps are
On Mon, Jan 25, 2016 at 3:04 AM, Guy Harris <guy at alum.mit.edu> wrote:
> On Jan 24, 2016, at 6:46 AM, Yang Luo <hsluoyb at gmail.com> wrote:
> > I have implemented a loopback adapter called "Npcap Loopback Adapter" on
> > Windows. It's like lo in linux. I know that libpcap recognizes "lo" by
> > matching the adapter name with "lo".
> ...*if* the OS doesn't helpfully provide, as one of the interface flags,
> $ ifconfig lo0
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff000000
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> nd6 options=1<PERFORMNUD>
> which is also provided by other BSD-flavored interfaces and, at least with
> newer kernels, Linux, and possibly other OSes.
> If the flag *isn't* specified, it checks whether the name is either "lo"
> or "lo" followed by a single digit.
> > So possible solutions are:
> > 1) Adding registry read code to libpcap, read the name of "Npcap Loopback
> > Adapter" and compare it with the value in the code.
> > 2) Call my provided PacketIsLoopbackAdapter. Unfortunately, as my Npcap
> > not a official successor of WinPcap. I can't expect anyone can statically
> > compile against my added PacketIsLoopbackAdapter function. Maybe
> > dynamically function load is needed (LoadLibrary and GetProcAddress).
> > 3) ..
> > Currently my way is like 2), except that I directly built libpcap against
> > my new function. My modification is:
> > I'm not sure which is the best practice to let libpcap recognize my
> > adapter. Any opinions? Thanks!
> On Windows, libpcap and packet.dll are somewhat tied together, in that
> there's no expectation or requirement that an arbitrary binary version of
> libpcap code will work with an arbitrary binary version of packet.dll.
> Normally, the libpcap code and packet.dll are distributed together in a
> single package; the binary interface that's kept stable is the libpcap ABI
> (which is also kept stable on UN*Xes), *not* the packet.dll interface.
> So if you're going to distribute an NPcap that's binary-compatible with
> WinPcap (possibly adding new APIs, and possibly enhancing old APIs, but not
> removing old APIs or changing them in an incompatible fashion), you could
> modify pcap-win32.c etc. as necessary. Please contribute those changes
> back to libpcap; it might be possible to have the CMake scripts for libpcap
> check whether packet.dll supports particular APIs and #ifdef out the code
> that uses those APIs if it's not present.
More information about the tcpdump-workers