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_at_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_at_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
Received on Apr 14 2004
Intro
