search

nmap / npcap

Nmap Project's Windows packet capture and transmission library
https://npcap.com
Other
2.96k stars 511 forks source link

Update Npcap to use latest libpcap trunk #471

Closed fyodor closed 3 years ago

fyodor commented 8 years ago

Right now Npcap is based on an old version of libpcap which was in WinPcap 4.1.3. And that is Libpcap 1.0.0 which was released in 2010. We should try to merge in all the libpcap changes since then into our branch, but it may be a large project.

hsluoyz commented 8 years ago

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.

hsluoyz commented 8 years ago

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: https://github.com/nmap/npcap/commit/b400111b365dd6397329f01c6b9086fb215f7210 https://github.com/nmap/npcap/commit/5d84de40271d08c173563c3c53d1484132a13478

Update

https://github.com/nmap/npcap/commit/b400111b365dd6397329f01c6b9086fb215f7210: Nmap still uses the pcap_int.h to directly call Packet functions. So this commit is not needed. https://github.com/nmap/npcap/commit/5d84de40271d08c173563c3c53d1484132a13478: We have decided to delete the pcap_get_servicename function.

So this work is finished.