Your best friend for file transfer.

Fetch application logoFetch

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

This is an archived topic. The information in it is likely to be out-of-date and no longer applicable to current versions of Fetch.
  • Started 11 years ago by paleolith
  • Latest reply 11 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 11 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 11 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 11 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 11 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 11 years ago #

Topic closed

This topic has been closed.