[tcpdump-workers] Adding loopback adapter detection for Windows

Guy Harris guy at alum.mit.edu
Sun Jan 24 14:04:09 EST 2016


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 just
> matching the adapter name with "lo".

...*if* the OS doesn't helpfully provide, as one of the interface flags, IFF_LOOPBACK:

$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
                   ^^^^^^^^
        options=3<RXCSUM,TXCSUM>
        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 is
> 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:
> https://github.com/nmap/npcap/commit/d18318c495578887829fce8cb366770d3b3c7616
> 
> 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 mailing list