Mailing List Archive: nessus and AMD64 again

nessus and AMD64 again

Jan 8, 2004, 9:00 AM

Post #1 of 7 (2356 views)

In my attempts to get nessus running (at least building for now) as a 64 bit
application, I have hit a problem.

1. First of all, there is a bug in gcc -O2 which causes a loop in gcc when
building nessus-libraries ... this is described in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112678 and fixed by the
associated patch.

2. I am use rpm as part of the build/install/etc. process but that is not
relevent.

3. The problem is that the libpcap libraries are installed into /usr/lib
rather than /usr/lib64. Per convention, /usr/lib is reserved for 32 bit
libraries on dual (32/64 bit systems) and 64 bit libraries are placed in
/usr/lib64. The other libraries involved in nessus-libraries are properly
installed into /usr/lib64.

4. Is there some reason that nessus needs its own version of libpcap? Are
there some unique modifications that have been made to libpcap that are not
part of libpcap 0.7.2? Couldn't nessus simply use the regular libpcap and,
at least on linux (or specifically Red Hat/Fedora) systems, not install its
unique libpcap?

5. I have started looking for a fix but do not have one yet. In any case, the
files nessus-libraries/Makefile, nessus-libraries/libpcap-nessus/Makefile.in,
and nessus-libraries/libpcap-nessus/Makefile need to be changed so that they
do the right thing.

6. After a "quick look", it appears that the references to
"${exec_prefix}/lib" in Makefile.in need to be changed to "${libdir}". The
is also a reference in the top level Makefile to "${prefix}/lib" rather than
"${libdir}". This last thing seems (to me) to be superfluous and you should
let the lower level Makefile just do the work (like you do for libnessus).
--
Gene

Re: nessus and AMD64 again [ In reply to ]

deraison at nessus

Jan 8, 2004, 9:10 AM

Post #2 of 7 (2310 views)

Permalink

On Jan 8, 2004, at 5:00 PM, Gene C. wrote:

> In my attempts to get nessus running (at least building for now) as a
> 64 bit
> application, I have hit a problem.
>

> 3. The problem is that the libpcap libraries are installed into
> /usr/lib
> rather than /usr/lib64. Per convention, /usr/lib is reserved for 32
> bit
> libraries on dual (32/64 bit systems) and 64 bit libraries are placed
> in
> /usr/lib64. The other libraries involved in nessus-libraries are
> properly
> installed into /usr/lib64.

You're probably right in your fix (using $libdir should solve the
issue). I'll
comming a CVS right away.

>
> 4. Is there some reason that nessus needs its own version of libpcap?
> Are
> there some unique modifications that have been made to libpcap that
> are not
> part of libpcap 0.7.2? Couldn't nessus simply use the regular libpcap
> and,
> at least on linux (or specifically Red Hat/Fedora) systems, not
> install its
> unique libpcap?

I have had numerous issues with libpcap 0.7.x on Linux. It seems that
they try
to use the bpf-like architecture offered by the kernel, but libpcap
0.7.x hates to
have too many pcap descriptors open at the same time. The solution
would be
to use the userland pcap workaround I use for BSD systems now that it's
been
extensively tested. Also I'd need to make sure that pcap 0.7.x is
non-blocking
on Linux (the older "stock" pcap libraries were blocking - ie:
pcap_read() would
not return until a packet hits the filter).

So all in all, I'd love to get rid of libpcap-nessus, but that's not
necessarily as easy
as it sounds.

-- Renaud

Re: nessus and AMD64 again [ In reply to ]

theall at tifaware

Jan 8, 2004, 9:32 AM

Post #3 of 7 (2313 views)

Permalink

On Thu, Jan 08, 2004 at 05:10:25PM +0100, Renaud Deraison wrote:

> I have had numerous issues with libpcap 0.7.x on Linux.

Version 0.8.2 was released late last month, btw.

> Also I'd need to make sure that pcap 0.7.x is
> non-blocking
> on Linux

I tried using Nessus with 0.8.2 but found the daemon would hang when
testing hosts that were down. While I'll admit to knowing little about
libpcap, I suspect your concern remains valid.

George
--
theall@tifaware.com

Re: libpcap 0.7.2 (was: nessus and AMD64 again) [ In reply to ]

peak at argo

Jan 15, 2004, 6:39 PM

Post #4 of 7 (2309 views)

Permalink

On Thu, 8 Jan 2004, Renaud Deraison wrote:

