mailing list archives
Re: [Patch] Resubmitting: Upgrade libpcap to 1.5.3
From: Jay Bosamiya <jaybosamiya () gmail com>
Date: Thu, 20 Mar 2014 12:20:08 +0530
On 19 Mar 2014 23:07:18 +0100, Gisle Vanem wrote:
It seems the lack of response on your diffs (here on dev () nmap org) has
(1) something to with the size of your diffs. Almost 1 MByte uncompressed!
E.g. diffs of libpcap/scanner.c and libpcap/grammar.c are totally
unneededsince those files are generated from libpcap/scanner.l and
The main chunk of the diffs is from the 1.5.3 update.
I haven't written those. I have only written the changes to
libpcap/NMAP_MODIFICATIONS. This is there in my older mail . I have
also put that up as a github gist now .
The big patch  is just me running all the steps of the smaller patch .
So for reviewing the patch, it is necessary only to see  but to make
the process painless to patch, there is .
Nope, no private replies. But btw, "Reply to all" is a useful thing and
I've been using that in Thunderbird. It automatically puts dev () nmap
org into the Cc list for me.
(2) Or. I don't know if you got some private replied to your patches. It's hard to tell
since the way this mailing-list is setup; there is no 'Reply-to:'
header. Hence manymailers (including my good old Outlook Express) send
a reply (by default) to the'From:' (i.e. you) address. So a discussion
could easily die out quickly.
I have looked into that page. In fact I was thinking that it
(parallelized Nmap's forwad DNS) could be part of my SoC project.
I am polishing up my proposal right now, and will post to the list for
feedback (just hope it's not too late for any reviews).
(3) Since there's no bug-tracker, it's possible that good ideas and bug-report gets
forgotten or simply ignored due to lack of time or interest from the maintainer(s).
Your guess is as good as mine.
But there are other important ideas here:
(not only athttps://svn.nmap.org/nmap/todo/nmap.txt)
Especially the "parallelized Nmap's forward DNS". It would be nice to
have C-ares,GNU-adns or some other DNS-lib do this. No need to
reinvent the wheel. Butmaybe someone is afraid of yet another external
dependency. I cannot see any
problem with that.
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/