World: r3wp

The lines directly above that read:

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> PASV

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> 227 Entering Passive 
Mode (192,168,1,20,15,187)
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD somedir/

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/somedir" is current directory.
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> TYPE A

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Type set to 
A
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> LIST

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 150 Connection 
accepted

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 226 Transfer OK
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD /

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/" is current directory.

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> PORT (ip and port 
info here)

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Port command 
successful
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD somedir/

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/somedir" is current directory.
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> TYPE A

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Type set to 
A
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> LIST

If I setup my firewall to accept incomming connections, I got:
Net-log: "150 Opening data channel for directory list."
Net-log: "Closing listen port 3797"
Net-log: "Closing data port 69.12.157.73 3797 62038"
Net-log: [none ["226" "250"]]
Net-log: "226 Transfer OK"
Net-log: "Opening listen port 3798"
Net-log: [["PORT" port/locals/active-check] "200"]
Net-log: "200 Port command successful"
Net-log: ["TYPE I" "200"]
Net-log: "200 Type set to I"
Net-log: [["RETR" port/target] ["150" "125"]]
Net-log: "150 Opening data channel for file transfer."
Net-log: "Closing listen port 3798"
Net-log: ["low level read of " 2048 "bytes"]
Net-log: ["low level read of " 2048 "bytes"]
Net-log: "Closing data port 69.12.157.73 3798 62039"
Net-log: [none ["226" "250"]]
Net-log: "226 Transfer OK"
Net-log: "Caching cmd-port 69.12.157.73 3796 21"
== "now 22-Jan-2007/16:11:08+1:00"

From my point of view, Rebol is working with passive and active mode 
as well. What's exactly your problem?

If you upload a lot of files and sometimes get error, maybe it's 
problem with connection or something like that

My problem is that I am trying to do a remote backup of a complete 
directory that may contain thousands of files.  On a local area network, 
it always works fine (not using FTP), but when using FTP, it locks 
up seemingly at random.

what does it mean lock ups? That you cannot upload any file anymore?

I'm not certain, but it only seems to happen when backing up when 
part of the path is over wireless.  At least that is where the problem 
was detected and it is also how I've been testing it.  But then I 
noticed that the FTP server gave the 425 error at the same time the 
lockup happened.

No, by "lock up", I mean Rebol sits and waits forever for a response 
and never continues.  It never times out.

And you are using just a read and write?

Maybe you should use some more sophisticated method.

read and  write  should still work.

If you backup so many files, you should open just one connection 
and comunicate with the server. Not to open and close connections 
for every file.

Read and write is working... at least now:-)

I'm doing an open and copy on the source machine and I'm writing 
to the FTP server using 'write/binary/append

But it doesn't seem to hang up while appending to an existing file. 
 The only time I have seen it hang up is when Filezilla returns a 
425 message.

where was the download  for thesdk? Is  that  public?

What part of the SDK do you want?  The ftp-prot.r file?  I can place 
that on the FTP server under the rebol3 account.

yes, to make sure i use the same.

maybe the 425  is not handled correctly.

OK.  It's on the FTP server now as prot-ftp.r

In the root level.

A simple search doesn't find 425 anywhere in that protocol.

you may try my ftp-sync script ftp://rebol3:[rebol3-:-69-:-12-:-157-:-73]/test/ftp-sync-latest.zip 
I never used it in the real life, so maybe it's not perfect as well.

Do I replace the regular prot-ftp.r with this?

no... and I see, the zip is not complete, I uploaded complete script 
to:  ftp://rebol3:[rebol3-:-69-:-12-:-157-:-73]/test/ftp-sync_latest.r

And it certainly require some fixes

as it douesn't recognize, that the file is already uploaded and with 
same or newer date

there is just a little mess with the source and target path, as I 
was using it in the scenarie, where the target path was accessed 
thru http, it should not be difficult to fix it, but I don't have 
more time now

http://support.microsoft.com/kb/129395/could match?
with wireless port is more often in wait-state?

the last message can be located by looking for list-check, then some 
port-opening seems to happen.

Volker, this definitely seems like it could be the issue.

can you add some wait between  files in your code, to give it  time 
 to relax? just guessing.

Smooth-Copy has an adjustable wait mechanism built in, but it may 
make the overall length of the transfer too long.  I'll have to put 
some debugging statements in prot-ftp.r to see if I can isolate the 
problem and figure out how to go around it.

Thanks for the help you have given so far!

np

Pleae tell when you  find out where it hangs. Curious :)

If I find a solution, I'll post the fix and let you know.

Yup, just verified that Rebol always hangs up when the FTP server 
logs a 425 response: "425 Can't open data connection"

I've found THE LINE that Rebol hangs up on when the FTP server returns 
a 425 response.  It is the line with the ;<--- after it below:

	accept-connect: func [port type][
		if not port/locals/passive [
			either port/locals/listen-port [
				if type <> 'new-dir [
					port/sub-port: first port/locals/listen-port ;<---
				]
				close-listen port
				port/locals/listen-port: none
			][
				net-utils/accept-proxy port/sub-port
			]
		]
	]

Obviously, it is in an infinite wait for a listen port that will 
never come.  Can you see any problems if the line were changed to:


if port? lstn-prt: wait [any [system/schemes/ftp/timeout system/schemes/default/timeout 
30] port/locals/listen-port][port/sub-port: lstn-prt]

there should  be a timeout, yes. Would  trigger an error too, how 
 is that done in the right way with ports? Because i do not know 
what this code  does without a port/subport.

what confuses  me, this code runs also in passive  mode?


an idea of mine is to listen on both ports, control and this one. 
if the server sends the 405, its never processed because we dont 
listen there. Should  listen on both ports and still handle commands. 
But do not know what the  right vars are.  Waiting for the skilled 
 ftp-patchers  before examining^^

In limited testing, my patch above (slightly modified to remove typos) 
works.  If the 425 occurs, after a timeout period the patched protocol 
picks up right where it left off.  But yes, I would really like the 
skilled ftp-patchers to take a look at the problem and see if they 
can come up with a better fix.

Grats :)

Are you sure that this happens in passive mode, despite  " if not 
port/locals/passive [  "


I found this line also to be the cause for infinite waiting when 
using ftp with active mode thru a firewall . But activating the passive 
mode eliminated the need for a patch on  my side.

Anyone got a quick script I can use to determine the ip address of 
a PC on the local network?

I presume I need one server script and one client script

Graham: do you mean IP adress of your computer?
>> read dns://
== "boleslavb967"
>> read dns://boleslavb967
== 10.10.8.179

no

I just get 127.0.0.1 when i do that.

it's a virtual nic ...