Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Aug 2002 02:00:03 -0700 (PDT)
From:      "Ted Mittelstaedt" <tedm@toybox.placo.com>
To:        freebsd-bugs@FreeBSD.org
Subject:   RE: misc/42172: ftp and fetch client needs an active command line option now
Message-ID:  <200208300900.g7U903Vm086410@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/42172; it has been noted by GNATS.

From: "Ted Mittelstaedt" <tedm@toybox.placo.com>
To: "Peter Pentchev" <roam@ringlet.net>
Cc: <bug-followup@FreeBSD.org>
Subject: RE: misc/42172: ftp and fetch client needs an active command line option now
Date: Fri, 30 Aug 2002 01:51:25 -0700

 >-----Original Message-----
 >From: Peter Pentchev [mailto:roam@ringlet.net]
 >Sent: Friday, August 30, 2002 12:00 AM
 >To: Ted Mittelstaedt
 >
 >Actually, here, on 4.6-STABLE as of yesterday, it seems to work with
 >fetch(1), too:
 >
 
 Well, in digging deeper I think that there's something else going on
 here that is making fetch different than a get from FTP.  Perhaps this
 ought to be written up in a different PR - but I don't know which one
 (fetch or the ftp client) is violating the spec.
 
 Fetch does see the variable setting, true, (of course this isn't
 documented in the fetch man page and should be) but the transfer is
 still failing - it just fails differently.
 
 I've included 2 debugging runs here, the first is fetch with the
 FTP_PASSIVE_MODE=NO set into the environment - this one is failing.  The
 second is me doing it manually with the ftp client - that succeeds.  This
 is 4.5-RELEASE.
 
 I believe the reason that fetch is failing from the Snap server is because
 it is issuing a MDTM for the file _first_, before actually getting the
 file.  The ftp client issues the MDTM _second_, after getting the file.
 In an active FTP session I think you have to close and reopen the
 data channel each time - perhaps issuing another port command - and
 the successive RETR and MDTM on the same channel isn't allowed in
 active mode FTP but permitted in passive mode?
 
 --------first run------------------
 
 $ fetch -v -v ftp://tedm:XXXX@mrssnapper.ipinc.net/tedm/trs
 ---> mrssnapper.ipinc.net:21
 looking up mrssnapper.ipinc.net
 connecting to mrssnapper.ipinc.net:21
 <<< 220 Service ready for new user.
 >>> USER tedm
 <<< 331 User name okay, need password.
 >>> PASS XXXX
 <<< 230 User logged in, proceed.
 >>> TYPE I
 <<< 200 Command okay.
 >>> CWD /tedm
 <<< 250 Requested file action okay, completed.
 >>> SIZE trs
 <<< 213  48
 size: [48]
 >>> MDTM trs
 <<< 213 20020820132731
 last modified: [2002-08-20 13:27:31]
 binding data socket
 >>> PORT 205,139,102,3,192,15
 <<< 200 Command okay.
 initiating transfer
 >>> RETR trs
 <<< 125 Data connection already open; transfer starting.
 fetch: trs: Data connection already open; transfer starting
 $
 
 ----------end of first run-------------
 
 --------second run----------------------
 
 $ ftp -n -v
 ftp> debug
 Debugging on (debug=1).
 ftp> passive
 Passive mode off.
 ftp> open mrssnapper.ipinc.net
 Connected to mrssnapper.ipinc.net.
 220 Service ready for new user.
 ---> SYST
 530 Not logged in.
 ftp> user tedm
 ---> USER tedm
 331 User name okay, need password.
 Password:
 ---> PASS XXXX
 230 User logged in, proceed.
 ftp> bin
 ---> TYPE I
 200 Command okay.
 ftp> cd /tedm
 ---> CWD /tedm
 250 Requested file action okay, completed.
 ftp> get trs
 local: trs remote: trs
 ---> SIZE trs
 213  48
 ---> PORT 205,139,102,3,192,19
 200 Command okay.
 ---> RETR trs
 125 Data connection already open; transfer starting.
 100%     48       00:00 ETA
 226 Closing data connection. Requested file action successful.
 48 bytes received in 0.02 seconds (3.06 KB/s)
 ---> MDTM trs
 213 20020820132731
 ftp>
 
 -----------end of second run--------------------- 
 
 Ted            

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208300900.g7U903Vm086410>