Re: JR in need of mentoring...

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Jason,

> Yes I can, I was able to ping/traceroute google.com and webservicex.net
> with no lost packets or failed hops.

Here's what we know for sure:   HTTPAPI is attempting to establish a TCP 
connection.  It has sent the connection request, and is waiting for a 
response.  When it doesn't receive a response within 60 seconds (or 
whatever you set the timeout to) it gives up and reports 'time out.'

So what can cause that?   Theoretically, there are many things that can 
cause this "no response" symptom.  In fact, virtually any sort of 
misconfiguration could cause a "no response".   A Broken cable.  A bad 
hub/switch, a bad router, a misconfiguration of the routing table, or 
perhaps the most obvious thing...  the network is too slow to respond 
within 60 seconds to the request.

But we can rule most of these possibilities out off the bat!

a) It can't be a broken cable, or PING/TRACEROUTE wouldn't work.
b) It can't be a bad hub/switch or PING/TRACEROUTE wouldn't work.
c) It can't be a bad router, because PING/TRACEROUTE wouldn't work.
d) It can't be a misconfiguration because PING/TRACEROUTE wouldn't work.
e) It can't be too slow of a network, because you'd see that with 
PING/TRACEROUTE as well.

So what could it be?   It's almost as if there's some sort of mysterious 
device that's blocking HTTP, but isn't blocking PING/TRACEROUTE. 
Imagine it!  Some sort of device that could be configured to allow 
CERTAIN traffic in an out of a network, but still block UNWANTED traffic 
in and out of the same network.

Well, guess what?  That's what a firewall does.   When you configure a 
firewall, you tell it what to block and what not to block.

The fact that PING/TRACEROUTE work does NOT tell you that your firewall 
will let HTTP requests through.  Instead, it tells you that your 
firewall will let PING (ICMP messages) and traceroute (both ICMP 
messages and UDP messages on ports 33434 - 33500) through.

HTTP is NOT ICMP or UDP.  It's TCP on port 80 (or SSL on 443) though 
sometimes people use non-standard ports.

The point is... you have NOT tested whether your network allows these 
things through, and PING and TRACEROUTE tell you nothing about that.

If you honestly believe that HTTPAPI is the problem (which seems a 
little unlikely since it works for many people) then you might try 
typing the following, since that DOES test TCP on port 80:

TELNET RMTSYS(www.google.com) PORT(80)

The "PORT(80)" is critical.

If TCP PORT 80 is getting past your firewall, then the response will be 
"TELNET session ended.  Connection closed."  or you MAY get a blank 
screen...

If a firewall is blocking it, you'll get:
No response from remote host system within open time-out.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------