Ping @error=1

[Richard Robertson]

Alright. JohnOne asked if InetGet worked. Have you tried that yet?

[JohnOne]

Try

Ping("www.google.com",10000)

[Inconspicuous]

Alright. JohnOne asked if InetGet worked. Have you tried that yet?

Sorry, I missed that post. Here's what I've tried and it didn't work:

dim $handle = InetGet("http://www.mozilla.com/en-US/firefox/", @TempDir & "personal.html")
dim $info = InetGetInfo($handle, 3)
If $info Then
    MsgBox(0, "InetGet", "Success.")
Else
    MsgBox(0, "InetGet", "Failure.")
EndIf
InetClose($handle)

Try

Ping("www.google.com",10000)

Didn't work, it just timed out.

[Richard Robertson]

It seems you've got something specifically blocking your AutoIt scripts from accessing the internet. If it's not your software firewall, I'm not sure what could be blocking it.

[jchd]

From what you describe it smells bad.

Try installing WireShark and capture everything on the adapter while running the AutoIt ping. Save the snapshot and compare with a capture of a run with the command-line ping.

It that an official final install vs. some version of "enhanced" distribution of your OS (note that my question is _not_ about WGA and legit issues)?

Many OS ISOs found here and there have weirdly tweaked settings that can produce difficult to debug problems, specially after installing some MS patches which rely on the system not being hacked inconsistently.

[Inconspicuous]

From what you describe it smells bad.

Try installing WireShark and capture everything on the adapter while running the AutoIt ping. Save the snapshot and compare with a capture of a run with the command-line ping.

It that an official final install vs. some version of "enhanced" distribution of your OS (note that my question is _not_ about WGA and legit issues)?

Many OS ISOs found here and there have weirdly tweaked settings that can produce difficult to debug problems, specially after installing some MS patches which rely on the system not being hacked inconsistently.

It's a copy that my university supplied from MSDN Academic Alliance. I don't think it's an "enhanced" copy or anything. I'll try the WireShark method.

[GEOSoft]

If you are attempting to run this through the universities server then therein may be the problem. Fisrt try to ping the university server and then talk to the IT department. Try the WireShark method first.

[Inconspicuous]

From what you describe it smells bad.

Try installing WireShark and capture everything on the adapter while running the AutoIt ping. Save the snapshot and compare with a capture of a run with the command-line ping.

When I ping with AutoIt, the ping request is sent out, but there is no reply. I get replies by pinging in cmd.

AutoIt pings with 36 bytes and cmd pings with 32 bytes. So, I tried pinging with 36 bytes in cmd and it still worked. I guess the number of bytes isn't the problem.

One difference is the data, ie. AutoIt pings with 36 bytes of "AAAAAAAAAAAAAA..." and cmd pings with 36 bytes of "6162636465666768696A6B...". Also, the "Time to live" for AutoIt is 128 and for cmd is 255. Could this be causing the problem?

[jchd]

I don't believe typical routers would be setup to dissect ICMP data contents and drop whatever packet they don't recognize content, but what do I know?

OTPH it could make sense to do so in order to recognize ICMP from classical ping from Windows, Linux and Mac and filter out anything else in an attempt to block ICMP flood and hackers scanning for PCs to attack.

Time to live is a max timeout in seconds, which every router is required to decrement by one. Is it possible that you reach 0 (in which case the packet is dropped) from where you are? I doubt it: 128 hops is unlikely.

If you don't succeed in finding out how and why the university is blocking responses back, then running the cmd line ping from autoit will certainly be an easier solution than issuing the ping and receiving answers by low-level calls yourself.

[JohnOne]

What I would try next is not only disabling my firewall but uninstalling it, to absolutely rule it out.

From what I understand, when you disable them, some low level part of them is still running.

Also, are you trying this from home or your university?

[engjcowi]

Hi

Try this. I use it to establish when to update programs

If Ping("www.google.com") Then
    MsgBox(0, "Ping", "Online.")
Else
    MsgBox(0, "Ping", "Not Online")
EndIf

[Inconspicuous]

If you are attempting to run this through the universities server then therein may be the problem. Fisrt try to ping the university server and then talk to the IT department. Try the WireShark method first.

I did a tracert and it seems that it goes through 4 servers from my university. I can ping the first 2 out of 4, but not the last 2 (same results in cmd line and AutoIt). I'm not what I can conclude from this but it seems that the last 2 servers are private or something.

What I would try next is not only disabling my firewall but uninstalling it, to absolutely rule it out.

From what I understand, when you disable them, some low level part of them is still running.

Also, are you trying this from home or your university?

It's too much of a hassle to uninstall my firewall and reinstall it if it doesn't work. I'll take jchd's advice and ping from cmd line when I run out of options. And I am on my university's network.

Hi

Try this. I use it to establish when to update programs

If Ping("www.google.com") Then
    MsgBox(0, "Ping", "Online.")
Else
    MsgBox(0, "Ping", "Not Online")
EndIf

Isn't this practically the same thing? And it didn't work, still "Not Online".

.

Edited June 30, 2010 by Inconspicuous

[GEOSoft]

I suspect that one or more of the servers have a policy set to prevent applications, other than those specified in the policy, from accessing the internet. It's actually a good security setup for places like universities, although not unbeatable. Talk to the IT department and they may have a work-around