× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Jon,

All you'd see in a comm trace is that you sent a SYN packet, and didn't get any response. SYN is short for "synchronize", but you can think of it as a request to start a new connection.

Normally, a server would receive the request, and respond with an error message (most commonly, "connection refused") or it's own SYN packet to tell your side that it's willing to start the session.

The problem is that you're not receiving either of these responses, so your program sits and waits until it gives up (or "times out").

The real question is: WHY aren't you receiving a response? Well, this is the standard behavior of a firewall. When it receives a packet that isn't allowed according to the firewall rules, it discards the packet. Therefore, the host never receives your request, and can't send a response.

Some firewalls also block ICMP data (used to report error messages), and therefore it's possible that the remote host is receiving your request and reporting an error that's being blocked by the firewall -- but this is much less likely.

Other possibilities would include an incorrect entry in a routing table, or a faulty piece of equipment that's dropping packets. But, in either of these cases, the symptoms would be noticed for all connections, not just FTP, and therefore I consider this much less likely.

I'd say there's about a 97% chance that there's a firewall blocking port 21, and that's the cause of the problem.

Jon Paris wrote:
On 16-Oct-07, at 1:00 PM, Scott Klement wrote:

You say that the error is a timeout? When does the timeout occur?
Does it occur on the initial connection, or does it occur when trying to
perform a transfer (i.e. a PUT, GET or directory listing).

On the initial connection.

On the other hand, if it's happening immediately during the initial
connection, then it's a simple TCP connection to port 21 that's being
blocked by a firewall.

Here's the log from a Telnet session

jon-paris-computer:~ jonparis$ telnet frankieiii.frankenseries.com 21
Trying 65.183.178.117...
telnet: connect to address 65.183.178.117: Operation timed out
telnet: Unable to connect to remote host

jon-paris-computer:~ jonparis$ telnet partner400.com 21
Trying 63.167.147.110...
Connected to partner400.com.

So I can telnet to one system but not the other. I also verified that the same scenario applies with FileZilla just in case it was misinterpreting a response.

So it would appear from this test that any firewall issue must be on the 400 side. But if that is the case then why is it that I can connect via 5250 to another completely different 400 and then happily telnet to the problem system that failed above! Doesn't that indicate that there is no firewall blocking port 21 on the box?

Since it is a straight timeout is there any point in doing a comms trace?


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.