Re: Adding loopback adapter detection for Windows

[Guy Harris <guy () alum mit edu>]

On Jan 24, 2016, at 6:46 AM, Yang Luo <hsluoyb () 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.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers