Update Npcap to use latest libpcap trunk about npcap HOT 2 CLOSED

Updating Npcap to use latest libpcap trunk is a necessary part for our long-term goal. However, we didn't come to an agreement on how to do it yet.

Current Npcap's libpcap code uses WinPcap 4.1.3's original part, which is based on libpcap version 1.0 branch 1_0_rel0b (20091008).

The official libpcap repository is also hosted on GitHub: https://github.com/the-tcpdump-group/libpcap, maintained by Guy. The latest version is 1.7.4.

We can view libpcap's code as two parts, the first part is OS-independent part. This part of code is general for all supported OSes (Linux, Windows, etc.). The second part is OS-dependent part. This part is only for the specific OS. Like pcap-win32.c, pcap-remote.c on Windows. The first part of code is much more than the second part.

However, because of some reason, the current libpcap trunk code is still not usable on Windows. So it can‘t be directly used on Npcap or WinPcap. It needs some modifications. As libpcap 1.7.4 has changed too many things than the original 1.0, it's impossible to add all new libpcap 1.7.4 features to Npcap's libpcap 1.0 code. The only workable way is to add back Windows support to the current libpcap 1.7.4 trunk. So we have two ways here.

1. Merge our modifications (including Windows support and Npcap support) to the official libpcap repo, then make the official libpcap repo a submodule of Npcap repo. The advantage is that Npcap will automatically receive all updates of the libpcap OS-independent part of code when the libpcap repo trunk updates. The disadvantage is that we don't have full control on the libpcap part of Npcap.
2. Fork a private branch of libpcap, make our modifications on this private fork, then make this private repo a submodule of Npcap repo. The advantage is that we have full control on the libpcap part of Npcap. The disadvantage is that we still need to manually merge all necessary changes from the official libpcap repo to our private branch. As the official libpcap repo doesn't have our modifications, their new changes won't consider our fork's existence and can be quite difficult to apply on our own fork.
3. based on method 1., we request to be one of the administrative members for the official libpcap repo. In this way, we can gain some sort of control on the libpcap repo.

I'm personally with 1. or 3. But we haven't reached an agreement yet, so still needs to be discussed.

from npcap.

This work has been done. And I released Npcap 0.08 for this improvement here: https://github.com/nmap/npcap/releases.

I used Nmap's libpcap fork's npcap branch as a submodule of the Npcap repo. This branch is based on the official libpcap's 1.8.0 release. And I have merged nearly all improvements from the original local libpcap source to this new repo.

Only two commits are still not merged yet:
b400111
5d84de4

Update

b400111: Nmap still uses the pcap_int.h to directly call Packet functions. So this commit is not needed.
5d84de4: We have decided to delete the pcap_get_servicename function.

So this work is finished.

from npcap.