PureBasic Forums - English

The current Version 0.7d of my version of the FTP_Library code is available at
http://elfecc.no-ip.info/purebasic#FTP_Library
last updated June 29, 2005

There have been substantial changes since Vs. 0.7c. Lots of debugging,
working to make it compatible with more servers, expand the logging
capabilities, and modify it to support the PORT method.

Utilizing the PORT method has proven quite difficult for me. Can't say
that it is perfect yet, although it works well with some servers on my list.
So, if you utilize the PORT method and have problems, I woud appreciate
your feedback.

NEW in Vs. 0.7d

• handle local log display when switched on
  added FTP_Type command (separated from FTP_Login)
  renamed Init_FTP_PASV to FTP_DataPort_Initialize and modified to setup PASV and PORT connections
  renamed Init_FTP_PASV_Close to FTP_DataPort_Close and modified to close PASV and PORT connections
  added FTP_DataPort_Connect (for PASV mode) to connect to the Server's designated listening port
  added FTP_DataPort_Server (for PORT mode) to create a listening port for the FTP Server to connect with to send/receive files
  modified FTP_FileGet to support PASV and PORT mode
  modified FTP_FilePut to support PASV and PORT mode
  modified FTP_GetDirList to support PASV and PORT mode
  added FTP_GetClientIP (for PORT mode security)
  added FTP_GetHostIP (for PORT mode)
  added FTP_GetVisibleLocalIP (for PORT mode)
  added FTP_Timeout_Report for all FTP commands

Terry

Hi Terry,

Thanks for the update.

As I understand it, if PASV and PORT are not issued, PORT is assumed on port 20.

So I was wondering why PORT cannot be used in "default" mode rather than via an explicit approach, that is, just assume 20

( I haven't been able to make any PORT commands work off my own bat so I am not scrounging through your code )

Num3, DarkDragon, Zapman & Terryhough:
Thank you very much guys, this is greately useful

Psychophanta wrote:Num3, DarkDragon, Zapman & Terryhough:
Thank you very much guys, this is greately useful

Any time, well here's my FTP Client(Linux and Windows Executable included):
http://www.bradan.net/downloads/Bradan%20FTP.zip

Dare2 wrote:Hi Terry,

Thanks for the update.

As I understand it, if PASV and PORT are not issued, PORT is assumed on port 20. So I was wondering why PORT cannot be used in "default" mode rather than via an explicit approach, that is, just assume 20

You're welcome. Hope it is useful.

You are correct the PORT is assumed on port 20 (per the RFCs).

And the PORT method should be the "default" mode to use.

However, assuming anything about how some of the servers work
backfires on me frequently. So, I made it more explicit. Hopefully,
if I tell the server how I want to communicate it will comply.

Also, working with PORT behind a router requires that the router
"forward" the incoming requests properly. So, if you are attempting
this behind a router or firewall, make sure the PORT range is being
forwarded correctly.

In this code, I used a range of 20 ports starting at 6000 It probably
could be port 20 alone just as easily. The PB references for
CreateNetworkServer says

Create a new network server on the local computer at the specified port. Port values can range from 6000 to 7000 (this is a recommended area space, but it can go from 0 to 65000 in reality).

but it doesn't appear to be a real restriction.

NOTE: A problem I expericence: When I use CloseNetworkServer()
it seems that the port is not closed immediately even though the
program continues immediately. Since CloseNetworkServer() doesn't
return a response, I can't capture that occurance. So, if I try to
CreateNetworkServer() on that same port again, there are problems.
I got around that by using random ports in the defined 20 port range.
Not sure whether it is my problem or a bug in PB's CloseNetworkServer()
or just a timing issue.

Personally, I prefer the PASV mode because the Client Program does not
have to act as a server at all. Much simpler and that should be more
secure.

So, why did I go to the effort to try to make PORT work when I already
had PASV working well?

1) To see if I could I wanted the code to work pretty generically.
2) Because the server software(s) I tested with are very inconsistent in
how thay assign the port to be used which created problems for my
intended use. Some servers assign random ports which may not be
open for use when they are running behind a router (my case). Another
assigns PASV ports withing a definable range, using the first port number
over and over unless the server knows that it is still open in which case it
increments the port number by one. That was not a real problem for me,
but that same server just doesn't function at all with the PORT method.
Another server requires the client to connect using the full IP address of
the server with the assigned port number, but issues the local LAN IP
address in the PASV reponse when it is running behinc a router instead of
the visible WAN IP address. In that case, the client can't locate the server
to send/receive the files.

It has been fun and a good learning process for me. I am sure I will
continue to tweak this code for some time.

Keep me posted on how things are working for you.
Terry

