Check If A Computer Is Online

[ezzetabi]

a copy of my famous (uh? Where?) script to check if a computer is online or not.

Remade in the Au3 sintax!!

Just, as every function, copy in the botton of your script and call it with

_IsTheComputerOn("computername")

Func _IsTheComputerOn ($computername)

; A function to know if a remote computer is on or not.
; Returns
; 0 if the computer is OFF
; 1 if the computer is ON
; 5 if the computer is the one where the script is executed, so it is of course on...;)

 Local $ping
 Local $computername

 If @computername = $computername Then
    Return 5
 EndIf

 RunWait(@comspec & " /c ping "& $computername &" -n 1 -w 50>"& @tempdir &"\ping.tmp","",@sw_hide)
 $ping = FileReadLine(@tempdir &"\ping.tmp",13)
 FileDelete(@tempdir &"\ping.tmp")
 If StringInStr($ping,"(0%") Then
    Return 1
 Else
    Return 0
 EndIf
EndFunc

Edited March 5, 2004 by ezzetabi

[sugi]

I'd suggest using a far simpler way that works in WinNT/2k/XP for sure and may also work in Win9x:

$Computer = InputBox("IP", "IP")
If RunWait("ping.exe -n 1 " & $Computer, "", @SW_HIDE) == 0 Then
    MsgBox(0, $Computer, $Computer & " is pingable")
Else
    MsgBox(0, $Computer, $Computer & " is NOT pingable")
EndIf

The reason I think this code is better:

- No need for temporary files

- It's nearly sure that it'll continue to work in newer version of Windows as exit codes normally are not changed to prevent problems with scripts

- It's far simpler

What it doesn't do: Check if the local computer is pinged

[ezzetabi]

Actually that was my first solution but it have a big problem.

If the computer have its name in the dns cache of the dhcp server and it is turned of the errorlevel is 0 all the same.

Check this:

Ripped from mine console

C:\>ping daniele

Esecuzione di Ping daniele.manghi.locale [192.168.0.158] con 32 byte di dati:

Richiesta scaduta.
Richiesta scaduta.
Richiesta scaduta.
Richiesta scaduta.

