Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Buffer space Problems
From: Bob McLaren <BobMcLaren () fssi-ca com>
Date: Wed, 14 Apr 2004 16:52:54 -0700

Few hundred megabytes?
I think those entries are specified in kilobytes, not megabytes.
Meaning 4096K, meaning about 4 megs.

You can afford to spare 4 megs can't you?

David G. Cheney wrote:

yeah, I just wish this worked for my situation.
In one case I'm regularly scanning a (mostly empty) /8
I really just can't aford to devote a few hundred megabytes to kernel buffers =+/

--dgc

Mike Slifcak wrote:

Another solution for Redhat Linux that works without additional scripting:

   Add the following lines to /etc/sysctl.conf:

 net.ipv4.neigh.default.gc_thresh3 = 4096
 net.ipv4.neigh.default.gc_thresh2 = 2048
 net.ipv4.neigh.default.gc_thresh1 = 1024


Regards,
-Slif



Bob McLaren wrote:

Holy arp entries Batman!!! You fixed it!!!

I have had this exact same problem since early March! I had already given up on it! Bless you both...

BTW
Just to add my two cents and try to help out, here are the commands I used on my RedHat 7.1 system to write the kernel variables

/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3 = 4096
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh2 = 2048
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1 = 1024

Regards,
   Bob

joeclifton () bellsouth net wrote:

David,
I did some research, and found the following entries in my system log (/var/log/messages)kernel:
Neighbour table overflow
NET: 1067 messages suppressed

This is definitely an arp table overflow, so I fully concur with your findings.

Here is how I fixed it....well, at least temporarily:

by allocating more ram for the arp table:
echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

I'm not sure if these will be there when I reboot, if not, I will have to find out where I can set those on each boot, or permanently.

I have tested this while scanning an entire /16 subnet, then I tried it in 2 console windows, while simultaneously scanning 2 /16 subnets.....knock on wood...it is working thus far.
Hope this helps you!

joe

On Wed, 2004-04-14 at 13:35, David G. Cheney wrote:

I believe this isn't just an nmap problem.
I have encountered similar problems useing a home grown scanner similar to fping on FreeBSD. The buffer starvation in my case is related to the arp table growing to hundreds of thousands of entries. In FreeBSD 4.8 there was a known denial of service vulnerability based on this behavior, and where it was claimed to have been fixed the problem still occurs when it is the local arp daemon making the requests.My workaround was pretty ugly. I resorted to flushing the arp table every couple of thousand probes. This solves the problem on FreeBSD (btw. 5.2.1 still has this issue). I'm guessing that Linux has some similar issues.I personally don't think it should be the task of the user space application (i.e. scanner) to deal with resource starvation issues like this, but to be fair to the various kernels a scanner is not a typical load.If anyone has an alternate solution I would love to hear it.--dgc

joeclifton () bellsouth net wrote:> Any help is appreciated.
My Command line: > > nmap -sP -PI -oA ping-10.10.0.0 10.10.0.0/16> > Obvisouly, I am running out of buffer space somewhere, but where is my question, and is there a solution, except to reduce the size of the subnet being scanned. I first tired -T4, and backed it all the way down to -T1, with almost no difference. I get lots of hosts returned as being up, then it starts giving me the error below. I have tried different size subnets, and the largest I can scan with out geting the error is /22.> > I sometimes get an error similar to #2 below. (can;t remember the whole thing, and forgot to copy it.)> > I scan a lot of large subnets, and would like to ge this resolved.> Is there another way to throttle back, besides the timing option? I hate having to do 20 or 25 smaller scans, then cat'ing them together.> > error #1> > sendto in sendpingquery returned -1 (should be 8)!> sendto: No buffer space available> > er ror #2> RTTVAR > > > My versions:> > nmap version 3.48 > > Linux xxx.xxxx.org 2.4.22-1.2174.nptl #1 Wed Feb 18 16:38:32 EST 2004 i686 i686 i386 GNU/Linux (Fedora Core 1)> > > Thanks again for any help....> > joe> > >




---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to nmap-dev-help () insecure org . List archive: http://seclists.org





---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to nmap-dev-help () insecure org . List archive: http://seclists.org







---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to nmap-dev-help () insecure org . List archive: http://seclists.org



  By Date           By Thread  

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