[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JR in need of mentoring...
Thank you! that answers my question exactly! I didn't know that PING and
TRACEROUTE were red herrings. I just didn't know how to prove my firewall
was blocking a port or a service.
Thank you all, again...
-Jason
On Fri, 17 Oct 2008 17:57:38 -0500, Scott Klement <sk@xxxxxxxxxxxxxxxx>
wrote:
> 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
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------