Bug 3975

Summary: (gftp, not ftp) All uploads reported as failed.
Product: [Retired] Red Hat Linux Reporter: joel
Component: gftpAssignee: David Mason <dcm>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-14 22:11:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description joel 1999-07-10 03:52:29 UTC
When trying to upload files to a SCO Unix system, every file
uploaded, reported as failed by TFTP. The some of the
programs configuration switches, also seemed not to work.
(Passive Mode Switch) Turning it off had no effect it still
transfered in passive mode.

Comment 1 Jeff Johnson 1999-08-28 22:12:59 UTC
I'm not sure what problem is being referred to since
1) tftp is very sldom (and very insecurely) used for uploads
2) there is no "passive mode" in tftp.
3) If you meant ftp rather than tftp, then there is insufficient
information to diagnose the problem.

Comment 2 joel 1999-08-31 13:27:59 UTC
When trying to upload files to a SCO Unix system, every file
uploaded, reported as failed by GFTP. The some of the
programs configuration switches, also seemed not to work.
(Passive Mode Switch) Turning it off had no effect it still
transfered in passive mode.

Comment 3 joel 1999-08-31 13:31:59 UTC
GFTP is in X windows environment

Comment 4 Michael K. Johnson 1999-09-25 16:51:59 UTC
I presume that you are using gftp-1.13-4 that shipped with 6.0, not
the update gftp-2.0.3-1 that we released a few months later as an
update.

Please try the update, or the latest gftp from rawhide
ftp://ftp.redhat.com/pub/rawhide/i386/RedHat/RPMS/gftp-2.0.4-1.i386.rpm
and see if they fix the bug.

Comment 5 Elliot Lee 2000-02-14 22:11:59 UTC
No further comments from reporter - assumed fixed.