[BUG] Issue with the NAT traversal, in newest build

I think I've tracked down one of the problems that is causing so many to report a bug.


1) Even though I have UPNP activated on my computer, it sometimes happens that SmartFTP uses the old way to get the IP (giving a call to http://repeater.smartftp.com/). This is not normal, and causes PORT data connections to fail. This problem usually goes away when I close SmartFTP and start it again.

2) However, sometimes, I have a very similar problem. SmartFTP reports using GetExternalIP (the UPNP command), but then doesn't add/remove port mappings as needed---thus again causing problem with PORT connections.


As I know SmartFTP uses Microsoft's UPNP API (which maybe, is the problem), I believe that this problem could be caused by SmartFTP's UPNP acquiring method timing out

Hello ..

Thank you for your comments.

>1
As you correctly guessed we are using the UPnP implementation provided by Microsoft in Windows XP. I'm not sure whether the problem you are seeing is with their layer or with the SmartFTP client. Restarting the SmartFTP client or the system usually "fixes" the problem. It doesn't really matter whether SmartFTP gets the external IP from the router or from the repeater. The repeater is usually more accurate due to buggy UPnP implementations in the router software (router returning wrong ip address).

>2
No every router allows you to dynamically add the ports. It doesn't work with my Linksys (latest firmware) but it works with Netgear, US Robotics and others. If you cannot change the port mappings through the windows settings (Control Panel -> Network Connections -> Internet Gateway -> Properties etc) then the problem is with the router software.

The problem many users are seeing is not really related to UPnP. UPnP is only used if a connection is made to a server on a non standard port (not 21) or if a secure data connection is made and PORT is enabled. Both situations are not common for most users.

The actual difference is the port/pasv fail over mechanism which was partly missing in version 1.5. This has been addressed in the latest beta build available from:
https://www.smartftp.com/download
The SmarFTP client will now automatically change the data connection mode (From passive -> active and vice verse) if the directory listing fails with the user settings. This hopefully solves lots of problems where inexperienced users are using the wrong settings.

Regards,
-Mat

Thank you for your kind reply. However, I think I must not have expressed myself correctly.

The problem I encounter often is that sometimes, for an FTP server for which SmartFTP usually uses UPNP add/remove portmapping, it does not. What I am saying is that when it uses portmappings for those servers, everything works perfectly. But there are some times when it, for no reason, does not use UPNP. And then, nothin on the server works. As you said, restarting SmartFTP and/or the system usually solves this problem. But here, the issue is not with the router. When this problem happens, SmartFTP does not UPNP at all (even with other FTP servers) which is why I believe maybe it has not "acquired" UPNP at startup (that is how I use UPNP in my applications).

This problem has only started occuring with the new FTP library (the one you also sell separately).

I will try the development build to see if the problem is solved.

Thank you very much for taking the time to answer me!!

Best Regards,

J

Here is an example.

I have connected to the same server several times, and to test data connections, I have always refreshed the root dir /

This is the listing that fails:
[16:46:16]     TYPE I



[16:46:16] 200 Type set to I.



[16:46:16]     PROT P



[16:46:16] 200 Protection set to Private



[16:46:16]     UPNP: GetExternalIPAddress a retourn

Hello ...

Unfortunately we do not have much control over the UPnP layer. It turned out to be pretty reliable in the past though.
I would recommend you to add a static port range in your router and set the same values in the SmartFTP Limit Local Port range setting.

Regards,
-Mat

UPNP instability only dates from the latest 1.5 release, where you changed FTP libraries.

If my guess of SmartFTP not acquiring UPNP is good, I suggest you might try to make the acquisition timeout longer.

In any case your suggestion, although not very pleasant (having to forward ports manually is a thing of the past! ) ... I guess it'll have to do. The only problem is that SmartFTP tends to remove portmappings that are already there. How to completely deactivate UPNP?

I must note that SmartFTP's ease at PORT connections, brought on by UPNP, is one of your major advantages over clients such as FlashFXP. You might not want to dismiss it so fast.

I once had problems with SSL (when I was programming). The connection would sometimes be secured properly, and sometimes not. I could not realize what was different between to versions of the same classes. Finally, I discovered, that in the version that did not work, I was using several threads, and was unwittingly writing to the socket at the same time as it was sending out a handshake. The solution was to put the handshake routines in a lock block.

Best Regards.

Do you experience the problem only when using multiple connections and all of them dynamically add and remove the ports to the UPnP enabled router?
If this is a case I can move the add and remove port code into a critical section but thats pure trial and error.

The latest beta version offers a new global setting to disable UPnP for dynamic port mappings in the Settings->Connection dialog:
https://www.smartftp.com/download

What OS are you running? If it's XP, do you have the SP2 installed? The UPnP framework has been improved in the SP2.

Thank you for your time.

-Mat

Dear Mat,

I did a bit more thorough testing. From many attempts, it seems that the first FTP session works fine with UPNP portmapping, but all the following don't (which means I have to restart SmartFTP after every FTP session to get UPNP working). This has thus far always been the case (which is why I question if it really is instability). This includes whether I close or leave open the first FTP session. Secondly, it seems whether I just close the session, or explicitly send the QUIT message to close it cleanly does not make a difference.

I am running WinXP SP1. I really do not wish to install SP2, unless you really think it might help you debug this.

Best Regards,

J

Problem was solved in latest .46 build.