Nmap Development: Re: Buffer space Problems

[Bob McLaren <BobMcLaren () fssi-ca com>]

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