Field Point FTP getting error 425

[GregFreeman]

Hey all, this is a bit of a stretch but I figured I'd post anyways to see if anyone had seen this problem before and solved it. I have 3 cFP going through a switch and randomly they will have connection problems; they will open a connection, but return error 425. Sometimes they also give error 550 (unable to find the directory) eventhough I am just trying to ftp to the root. When I see the problem with our software as it tries to open a FTP connection to the field point, I see the same problem with FileZilla; it gets the same error when trying to connect to the cFP. Everything I have found online talks about the router being the issue, but even when I connect straight into the cFP the problem still exists. It is an intermitant problem, so I hate to reboot the cFP and fix the issue because I do not know when it will reproduce itself again. 

It's frustrating because we (us RT users) have no control over the FTP server on the RT as far as I know, so I can't mess with or look at any of those settings.

And no, passive/active connection is not the issue.

[Ben]

Only thought that comes to mind is "how busy" is the FP unit?

Busy FP units will tend to there internal tasks before responding to other requests.

Does retrying result in a good request?

Ben

[GregFreeman]

---

@Ben wrote:

Only thought that comes to mind is "how busy" is the FP unit?

Busy FP units will tend to there internal tasks before responding to other requests.

Does retrying result in a good request?

Ben

---

Once it's down, it's down until reboot. This happened before and we attributed it to being busy. The problem is it just reared it's ugly head during a week while the line was down . There goes that theory. We thought maybe my code wasn't closing and reopening connections properly on errors, which may have been eating up the ports after some amount of time. But, we have been unable to prove that is the case after stepping through the code. Seems to funciton as expected. We may just switch to TCP/IP to transfer file content instead of FTP at some point, especially if this keeps acting up.

[Ben]

Don't know if it will help you but I will share.

Errors durring acquisition (eg open thermocouple) will return a non-empty source string requiring memory allocated where it was not need prior.

So check of errors and check the mem useage at the time of failures.

I resorted to blanking out all source fileds in error clusters for the apps that have to run 24 X 7 and never go down.

Just trivia

ben

[Zach-H]

Have you been monitoring your Memory or CPU usage while the controllers are running?

If you're running out of either I would expect the controller to start dropping network communication. 

Do you lose any other communication methods to the controller's when you're unable to complete an FTP transfer from them?

Do they continue to show up properly in MAX as connected and running?

How often do you attempt to transfer files via FTP to/from the controllers?

Is there any pattern to the amount of time between restarting the controllers and being unable to open an FTP session?  

[Ben]

Zach's reply reminded me yet another issue I have seen.

We had a customer that downloaded recipes and after it finished (could be a day or more later) the FP would crash when grabbing the report. That would up being a log file produced for the recipes run was growing to exceed available memory when running the long recipes.

Again, look to memory and look twice at any string used on a RT system.

Ben

[Texas_Diaz]

What KIND of cFP do you have?  If the cFP is VxWorks-based (cFP-22xx) the socket pool and the file handle pool is shared - if you run out of file handles, you also run out of sockets, and vice versa.  Check to see if you're leaking file handles.

-Danny