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_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
>
>
>
>
---------------------------------------------------------------------
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