Statistiche Ping per 192.168.0.158:
    Pacchetti: Trasmessi = 4, Ricevuti = 0, Persi = 4 (100% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 0ms, Massimo =  0ms, Medio =  0ms

C:\>echo %errorlevel%
0

The Errorlevel is 0 even if the computer is unreachable.

The Errorlevel is 1 only when the host in unknow and it is not often the case in a LAN (a part of mispelling of course).

[sugi]

That's really strange, it's working fine for me:

M:\>ping fhhwxpdftest01 -n 1

Ping fhhwxpdftest01.S2.MS.UNILEVER.COM [194.15.51.11] mit 32 Bytes Daten:

Zeitüberschreitung der Anforderung.

Ping-Statistik für 194.15.51.11:
    Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1 (100% Verlust),

M:\>echo %ERRORLEVEL%
1

And after turning the machine on:

M:\>ping fhhwxpdftest01 -n 1

Ping fhhwxpdftest01.S2.MS.UNILEVER.COM [194.15.51.11] mit 32 Bytes Daten:

Antwort von 194.15.51.11: Bytes=32 Zeit=1ms TTL=127

Ping-Statistik für 194.15.51.11:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms

M:\>echo %ERRORLEVEL%
0

Pinging an unknown name:

M:\>ping fhhw01 -n 1
Ping-Anforderung konnte Host "fhhw01" nicht finden. Überprüfen Sie den Namen, un
d versuchen Sie es erneut.

M:\>echo %ERRORLEVEL%
1

[ezzetabi]

I do not know what to say... Maybe we have different version of Ping...

[Gene]

I do not know what to say... Maybe we have different version of Ping...

Given that demonstrated difference, it is safer for potential code borrowers to use Ezzetabi's method. It should work fine in either scenario. If you guys can determine the source of the difference, maybe you could devise a test and combine the two UDFs.

Gene

Edited April 26, 2004 by Gene

[sugi]

Given that demonstrated difference, it is safer for potential code borrowers to use Ezzetabi's method.

It's not that easy. Ezzetabi's method doesn't work on e.g. NT4 because the NT4 version does not show any statistics after pinging and Ezzetabi is relying on that.

[Jos]

It's not that easy. Ezzetabi's method doesn't work on e.g. NT4 because the NT4 version does not show any statistics after pinging and Ezzetabi is relying on that.

you could include a ping.exe that runs on all WIN versions by doing:

fileinstall("ping.exe", @tempdir,1)
RunWait(@comspec & " /c " & @tempdir &"\ping "& $computername &" -n 1 -w 50>"& @tempdir 
filedelete(@tempdir &"\ping.exe")

[Gene]

you could include a ping.exe that runs on all WIN versions by doing:

fileinstall("ping.exe", @tempdir,1)
RunWait(@comspec & " /c " & @tempdir &"\ping "& $computername &" -n 1 -w 50>"& @tempdir 
filedelete(@tempdir &"\ping.exe")

If you're going to bring your own, I bet there is a freebe 3rd party PING utility out there written in assembler with superior features (read small and useful). Now all we need is for someone to remember which one it is and where they got it.

I remember seeing them, but then I wasn't in the market.

Gene

[sugi]

...I bet there is a freebe 3rd party PING utility out there...

Sure, there will be severall. But I don't think it's worth the extra load of having to extract a file everytime the function is called. It would increase the size of the script a lot more than having maybe 30 lines of script code doing the ping.

I think I've found a solution to the mess Microsoft has created with the exit codes of ping:

If ComputerOnline("host") Then
    MsgBox(0, "host online", "")
Else
    MsgBox(0, "host offline", "")
EndIf

Func ComputerOnline($Computer)
    If RunWait('cmd /c ping -n 1 -l 32 ' & $Computer & '| find /n " " | find "[4]" | find "=32"', "", @SW_HIDE) == 0 Then
  Return 1
    Else
  Return 0
    EndIf
EndFunc

Bad thing about this script: It's relying on the output of ping AND find. But at least it's working on NT4 and XP. I have no 2k available, so I cannot test this.

Also I'm pretty sure it wont work on win9x because find is not available there, as far as I know.

Maybe someone with a Win9x system can add a routine that's working for himself? Then we can combine the functions and check the @OSTYPE macro to decide wich of the functions are called.

Edited April 28, 2004 by sugi

[Gene]

Sure, there will be severall. But I don't think it's worth the extra load of having to extract a file everytime the function is called. It would increase the size of the script a lot more than having maybe 30 lines of script code doing the ping.

I think I've found a solution to the mess Microsoft has created with the exit codes of ping:

If ComputerOnline("host") Then
    MsgBox(0, "host online", "")
Else
    MsgBox(0, "host offline", "")
EndIf

Func ComputerOnline($Computer)
    If RunWait('cmd /c ping -n 1 -l 32 ' & $Computer & '| find /n " " | find "[4]" | find "=32"', "", @SW_HIDE) == 0 Then
  Return 1
    Else
  Return 0
    EndIf
EndFunc

Bad thing about this script: It's relying on the output of ping AND find. But at least it's working on NT4 and XP. I have no 2k available, so I cannot test this.

Also I'm pretty sure it wont work on win9x because find is not available there, as far as I know.

Maybe someone with a Win9x system can add a routine that's working for himself? Then we can combine the functions and check the @OSTYPE macro to decide wich of the functions are called.

All the issues you just raised are the reasons I suggested a third party ping or why a previous writer suggested using the install method, for that matter. If you don't have dependable, cross OS output you have to build more code to meet all te circumstances of which you are aware, or can test for. With dependable output you can write one tight module that always works.

Gene

[sugi]

@Gene: You're definitly right if you're writing scripts for your own use and maybe for a small company. But some bigger companies (at least the one I'm working in) have policies that forbidd the use of external tools as long as they have no special approval.

In my company AutoIt has been approved after about a month, but I'd have no chance of getting an external ping utility approved because I'm able to use the Microsoft versions of ping with a few more lines of code.

Also as another reason: I don't know if a ping function will be included in one of the next versions of AutoIt, but if there wont be any, this could be a function for the library. But only as long as we're able to create a routine that works on every Windows version AutoIt is running on.

I wouldn't like the idea of having a FileInstall within the library, but of course I don't know how others look at this or if there is any interest in having a ping function in the library.

[Gene]

@Gene: You're definitly right if you're writing scripts for your own use and maybe for a small company. But some bigger companies (at least the one I'm working in) have policies that forbidd the use of external tools as long as they have no special approval.

In my company AutoIt has been approved after about a month, but I'd have no chance of getting an external ping utility approved because I'm able to use the Microsoft versions of ping with a few more lines of code.

Also as another reason: I don't know if a ping function will be included in one of the next versions of AutoIt, but if there wont be any, this could be a function for the library. But only as long as we're able to create a routine that works on every Windows version AutoIt is running on.

I wouldn't like the idea of having a FileInstall within the library, but of course I don't know how others look at this or if there is any interest in having a ping function in the library.

That's interesting relative to another topic. There has been on and off discussion on the Yahoo List and perhaps here as to how much and whether or not various capabilities should be included in AutoIt. You just made one of the best points in favor capabilities that duplicate many of the external utilities we have historically depended on. As long as we're supporting ourselves or small/private clients, the number and source of external helpers doesn't matter. But, in the case of large or governmental agencies, most if not all downloadable utilities are forbiddden. I can't and wouldn't attempt to speak for Jon, but from reading his posts, it appears AutoIt is intended for a wide a usage as finds it helpful for appropriate goals.

Gene

[Lilla]

below is some .vbs code I found when I was looking for an IsServiceRunning() function. It includes an IsConnectible() function that relates to this thread. The author says in Works an "all" WSH versions. Perhaps you can write some AutoIt code that does the same thing, or just call the .vbs from your AutoIt code.

I am using his IsServiceRunning() - the short version. Is it possible to rewrite this function in AutoIt?

Click the link below to see the full code for both functions. The author is a scripting guru.

IsConnectible() and IsServiceRunning()

by torgeir

Microsoft MVP Scripting and WMI, Porsgrunn Norway

...snip...

' ping the computer to see if it is online

If IsConnectible(sCompName, "", "") Then

On Error Resume Next

Set oComputer = GetObject("WinNT://" & sCompName & ",computer")

If Err.Number <> 0 Then

'WScript.Echo sCompName & " is online but not available"

Else

...snip...

Function IsConnectible(sHost, iPings, iTO)

' Returns True or False based on the output from ping.exe

'

' Author: Alex Angelopoulos/Torgeir Bakken

' Works an "all" WSH versions

' sHost is a hostname or IP

' iPings is number of ping attempts

' iTO is timeout in milliseconds

' if values are set to "", then defaults below used

If iPings = "" Then iPings = 2

If iTO = "" Then iTO = 750

Const OpenAsDefault = -2

Const FailIfNotExist = 0

Const ForReading = 1

Set oShell = CreateObject("WScript.Shell")

Set oFSO = CreateObject("Scripting.FileSystemObject")

sTemp = oShell.ExpandEnvironmentStrings("%TEMP%")

sTempFile = sTemp & "\runresult.tmp"

oShell.Run "%comspec% /c ping -n " & iPings & " -w " & iTO _

& " " & sHost & ">" & sTempFile, 0 , True

Set fFile = oFSO.OpenTextFile(sTempFile, ForReading, _

FailIfNotExist, OpenAsDefault)

sResults = fFile.ReadAll

fFile.Close

oFSO.DeleteFile(sTempFile)

Select Case InStr(sResults,"TTL=")

Case 0 IsConnectible = False

Case Else IsConnectible = True

End Select

End Function

[sugi]

@Lilla: Well, basically the code we tried (except my tries with the error level) does the same as the function posted by you: check the output of ping.

But as I stated above, this is not a real solution but only a workaround for a buggy ping.exe. The only real solution would be that Microsoft released fixed versions. But I'm sure this wont happen.