Fetch Softworks

server-to-server -- not (5 posts)

• Started 20 years ago by paleolith
• Latest reply 20 years ago from paleolith

• paleolith Member

  Just downloaded (and licensed) 4.0.3 to get the server-to-server feature. (I've been using Fetch for 10ears.) But when I tried it, I found that the transfer was going through the client anyway. I could tell this by the port commands in the Fetch transcript, as well as by the speed (14KB/s rather than the 80KB/s that I've observed on server-client transfers between those hosts).

  I had set the "obscure option" to use direct server-to-server transfers. BTW, this should NOT be "obscure", since it defaults to off!

  I found the note that said Fetch will not initiate a server-to-server transfer if it thinks the servers are incompatible or the transfer might be unsafe. But it's totally silent on the factors it uses to determine compatibility and safety, leaving me at a loss to find the reason.

  I'm not surprised that I have to debug the connection between these servers -- one is a fairly standard server but the other is the Unisys MCP FTP server, which gives file listings that don't conform to usual practices (though they conform to the relevant RFCs). I have good reason to believe that a transfer between these servers will work -- it works when I use an FTP client on the MCP side, and that uses the same code for the transfer. But Fetch isn't helping me.

  I'd much rather have an option to *force* a server-to-server transfer and then report any errors to me.

  Is there anywhere I can go from here?

  Edward Reid

  Posted 20 years ago #

• Jim Matthews Administrator

  Could you post the contents of the Fetch Transcript window after trying a server-to-server transfer? That should show me why Fetch is falling back to an indirect transfer.

  The option to do direct transfers is off by default because there are many situations where it hangs, and I wanted to make reliable behavior the default.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 20 years ago #

• paleolith Member

  Originally posted by JimMatthews:

  [B]Could you post the contents of the Fetch Transcript window after trying a server-to-server transfer?/B]

  Thanks:

  Connecting to cp2mcp.mgsinc.com port 21 (6/19/03 9:44:57 AM)
  Connecting to ftp.mgsinc.com port 21 (6/19/03 9:44:57 AM)
  220 FTP Services for ClearPath MCP: Server version 47.150.069
  USER ereid
  220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [mgs.mgsinc.com]
  USER xxxxxxxxx
  331 UserName received; please send the PassWord.
  PASS
  331 Password required for xxxxxxxxx.
  PASS
  230 User EREID logged in; you may proceed.
  230 User xxxxxxxxx logged in.
  SYST
  SYST
  215 Unknown Product Line FTP version 47.150.069 (MCP version 47.189.8174)
  215 UNIX Type: L8
  PWD
  PWD
  257 "(EREID) ON MGS1" is the current working directory.
  257 "/" is current directory.
  MACB ENABLE
  MACB ENABLE
  500 The MACB command is unrecognized by this Server.
  500 MACB not understood
  CWD (EREID)TEST ON MGS1
  CWD incoming/WON
  250 CWD command successful.
  250 The current working directory is now "(EREID)TEST ON MGS1".
  PWD
  257 "/incoming/WON" is current directory.
  PASV
  227 Entering Passive Mode (66,200,18,240,128,157)
  STOR FVPLOG
  125 Continuing the Type ASCII Data connection for "(EREID)TEST/FVPLOG ON MGS1".
  SIZE FVPLOG
  213 3468
  MDTM FVPLOG
  213 20030619000313
  PORT 192,168,1,4,138,167
  200 PORT command successful
  RETR FVPLOG
  150 Opening ASCII mode data connection for FVPLOG (3468 bytes)
  226 Transfer complete.
  226 Transfer complete; Data connection closed.
  Transfer complete at 6/19/03 9:45:05 AM
  PORT 192,168,1,4,252,37
  200 PORT command successful
  LIST

  etc

  Note that apparently my router (DSL modem), which is doing NAT, must also be fixing up the FTP PORT commands.

  Edward

  Posted 20 years ago #

• Jim Matthews Administrator

  NAT generally keeps direct server-to-server transfers from working, because the PORT command (telling one server to connect to the other one) gets re-written. I'm not sure what's happening in the transcript you posted, because the address in the PORT command doesn't appear to be a server address (it looks like the address of a machine on your side of the NAT device).

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 20 years ago #

• paleolith Member

  Hmm ... I would have thought that a NAT translating FTP would be smart enough to only translate addresses in the local space. Obviously not -- just now I finally caught it. I suppose the NAT software was written without server-to-server transfers in mind.

  Today I see the entire sequence. On the first try, Fetch did indeed attempt a true server-to-server transfer. The transcript shows

  PORT 66,200,18,235,207,98
  200 The next Data Port open will be Active to 199.44.20.3 #65379

  so obviously the NAT did mangle it.

  The transcript I posted previously was only of the transfer via the client. At that time I did not realize that Fetch had earlier attempted to do a direct server-to-server and had fallen back to indirect due to failure, so I didn't look for that part of the transcript. At least I assume that's what happened -- it definitely happened today, and I just don't remember about the previous time.

  Thanks,

  Edward

  Posted 20 years ago #