> I have had numerous issues with libpcap 0.7.x on Linux. It seems that
> they try to use the bpf-like architecture offered by the kernel, but
> libpcap 0.7.x hates to have too many pcap descriptors open at the same
> time. The solution would be to use the userland pcap workaround I use
> for BSD systems now that it's been extensively tested.

This is wierd. I have checked it can handle as much as 1000 simultaneously
open and listening pcap's (0.7.2 on 2.4 kernel).

> Also I'd need to make sure that pcap 0.7.x is non-blocking on Linux
> (the older "stock" pcap libraries were blocking - ie: pcap_read()
> would not return until a packet hits the filter).

I myself have been using Fyodor's patch that makes pcap_next() return
after the timeout specified by pcap_open_live() but it appears the
the timeout was meant to have other meaning and the right was is to
set the fd nonblocking (it works on Linux).

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Re: Re: libpcap 0.7.2 (was: nessus and AMD64 again) [ In reply to ]

deraison at nessus

Jan 16, 2004, 12:07 PM

Post #5 of 7 (2308 views)

Permalink

On Fri, Jan 16, 2004 at 02:39:44AM +0100, Pavel Kankovsky wrote:
> On Thu, 8 Jan 2004, Renaud Deraison wrote:
>
> > I have had numerous issues with libpcap 0.7.x on Linux. It seems that
> > they try to use the bpf-like architecture offered by the kernel, but
> > libpcap 0.7.x hates to have too many pcap descriptors open at the same
> > time. The solution would be to use the userland pcap workaround I use
> > for BSD systems now that it's been extensively tested.
>
> This is wierd. I have checked it can handle as much as 1000 simultaneously
> open and listening pcap's (0.7.2 on 2.4 kernel).

Interesting. I actually was using a 2.2 kernel when I did my tests,
maybe that's why.

> > Also I'd need to make sure that pcap 0.7.x is non-blocking on Linux
> > (the older "stock" pcap libraries were blocking - ie: pcap_read()
> > would not return until a packet hits the filter).
>
> I myself have been using Fyodor's patch that makes pcap_next() return
> after the timeout specified by pcap_open_live() but it appears the
> the timeout was meant to have other meaning and the right was is to
> set the fd nonblocking (it works on Linux).

That's a linux specific hack. That somehow defeats the purpose of using
libpcap in the first place...

-- Renaud

Re: Re: libpcap 0.7.2 (was: nessus and AMD64 again) [ In reply to ]

peak at argo

Jan 19, 2004, 7:43 AM

Post #6 of 7 (2306 views)

Permalink

On Fri, 16 Jan 2004, Renaud Deraison wrote:

> > This is wierd. I have checked it can handle as much as 1000 simultaneously
> > open and listening pcap's (0.7.2 on 2.4 kernel).
>
> Interesting. I actually was using a 2.2 kernel when I did my tests,
> maybe that's why.

Hmm...I guess I'll try the same stress test on 2.2.

> > > Also I'd need to make sure that pcap 0.7.x is non-blocking on Linux
> > > (the older "stock" pcap libraries were blocking - ie: pcap_read()
> > > would not return until a packet hits the filter).
> >
> > I myself have been using Fyodor's patch that makes pcap_next() return
> > after the timeout specified by pcap_open_live() but it appears the
> > the timeout was meant to have other meaning and the right was is to
> > set the fd nonblocking (it works on Linux).
>
> That's a linux specific hack. That somehow defeats the purpose of using
> libpcap in the first place...

The timeout it pcap_open_live() was never intended to be a portable
mechanism to make libpcap operate in a nonblocking way. See:

http://www.tcpdump.org/lists/workers/2000/msg01674.html
http://www.tcpdump.org/lists/workers/2000/msg01730.html
http://www.tcpdump.org/lists/workers/2001/01/msg00038.html

0.7.x adds a (presumably) portable way to put pcap into a nonblocking way
(pcap_setnonblock()), and 0.8 adds explicit support for select()/poll() on
nonblocking pcaps (pcap_get_selectable_fd(), yet to be documented).

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Re: Re: libpcap 0.7.2 (was: nessus and AMD64 again) [ In reply to ]

peak at argo

Feb 11, 2004, 12:16 PM

Post #7 of 7 (2314 views)

Permalink

On Fri, 16 Jan 2004, Renaud Deraison wrote:

> > This is wierd. I have checked it can handle as much as 1000 simultaneously
> > open and listening pcap's (0.7.2 on 2.4 kernel).
>
> Interesting. I actually was using a 2.2 kernel when I did my tests,
> maybe that's why.

It appears to work on 2.2 too (2.2.24 with libpcap 0.7.1).

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."