Re: Adding libdnet and libpcap to nbase

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 06/11/2010 05:53 PM, David Fifield wrote:
> 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?
>
>   
Well, I can leave any function out of the de-duplication process, that's
not a problem at all. But that would leave us with the same problem we
had before: same code in more than one place. Some of those libpcap
functions that are already in nbase are not that important by themselves
but are needed in order to move doArp(), which looks like a nice
function to share. Also, note that functions like DnetName2PcapName()
and my_pcap_open_live() are actually functions whose goal is to provide
portability, which makes them even more suitable to go in Nbase. But I
am not saying that I don't want to move libpcap-related functions out of
Nbase. It's fine by me if you prefer to keep separate copies of some
functions for the moment. Nmap and Nping will work as usual because
those functions have been around for years and they seem to work well.
However, I think it shouldn't be that hard to add a few #ifdefs in Nbase
so pcap-related code is not compiled if requested, pretty much like
nsock does. What do you think?

Luis MartinGarcia.

> David Fifield
>
>   

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