Active mode FTP STOR problem

[DuncanW]

I'm trying to transfer files via FTP to a box running an embedded OS & the PC seems to drop the connection when sending the PORT command.

The error I get back is code 66, (TCP Read in TCP Read xTP Reply.vi:6->FTP Get Command Reply.vi:5->FTP Command.vi:3->FTP [PORT].vi->FTP Open Data Connection.vi->FTP Data Send.vi->FTP [STOR].vi->mFTP.vi where mFT.vi is my LabVIEW app).

I've tried to simulate it using a local Filezilla server and an FTP server on a Unix box on our company network, and I can't get the FTP to connect there either. If I set the Active input to False, Filezilla & the Unix box FTP server both accept & receive the files.

Unfortunately the embedded OS doesn't support passive mode, so I'm wondering if there is a problem with LabVIEW's Active mode support & if anyone knows a workaround?

Cheers

Duncan

[John.P]

Hi Duncan,

Looking at this information it appears active and passive ftp use different ports.

I would suggest checking firewalls that could be blocking the communication in active mode.

Hope this helps,

John

[DuncanW]

Thank you John,

Yes, that's possible although I'm not using a firewall.

Driiling down in the LabVIEW code, the problem is that in Active mode, the FTP Validate Data Connection VI is run and that fails to validate, so closes the connection.

I'm currently testing it on my PC with a local Filezilla FTP server and specifying the PCs IP address, but the Validate Connection vi does it's check & comes back with the Windows 'Full Computer Name' rather than IP address, so when it converts both to Net Address using String to IP VIs, it get different values.

I've just tried specifying the Windows Full Computer Name instead of the IP address & that successfully transferred files to the local server using Active mode.

So, it looks like there's a LabVIEW problem to do with the FTP Validate Data Connection VI or the String To IP VIs, but it looks like I have a workaround, albeit nasty!

I need to now discover if it's the same issue with transferring to my equipment with embedded FTP server application. I'll test that & report back here.

Cheers

Duncan

[DuncanW]

Yes, the problem again is the LabVIEW FTP driver.

In the FTP Open Data Connection.vi, TCP Wait On Listener.vi has an input 'Resolve Remote Address', which defaults to True and internally that uses the IP to String vi, but that has a Dot Notation input, which defaults to False, so the Remote Address output ends up being unresolveable garbage rather than a valid IP. In my case, it returns the local PC Full Computer Name when talking to a local FTP server & beggers belief, but it returns my windows login name when talking to the remote box! This obviously fails to validate when comparing it to an IP address of my remote box!

I now need to see if I can fix this pile of poo & distribute the fixed version rather than it using the FTP driver in the LV runtime.... 

Cheers

Duncan