User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

FTP, SFTP, FTPS, and SSH/telnet console issues
4 posts Page 1 of 1
I do novice web development for a few sites and have been using an older version of UltraEdit with no issue connecting to any of their FTP accounts. A month ago, one of the web servers decided to change something with their FTP and I could no longer connect to it. I contacted my client and they contacted the admin's for this web server and we found out they changed the FTP server and we now needed to use port 9021. I figured this would be an easy change in UltraEdit. I was wrong.

Something about this new port prevents the connection of UEdit from both an older and newer version of the software. When I try with the older version, I receive the "up one level" folder but nothing else. No other folders are listed. When I try with the newer version, I receive an "Error connecting". I have tested their new port with FileZilla, multiple web browsers, and Windows Explorer and in all those other instances, the connection went through as expected.

I have spent a few hours searching the web, these forums, and trying different combinations of options and have had very little luck finding anything that fixes the problem. If anyone has any ideas, please let me know. I have already began asking the web server admin's for more information or a work-around but I'm sure, since other software connects, they'll consider it an issue on my end or not worth looking into.

Here's my software information:

Newer Version
  • UltraEdit v15.20.0.1022
  • Windows 7 Ultimate 64-bit SP1
  • Home Computer

Older Version
  • UltraEdit-32 v12.10a
  • Windows 7 Enterprise 64-bit SP1
  • Work Computer


Well, for FTP connections at least 2 connections are established: the control channel from client to server on the specified port (usually 21) and the data channel from server to client. The data channel could be the problem here. Do you have tried using Passive Transfers option which is on Advanced tab if I remember correct? Do you have configured the firewall on your computers to accept incoming connections (for data channel) on port 9021? The Windows firewall surely blocks incoming connections on port 9021 by default.
Mofi, you are a genius! The "passive option" worked for both instances. I figured your suggestion would not work on my home machine since I do not use Windows Firewall. However, I have a hardware firewall through my router so that explains it. You are awesome! I seriously appreciate your time and suggestion.

Thank you again!

flogger123 wrote: Just to clarify on this, passive option would mean that this would listen to the specific port assigned. Is this correct?

What happens in a 'normal' FTP session is that when a data transfer starts, client listens on an arbitrary port and tells the server what port it should connect to. Then the the server connects back to the client. However firewalls and NAT routers block incoming connections, but they may permit it for FTP transfers (depending on their configuration) since they can see & recognize the FTP session that was started by an outgoing connection on port 21. With a passive FTP configuration, instead of making a connection back to the client, client asks the server what port should be used for the data connection and the *client* makes the data connection. So the data connection is outgoing instead of incoming, which firewalls and NAT routers typically have no problem with (unless you have a firewall that's configured very restrictively, like the one at my work, where even passive FTP doesn't work).

When you had a FTP configuration that used the standard FTP port 21, your firewall or router probably recognized the FTP session and permitted the incoming data connection, since it knew there was an FTP session going on between your client machine and the server. But when the FTP configuration changed to use port 9021, the firewall no longer understood that it was an FTP session since 9021 didn't mean anything in particular. Therefore no special treatment for the incoming connection.
4 posts Page 1 of 1