Ping from VB6

[TimTDP]

I have an application that needs access to an Internet website, which I need to distribute. I need to put together a tool to test that Internet access is permissible, and that a firewall is not blocking access.
Can I do this using ping?
If yes, how do I know if the ping was successful, i.e access was allowed / disallowed?
If no, what other method can I use?

This must be able to run on Windows 2000, XP & Vista

[jdc2000]

You could Shell the ping command and direct the output to a text file, then read in the text file to see if the ping was successful or not. Bear in mind that some ISP's, web sites, routers, etc. may block ping requests while still allowing other traffic.

[dee-u]

This is what I use, not tested with Vista though.

Public Function ComputerIsOnline(ByVal strComputerName As String) As Boolean
    On Error GoTo ErrorHandler
    
    Dim strResult   As String
    Dim ShellX      As String
    Dim FileNum     As Integer
    Dim lPid        As Long
    Dim lHnd        As Long
    Dim lRet        As Long
    
    'DoEvents
    ShellX = Shell("command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide)
    lPid = ShellX
    If lPid <> 0 Then
        lHnd = OpenProcess(SYNCHRONIZE, 0, lPid)
        If lHnd <> 0 Then
            lRet = WaitForSingleObject(lHnd, INFINITE)
            CloseHandle (lHnd)
        End If
        FileNum = FreeFile
        Open "log.txt" For Input As #FileNum
        strResult = Input(LOF(1), 1)
        Close #FileNum
        ComputerIsOnline = (InStr(strResult, "Lost = 0") > 0)
    End If
    Exit Function
ErrorHandler:
    ComputerIsOnline = False
    Exit Function
End Function

[GhostWolf]

I don't remember which site I found this code on, but it's worked quite nicely for me:

Private Declare Function GetRTTAndHopCount _
    Lib "iphlpapi.dll" _
   (ByVal lDestIPAddr As Long, _
    ByRef lHopCount As Long, _
    ByVal lMaxHops As Long, _
    ByRef lRTT As Long) As Long
        
Private Declare Function inet_addr _
    Lib "wsock32.dll" _
   (ByVal cp As String) As Long
 
 

Public Function Ping(prmIPaddr As String) As Boolean
Dim IPaddr As Long, HopsCount As Long, RTT As Long
Dim MaxHops As Long
    Const SUCCESS = 1
    MaxHops = 20               ' should be enough ...
    IPaddr = inet_addr(prmIPaddr)
    Ping = (GetRTTAndHopCount(IPaddr, HopsCount, MaxHops, RTT) = SUCCESS)
End Function

[camoore]

I came upon this thread while searching for help about the ping function to test whether an internet IP is on-line and serviceable.

The answer I needed was contained within just one line of dee-u's code as above :

Dim strComputerName as String

ShellX = Shell("command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide)

If strComputerName is set to an IP address eg. 10.20.30.40 and this is run from a simple command button, then the test result appears in text file log.txt. File log.txt can then easily be read into a VB program (I used a RichTextBox to import it) and any element of its content can be parsed out as desired using string manipulation.

Dim Shellx as String, but you do not need to do anything with it. All the answers I needed were to be found in log.txt.

"log.txt" can be replaced by any other path you might prefer eg. "C:\MyFiles\Pinglog.txt"

So simple, so neat.

camoore, Wales, UK

[dilettante]

Shell() returns a Variant Double. If you don't need the return value don't ask for one:

Shell "command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide

[camoore]

Noted dilettante. I had not used Shell previously, so I copied that line of dee-u's code.

With your code there is no need for the ShellX variable at all, since in my application I am extracting the information I need from the .txt file.

camoore
Wales, UK

[dbasnett]

I have an application that needs access to an Internet website, which I need to distribute. I need to put together a tool to test that Internet access is permissible, and that a firewall is not blocking access.
Can I do this using ping?
If yes, how do I know if the ping was successful, i.e access was allowed / disallowed?
If no, what other method can I use?

This must be able to run on Windows 2000, XP & Vista

There is no point in doing a Ping. Just because you can or can not ping a site tells you nothing about other services.

Try pinging www.vbforums.com. Did it work? Now try browsing to www.vbforums.com. Did that work?

The best bet is to capture the errors produced when trying to access the site normally, which you need to do anyway.

[camoore]

The point made by dbasnett is most valid. A ping test merely serves to indicate that equipment with a given IP address is working, connected to internet and is configured to respond to ping tests (which some equipments may be configured not to do). A successful ping test indeed does not tell you anything about other restrictions which may have been placed upon website or other access to whatever is beyond that internet interface.

It is to be noted that this thread was started in 2008, so hopefully the OP. has resolved his issue by now (but I think the thread has not been marked as RESOLVED).

I came across this thread via the Forum search facility. My own requirement was of a more specialised nature. I was not seeking to find out about any website, but the serviceability of remote communication devices which utilise the internet for 2-way access. Are they working, or has a cow eaten through the phone line? For this essentially engineering purpose a ping test is ideal, and the so simple Shell routine suggested by dee-u and dilettante solved my own query very well.



camoore

Wales, UK

[dbasnett]

...
It is to be noted that this thread was started in 2008, so hopefully the OP. has resolved his issue by now (but I think the thread has not been marked as RESOLVED).

I came across this thread via the Forum search facility. My own requirement was of a more specialised nature. I was not seeking to find out about any website, but the serviceability of remote communication devices which utilise the internet for 2-way access. Are they working, or has a cow eaten through the phone line? For this essentially engineering purpose a ping test is ideal, and the so simple Shell routine suggested by dee-u and dilettante solved my own query very well....

It just showed up as active, so I responded. So what does this "...but the serviceability of remote communication devices which utilise the internet for 2-way access." mean. I used web access as an example, but it applies to any two devices using any standard means of internet connection. If the general format of the code is

if ping is successful then
do something else
end if

then you have missed the point.


It is generally best not to post in old threads. Start a new one and add a reference to the old one if needed.

[camoore]

dbasnett :

I will make one further post here, but the answer to your question is application specific rather than of general interest to the code forum.

In a safety critical environment, we have numerous sets of computer based control and monitoringsystems. Each site has one or more static IP addresses (more than 1 = deliberate redundancy). The sites communicate 2-way with the control facility via internet. When something goes wrong, naturally everything fails safe - but that stops the operation and can start to get very expensive.

So a malfunction has rapidly to be traced to either a remote equipment problem (so send an engireer out there asap) or to a communications problem (so alert the comms. section and/or the local phone companies).

It has been determined that we wanted to write a vb program which would rapidly and semi-automatically carry out ping testing to the remote site IP(s) and display the results back on screen. This should determine whether the problem lies in comms or elsewhere.

Initially I searched MS and found this article :
http://support.microsoft.com/kb/300197

That code worked, but I thought it rather over-complicated, though albeit comprehensive. However further searching brought me to this old forum thread and there in the post by dee-u was just what was wanted : a simple Shell routine to call the windows ping routine from within VB6 PLUS the means of getting the results back into VB6 (by importing the results .txt file which windows generates using dee-u's code into a Rich Text Box and then parsing out the elements of data for display on screen).

I could have made no reply at all - just used dee-u's code, but firstly I wished to inform dee-u (and others) how useful I have found his post and secondly so that anyone else who might go down the same search route as I have followed would have the benefit of my comments. That is why I posted here and not to a new thread.

Enough said I think.

camoore
Wales, UK

[dbasnett]

My question about what comes after the ping includes even home grown TCP or UDP socket oriented applications. In case it isn't obvious I have had this discussion before. I have even seen ping's be the root cause of the problem.

Because of ping-then-do consuming more and more ISP bandwidth (the last numbers I saw were between 2 and 4%), many are blocking ICMP requests from the edge. So my advice is don't ping-then-do.

I see more and more posts about this and few heed my warnings. So if one day you wake up and your pings no longer work, blame ping-then-do.

[camoore]

dbasnett, I thought this thread closed from my point of view.

Clearly you have firm any maybe well-founded views about internet use. I am not sure whether this forum is where to state them - since I thought that it is essentially a forum for coders.

Your remarks are however received with thanks. As to "ping then do" what we will do is exactly this : ping the remote site a maximum of 100 times at 2.5 second intervals with 32 byte packets. If in that time it has not responded, give up and call in the relevant engineering support - system technical or communications.

I would be happy to extend this interchange with you , but could you please do so by PM. since I feel it is not of direct relevance to the technical thread and hence not of interest to the forum community as a whole.

If you have views as to how internet should responsibly be used, there is surely a section of this forum on which properly to express them.

Although the OP has not, as far as I can see, marked this thread as "Resolved" let us treat it as such, unless of course other contributors may wish to add helpful comments.

For me this was yet another very helpful assist from the forum, with particular thenks to dee-u and dilettante.

camoore
Wales, UK

[dbasnett]

You are under no obligation to participate in this conversation. This is not a language specific forum and if it was, theory and algorithm discussion are always allowed.

I made two points that you did not respond to.

What mechanism do you use in your real application ("...The sites communicate 2-way with the control facility via internet.")? HTTP, Sockets, Email,...?

What are you going to do if the ISP's disable ICMP from the edge?

If someone should discover this thread in the future I would want them to hear both sides. That can't happen if you do not participate. If you want to discuss this somewhere else, take a look at my signature. I do not PM.

If you are sending your ICMP packets via ethernet, the minimum packet size will be 64 bytes on the wire.

[camoore]

dbasnett. It would be impolite not to reply to your last message, but I feel that its content is largely irrelevant to the theme of the thread and hence probably not of interest to the forum at this point. I have invited you to PM. If you do not wish to do so, that is your personal choice.

I will probably be making one further post to this thread, because we have now encountered an issue which seems to be Windows OS related. For completeness, and maybe the assistance of forum members who encounter this thread in the future, I will post details of our problem and its solution - when we have it.

Thank you dbasnett for having taken the time and trouble to contribute.


camoore
Wales, UK

[dbasnett]

dbasnett. It would be impolite not to reply to your last message, but I feel that its content is largely irrelevant to the theme of the thread and hence probably not of interest to the forum at this point. I have invited you to PM. If you do not wish to do so, that is your personal choice....

The whole premise of this thread was ping-then-do, so it is relavent. From the OP, "I have an application that needs access to an Internet website, which I need to distribute. I need to put together a tool to test that Internet access is permissible". If I had not been sick at the time and seen this I would have said something then.

You seem to think you have found the exception to ping-then-do, but as you are unwilling to disclose what TCP / UDP protocol mechanism you are using we can't have a discussion / debate based on the merits.

This isn't the first thread on this or other forums where I have had this discussion. So far no one has shown an example (outside of people actually running an ENTIRE network) where Ping was actually useful. There are a lot of people that don't understand.

The reason PM is out is that the subject is important and should be discussed openly.

Let me ask this question again: "What are you going to do when the ISP's shut off ICMP from the edge?" They already set ICMP packets to low priority which means when the network is congested the ICMP packets are slow or discarded.

[camoore]

A final post to this thread from me.

The code suggested by dee-u and further commented upon by dilettante was :

Shell "command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide

This worked fine for me under Win98SE, but not under later OS.

We had to change it to :

Shell "cmd.exe /c ping -n 2 " & strComputerName & " > log.txt", vbHide for Win2000 and XP

I have tested this OK with Win2000 and WinXP. My colleague has reported that it also works fine with Vista. As yet not tested with Win7.

In case anyone else finds this thread via the search routine, as did I, I hope that this OS version information may prove of assistance.

camoore

Wales, UK

[dbasnett]

A final post to this thread from me.
The code suggested by dee-u and further commented upon by dilettante was :
Shell "command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide
This worked fine for me under Win98SE, but not under later OS.

We had to change it to :
Shell "cmd.exe /c ping -n 2 " & strComputerName & " > log.txt", vbHide for Win2000 and XP

I have tested this OK with Win2000 and WinXP. My colleague has reported that it also works fine with Vista. As yet not tested with Win7.

In case anyone else finds this thread via the search routine, as did I, I hope that this OS version information may prove of assistance.

camoore
Wales, UK

I hope that if anyone finds this thread, they reconsider the assumption that ping-then-do is useful.

[dilettante]

There is a lot here that is suboptimal.

One might use %COMSPEC% to deal with the issue of which command shell to run... if you want to trust an environment variable, always a bad idea. For example some "alternate shell" packages rewrite COMSPEC's value to a command shell that uses different command line syntax.

Using Shell() to run an external process for something like this seems pretty wasteful. Using it to run a command shell to run the external program just to get redirection (to disk!)... well firing off two external processes is even worse, and programs are not supposed to rely on a command shell being available anyway. At least use anonymous pipes and run just the one program!

Then you have the ICMP ping issue which has been beaten to death.


What I don't understand is that if detecting that the server can't be reached is the goal why not just connect and see?

If you can't wait for the Winsock connection timeout interval and retries, then why not just use a Timer set to the longest interval you want to wait (3, 5, 10 seconds)? If the connection is accepted before the Timer goes off, disable the Timer and continue. If the Timer fires then disable it, close the connection attempt, and signal an error. If a connection error such as a sckConnectionRefused comes back... etc.

A small amount of code that bypasses all of the shaky practices outlined above.

I have tested this OK with Win2000 and WinXP. My colleague has reported that it also works fine with Vista. As yet not tested with Win7.

In case anyone else finds this thread via the search routine, as did I, I hope that this OS version information may prove of assistance.

There isn't an OS version issue here, it's an OS type issue. NT based Windows uses cmd.com as its default command shell, that's all. Almost nobody is using Win9x seriously anymore anyway.

[camoore]

I have frequently found that replies and suggestions provided by dee-u have been very helpful to me in solving problems.

Not being all that knowledgeable about this topic, I regret that I do not understand th majority of the last post by dilettante, wise and correct though it probably is - as usual.

We have a solution, albeit sub-optimal. Maybe dilettante could write a learned article on this subject for the forum. and attach it to his signature? Meanwhile shell ping works fine for our simple purposes.

camoore

Wales, UK

[dbasnett]

There is a lot here that is suboptimal.

One might use %COMSPEC% to deal with the issue of which command shell to run... if you want to trust an environment variable, always a bad idea. For example some "alternate shell" packages rewrite COMSPEC's value to a command shell that uses different command line syntax.

Using Shell() to run an external process for something like this seems pretty wasteful. Using it to run a command shell to run the external program just to get redirection (to disk!)... well firing off two external processes is even worse, and programs are not supposed to rely on a command shell being available anyway. At least use anonymous pipes and run just the one program!

Then you have the ICMP ping issue which has been beaten to death.


What I don't understand is that if detecting that the server can't be reached is the goal why not just connect and see?

If you can't wait for the Winsock connection timeout interval and retries, then why not just use a Timer set to the longest interval you want to wait (3, 5, 10 seconds)? If the connection is accepted before the Timer goes off, disable the Timer and continue. If the Timer fires then disable it, close the connection attempt, and signal an error. If a connection error such as a sckConnectionRefused comes back... etc.

A small amount of code that bypasses all of the shaky practices outlined above.



There isn't an OS version issue here, it's an OS type issue. NT based Windows uses cmd.com as its default command shell, that's all. Almost nobody is using Win9x seriously anymore anyway.

In VB .Net there is an Async version of the connect, but I do not know if something similar exists in VB6. Certainly the method above is better than what has been proposed before.

[luca90]

This is what I use, not tested with Vista though.

Public Function ComputerIsOnline(ByVal strComputerName As String) As Boolean
    On Error GoTo ErrorHandler
    
    Dim strResult   As String
    Dim ShellX      As String
    Dim FileNum     As Integer
    Dim lPid        As Long
    Dim lHnd        As Long
    Dim lRet        As Long
    
    'DoEvents
    ShellX = Shell("command.com /c ping -n 2 " & strComputerName & " > log.txt", vbHide)
    lPid = ShellX
    If lPid <> 0 Then
        lHnd = OpenProcess(SYNCHRONIZE, 0, lPid)
        If lHnd <> 0 Then
            lRet = WaitForSingleObject(lHnd, INFINITE)
            CloseHandle (lHnd)
        End If
        FileNum = FreeFile
        Open "log.txt" For Input As #FileNum
        strResult = Input(LOF(1), 1)
        Close #FileNum
        ComputerIsOnline = (InStr(strResult, "Lost = 0") > 0)
    End If
    Exit Function
ErrorHandler:
    ComputerIsOnline = False
    Exit Function
End Function

error: Variable not def in SYNCHRONIZE
and in OpenProcess variable or fuunction not def

[fafalone]

You bumped a thread that's been dead for 14 years because you want someone to look up common Windows API definitions for you? You're on this site so even if Google, Bing, and everything else was banned wherever you are you'd still be a single local site search away from the answer.