FTP Troubleshooting: Applying a Methodology

During one of my onsite training sessions, a student  asked if I could look into a problem his company was trying to troubleshoot: After the  FTP server was upgraded, an application wasn’t working anymore. They were stumped when they tested both FTP active and passive connections with a FTP client, which worked. They were basically having issues trying to reproduce the problem.

In this article, I will demonstrate that you don’t need to know all the nitty-gritty details of a protocol or application (FTP in this case) when you approach an issue. A sound and consistent methodology should get you to a point where you may not know what the root cause is, but you should have an idea what to research next.

In this case, I confirmed that the problem or error was consistently happening before starting with a packet capture of the reported problem. After capturing the application "hanging," we reviewed our trace and it was obvious what happened.

FTP-1A.jpg

Note that the PORT command is used by an FTP client to establish a secondary connection (address and port) for data to travel over. The first four numbers identify the client’s IP address and the next two values are used in a formula to identify the TCP port number for data. The formula is the first number multiplied by 256, then add the second value. In this example the data port will be over TCP port number 51068.

Now that we can clearly see that the port error message is causing the application to hang, I asked what they did next. They used FileZilla FTP client to test passive and active modes to see if either work, but said neither worked. They suggested we test again using FileZilla and perform a capture so we can try to figure out why both failed. For an initial test, I always use the software default settings. In this case, FileZilla’s default transfer mode is just "Default." Odd since Active and Passive are the other two options.

FTP-2.jpg

In our test, FileZilla worked, and  our trace showed why: FileZilla used passive mode as its default, or possibly tried passive first. You can see in the trace below that the PASV request was sent by the client and the server accepted in frame 25.

FTP-3A.jpg

We changed the transfer setting to active, expecting this next test to fail since active will send a port command. Just as before, it worked as well. We reviewed the trace and were caught off guard with what FileZilla did.

FTP-4A.jpg

You can see in frames 25 and 26 where FileZilla unsuccessfully tried the port command for an active connection. After that failed, FileZilla successfully requested a passive connection in frames 27/28. Even though we manually selected Active, FileZilla automatically went to passive. Now we know why FileZilla worked with default, active, and passive modes.

The group asked me how we can test a FTP session in active mode and I suggested using Internet Explorer. We then ran a test to see Internet Explorer's default settings.

FTP5A.jpg

As you can see, Internet Explorer used passive mode. You can change this setting in Internet Options.

FTP-6.jpg

We unchecked the Passive FTP box and tried again.

FTP-7A.jpg

As you can see above, Internet Explorer tried the Port command unsuccessfully and then failed. It did not try a passive connection like FileZilla did previously.

We were able to prove and document that the upgraded FTP server did not support active sessions or specifically, the port command. We passed our findings on to the application/server group, which investigated and asked us to test again, and our active test worked just fine. We then tested the application and it worked flawlessly.