Wonderful! Wonderful!

You guys are great! I have been waiting a while for this, however, earlier versions weren't working for me so I decided to dig into this latest code to find out. Here's the deal.

My FTP server is running on Port 222. Port 21 is too well known and the first place hackers look. Anyway, the problem line I had in the code is in the example file:

FTP_Port.b = 222 ; normal FTP port

The max port can only be 127 when defined as a byte.

Also, FTP_Connect(Server.s, PortNo.l) in the include file accepts Port as a long.

So, I simply changed:

FTP_Port.b = 222 ; normal FTP port

to

FTP_Port.l = 222 ; normal FTP port

And then it works great.

I believe windows allows port numbers up to 65536, so it would be prudent to allow for this, since a server can be running on any port.

Cheers and thanks again guys.

Good point!

I have updated the code at the download site.

Thanks,
Terry

I've updated my soft named DropUpLoad using this library.

It's a client that only does UpLoad, but in a particular (and very simple) way.

It's not possible to change the port in my soft. I'll add that later.

If you want to try it:

http://www.rankspirit.com/downloadduleng.php

Like your site, zapman*

I've encountered a couple of funnies, wondering if you guys have any answers.

Some sites seem to dribble feed responses:

--> PASV
227 Entering Passive Mode (192,168,0,2,19,137).||
--> LIST -aL
125 Data connection already open; Transfer starting.||
--> Got mark so get data, go back to response loop
226 Transfer complete.||

Others flood it in:

--> PASV
227 Entering Passive Mode (192,168,0,2,19,137).||
--> LIST -aL
125 blah .. ||226 Transfer complete.||
--> Data is still get-able

Wondering why this happens. Seems to be windows std FTP server does one by one reponse lines, some *nix servers flood em all in at once?

And some seem to drift off to sleep. ftp . intel . com for eg, with LIST:

--> PASV
227 Entering Passive Mod(198,175,98,64,101,219)||
--> LIST -aL
150 Opening BINARY mode data connection for directory listing.||
--> TIMED OUT (no matter how long you wait)
(the data is there and got)
--> NOOP (to prod it along)
226 Transfer complete.||200 NOOP command successful.||

Needs a prod. I sent a "PROD" command string - and got the 500 error back, but it moved things along.

Another site has same problem with STAT (gnu.org or nasa, forget which). Always the same commands, so it is unlikely they get sluggish at just that point. Other sites fly through, no probs.

Any clues?


PS: I am hoping to have a rough client and FTP include file here in the next few days. Not sure if it will contribute to the knowledge base but it has been fun and may be worth something, even if just a laugh.

Hi Dare2

First, which FTP_Include are you using? Mine, Zapman's, or a modified
one?

Second, you show
227 Entering Passive Mode (192,168,0,2,19,137).||
as the response to the PASV command.

Where is the server? That response gives you a local IP address. If the
server is really a remote one, you can't connect using that address to
receive the data, so you will have problems.

I have expereienced a couple of servers running behind routers that
return the internal IP address rather than the visible internet IP address.
That makes it impossible to use them in PASV mode (for me at least).
I won't call names but it really wasn't bullitt proof.

Hi Terry,

My (extensively) modified version. Almost ground up but with lots of peeping at everyone elses

I will upload my source sometime this weekend. Just want to clean up a few things first.

With the IP, that is a local one (on my lan) however the dribble-feed result is the same on some external servers. All are windows based. Didn't feel comfortable showing their IPs here because they are private (but not mine) servers.

Cannot understand why the intel ftp times out as it does. Gotta be something I am doing but why not with all (or most) servers then?

Ah well.

Anybody got 0.7d working properly? It's missing several variables and have a bit of hard coded values in there.

TerryHough wrote:First, which FTP_Include are you using? Mine, Zapman's, or a modified
one?

And mine? You have forgotten me!

A framework for a client (uploaded using itself) is here:

http://www.tabturn.com/purebasic/PasvTfr.zip

The zip contains sources and an executable. The client uses winapi but the actual FTP is cross-platform based on what I learned here. The FTP part is quite different in some ways (I tried to write from ground up) but still based on and only possible because of the work here.

An overseas business trip has come up and I leave on Tuesday so work on this went slow (preparing for trip) so the code is not as finished as I would like. (It is really a bare-bones skeleton). But it does some things.

Currently you can browse, upload, download, delete and rename remote files.

Lots of work needed. But I learned a lot, thanks to everyone here for all the good stuff on this thread.

Comments/suggestions requested.


PS:
The 226 problem was resolved. My bad (what else) I was waiting for this before closing the PASV connection. It arrives after the pasv is closed.