Re: Adding libdnet and libpcap to nbase (was: Status Report #5 of #15)

[David Fifield <david () bamsoftware com>]

On Thu, Jun 10, 2010 at 06:53:40PM -0700, Fyodor wrote:
> On Tue, Jun 08, 2010 at 09:21:41AM +0200, Luis MartinGarcia. wrote:
> > * Make it possible for nbase to use libdnet and libpcap.
> > * Try to move the rest of the code shared between Nmap and Nping
> >   to Nbase.
>
> While I can see how you would need to do that in order to share common
> tcpip code between nping and nmap, I'm a little bit skeptical of this
> idea.  I think of Nbase as a base library for portability stuff and
> core utility functions.  For example, it provides functions like
> getopt_long, inet_pton, inet_ntop, and snprintf for systems which
> don't offer them.  And it has some core utility functions for string
> processing, memory allocation, random number generation, etc.  For the
> random numbers, we pulled in OpenSSL code but didn't add a requirement
> for the OpenSSL library.

You're right, I agree this can be problematic. Particularly with pcap,
less so with dnet.

Some of the moved functions match the pattern of portability and utility
functions, though they operate at a higher level than other functions in
nbase. I mean functions like getinterfaces, getsysroutes, and route_dst.
I say these are higher-level because they presuppose certain data
structures that are the same in Nmap and Nping only because of their
common heritage. Maybe they would have been designed differently if they
were designed for a resuable library from the start.

So far the pcap-requiring functions moved have been modest. I see

pcap_selectable_fd_valid
my_pcap_get_selectable_fd
pcap_select
pcap_select2
DnetName2PcapName
my_pcap_open_live

pcap_selectable_fd_valid doesn't really require libpcap. pcap_select and
pcap_select2 would not either, if they were supplied selectable fd from
outside. my_pcap_open_live should not be shared in my opinion--it really
should be different in Nping and Nmap. As it is the shared nbase version
has hardcoded Nmap options in it.

> I worry that making nbase dependent on libdnet and libpcap will not
> only cloud its (admittedly already murky) focus, but also cause
> near-term practical problems.  For example, Ithilgore recently spent
> several days making libpcap removable from Nsock so it could still be
> used in Ncrack.  Ncrack also uses Nbase, so we could run into the same
> issue if we now go and add libpcap to that.

Right, I thought about what Ithilgore was doing only after I gave Luis
permission to add a dependency on pcap.

Luis has been maoving these functions to a new file, nbase_net.c, so
they are at least separated from the others.

I think it's worthwhile to add a dependency on libdnet for the benefit
of common routing and interface functions. libpcap appears more
problematic and less important. Luis, do you think it will be possible
to move only the functions that require libdnet, and not those that
require libpcap? In other words, can this be separated to a large
degree?

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