Using .NET ping to find devices on a network

I am finding that the PING function that ships in VB.NET seems to not always work on corporate networks, so I want to know what I can do to improve the probability of finding a host at an address.

The program allows the user to enter a list of addresses, and then it pings each address within that range and returns a table of devices

What I'm finding on large corporate networks is

1. The ping doesnt always find a device at an address even when a device is there
2. If I run it multi threaded, the probability of finding a device seems to reduce further
3. I have set default timeout to 100, and TTL=255, but so far I am only pinging each box once, whereas DOS ping obviosuly pings 4 times

Even with timeout upped to 5000, the problem exists.

I dont get many shots are large networks, so really I want to get it right next time..

My questions are:

(a) Would increasing the number of attempts from 1 to 4 or even more help ?
(b) Does it matter what size of data you send. I don't actually tell ping what data to send, so I suppose there must be a default byte array that it sends
(c) What other parameters can I set to get the absolute maximum probability of a ping response
(d) Multi threaded is definitely needed due to the time for each ping on a slow network, so any discussion on parameters related to multithreading would be appreciated




(c)
Public Function Ping(ByRef sAddress As String, ByRef sDataToSend As String, _
            ByVal lTimeOut As Integer, ByVal lTtl As Integer, _
            ByRef lResult As System.Net.NetworkInformation.IPStatus) As Integer
 
        Dim sn As New System.Net.NetworkInformation.Ping
        Dim re As System.Net.NetworkInformation.PingReply
        Dim op As New System.Net.NetworkInformation.PingOptions
 
        If sAddress = "" Then
            Return 0
        End If
 
        op.Ttl = lTtl
 
        Try
            re = sn.Send(sAddress, lTimeOut)
        Catch ex As System.Net.NetworkInformation.PingException
            Return 0
        Catch ex As System.Exception
            Return 0
        End Try
 
 
        lResult = re.Status
        If lResult = System.Net.NetworkInformation.IPStatus.Success Then
            Return 1
        Else
            Return 0
        End If
 
    End Function

Open in new window

LVL 8
plqAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Joel CoehoornConnect With a Mentor Director of Information TechnologyCommented:
If you're trying to do discovery on a network, the 'official' way to do it is via SNMP.  Unfortunately, as you're probably already aware it's a crapshoot whether or not a given device supports SNMP, and even then it may or may not be configured to actually respond to your request.

So you're looking at doing a simple ping as an alternative?  That has it's drawbacks as well.  IT networks sometimes specifically block icmp (ping, etc) packets from crossing subnet boundries.  Also, servers are often configured to specifically ignore ping requests as a precaution against denial of service attacks.

There is one thing you can still do to sometimes guess the existence of a device at a specific address even if you don't get a response.  Depending on how the device is configured it may either deny the request right away or simply not respond.  If it chooses not to respond you're ping will have to wait the full timeout period, and you haven't learned anything.  If it denies the request right away, the ping will fail, but it will return before the timeout expires.  So if you get a failure on the same subnet before the timeout expires, you know that a device exists at that IP.

When it comes down to it, a network discovery app is at the mercy of those administering the network.  You need to document what your app requires in order to function, and trust in the IT staff that implements your product to provide an environment that meets the documentation, or understand the gaps that will result.  Of course, you can make it easier on them by requiring at little as possible.

To get the best chance of a ping response, send as little data as possible.  Increasing the number of attempts might help, but remember that you don't want to repeat the ping if you get a response the first time.  This means don't rely on the built-in mechanism to repeat.  If the multi-threaded version of your ping code yields different results than the single threaded version, it's more likely the result of a bug in your multi-threading rather than whether or not a specific device responds.
0
 
plqAuthor Commented:
Yes the product supports many protocols incl snmp but ping is the one most customers choose since most devices support it, dont block it, whereas snmp is often turned off these days.

thanks for the feedback. Any further comments would be appreciated..
0
All Courses

From novice to tech pro — start learning today.