Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [Patch] Update libpcap to 1.5.3; Also discussion on whether we should really bundle 3rd party libraries or not
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 5 Jun 2014 15:12:21 -0500

Jay,

We need to do better checking on whether these issues have been addressed
upstream. Patch 0004-Include-netpacket-packet.h-before-pcap-bpf.h.patch for
instance was addressed in libpcap 1.4.1, as evidenced by this issue on
GitHub (https://github.com/the-tcpdump-group/libpcap/issues/306) and our
own CHANGELOG, which notes the upstream fix which was not in a release in
2008.

Patch 0003 was actually in response to a Valgrind bug, which has been fixed
in Valgrind upstream (
https://github.com/the-tcpdump-group/libpcap/issues/147 and
https://bugs.kde.org/show_bug.cgi?id=318203)

I've opened a pull request (
https://github.com/the-tcpdump-group/libpcap/pull/358) with upstream for
the --disable-packet-ring one, though I don't see how it affects Nmap
unless it's used for building the RPM binary packages for releases.

I also opened a pull request (
https://github.com/the-tcpdump-group/libpcap/pull/359) with upstream for
the pre-configure.patch issue on AIX. We'll see what they say.

Patch 0001 is simply to keep our SVN history clean, since folks with
different bison/flex versions could conceivably generate different files,
which would lead to unnecessary check-ins of "changes" to those files. When
you do rebuild those files with the new version of libpcap, please use
bison 2.5 or newer, since that is the version that was used with the
previous generation.

That said, I think that you can go ahead and commit the upgrade. You should
have pre-configure.patch, 0001-*.patch, and 0002-*.patch applied. If you
would like review on the modifications to those patches, please ask. Thanks
for your work!

Dan




On Thu, May 22, 2014 at 10:24 AM, Jay Bosamiya <jaybosamiya () gmail com>
wrote:

Hi all!

I wrote a patch in March that updates libpcap but it turned out to be too
large and so couldn't be reviewed and thus couldn't be committed.
Most of its size came from the updates in libpcap itself and I personally
had nothing to do in it.

In order to make it quite easy to review and for simplicity sake, I wrote
the patch as a small script that is bundled with the actual changes I made.
(script.sh and nmap_modifications.patch respectively).
I have attached the same as a compressed tar.gz.

To use the script, please extract the file to an empty directory and run
script.sh using bash. The script allows you to check out nmap, download
libpcap 1.5.3, runs the necessary changes (see nmap_modifications.patch)
and then generates a final patch file which can then be used on the latest
svn repo to update libpcap.

Note: You can test the downloaded libpcap file's signature here:
http://www.tcpdump.org/#latest-release to make sure that the download was
successful.

In order to review the patch, only reading the two files is needed and
testing can be done after running script.sh.

FYI, any tests that I ran after updating libpcap worked just fine. I was
testing on Ubuntu 14.04 (64 bit).



BTW, Looking at all the trouble that it takes to update a third party
library, both Gisle and Daniel have pointed out that we should actually be
having no need to bundle libpcap or any other 3rd party library for that
matter with Nmap.
Quoting Dan, "The basic question is, should we bundle readily-available
third-party libraries with Nmap? Sometimes we need to make modifications;
sometimes (like liblinear) the libraries are not readily available; but we
don't want to get into this problem of needing to keep them updated all the
time!"

What I suggest is that we should probably discuss this here and decide
whether we want to continue with these party libraries (and commit in this
update) or whether we should get rid of them (thus, not only reducing bloat
but also removing this trouble of updating).

I personally say that we should remove these libraries, even though I just
helped in updating one.

Hopefully we'll come to some sort of resolution on this soon. :)

Cheers,
Jay

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault