Nmap Development: Re: Buffer space Problems

[Mike Slifcak <slif () bellsouth net>]

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