Alternate way of detecting live IP's

Started by Frank Rizz

Frank Rizz

Alternate way of detecting live IP's   27 April 2014, 02:35

Hi, is there a way to utterly turn OFF ICMP-scanning in the application? I'm using many threads and pinging has become ineffective and unreliable. Right now I'm using the option to scan IP's even if they don't respond to ping, which is ok, but I'd like to simply not even generate the extra traffic of ping. Maybe some nmap-like methods of IP detection? Anyway, to clarify:

I'd like to be able to disable PING completely, and/or have an alternate method of detection before scanning for open ports.
SoftPerfect Support forum - Andrew avatar image

Re: Alternative way of detecting live IP's   27 April 2014, 13:46

There is currently no way to disable ping.

If you could suggest some alternative detection methods, that would be great.
Frank Rizz

Re: Alternate way of detecting live IP's   27 April 2014, 17:56

Well, I was thinking maybe something like nmap -PS (SYN Ping) or -PA (ACK Ping), although I'm reluctant to ask for stuff like that because I suspect it may require winpcap in Windows.. Anyway, if I set the "Method" option to a non-routable protocol like ARP-only rather than "Both ICMP & ARP", that should prevent NS from sending ICMP when scanning over the Internet, right? Kind of like a workaround?
SoftPerfect Support forum - Andrew avatar image

Re: Alternate way of detecting live IP's   28 April 2014, 19:49

It will still send an ARP packet to every IP address.

I don't see what's the harm in sending one small ICMP packet with 32-byte payload comparing to how many packets will be sent anyway if you choose the Always analyse host option.
Frank Rizz

Re: Alternate way of detecting live IP's   28 April 2014, 22:36

Oh, there's no _harm_ being done, per se. Here it is; when set to 1000 threads, ICMP becomes unreliable for me when scanning large nets (between 30 & 100 thousand IP's/per shot). For example, Scanning a range of 32 thousand addresses looking for port 80: Within about 15 seconds the my connection completely drops when using 1000 threads+ICMP. Now, I'm not sure if this is a problem with my router, or my ISP flagging some kind of prohibited activity (too many pings or whatever) and then dropping packets, but when I use "always analyze" + "ARP-only", it eliminates this problem (the drop) and I always get back many, many more open ports back.

In other words, "always analyze" is demonstrably more reliable for my setup as compared to when I do the _exact same scan_ using only ICMP. So basically I'm doing just fine right now, and don't even require anything because NS is working properly. However, I keep asking myself if the thing is working fine, then why even flood with additional ICMP and/or ARP? BTW I don't think ARP gets routed over the Internet so even though NS still generates ARPs, they never leave my subnet.

Now the problem with actually analyzing *every* host: efficiency & speed degradation. This is why I need some other method of quickly determining host availability before a full-blown scan commences. There is very, very little benefit to me for such a feature when scanning a giant range for only ONE port. But it becomes exponentially more important as the number of ports I need to scan increase. Even just 5 ports on a range of 64,000 IP's would take a massive hit using "always scan".

So the summary of all this mumbo jumbo is basically that using ICMP for recon-before-scanning kills my connection @ 1000 threads, so it would be great to have something that does the job of ICMP that won't cripple my network during high-volume scanning.

Oh and yes I've tried reducing the threads to determine stability using ICMP, It seems that ~300 threads and ICMP doesn't cause connection-drops, however using 1000 threads+always scan still gives me more results in a measurably shorter period of time anyway. =)

Reply to this topic

Sometimes you can find a solution faster if you try the forum search, have a look at the knowledge base, or check the software user manual to see if your question has already been answered.

Our forum rules are simple:

  • Be polite.
  • Do not spam.
  • Write in English. If possible, check your spelling and grammar.

Author:

Email:

Subject

A brief and informative title for your message, approximately 4–8 words:

     

Spam prevention: please enter the following code in the input field below.

 **     **  **    **  **    **   *******   **    ** 
 **     **  ***   **  **   **   **     **  ***   ** 
 **     **  ****  **  **  **           **  ****  ** 
 **     **  ** ** **  *****      *******   ** ** ** 
 **     **  **  ****  **  **           **  **  **** 
 **     **  **   ***  **   **   **     **  **   *** 
  *******   **    **  **    **   *******   **    ** 

Message: