Discussion:
FTP passive mode?
(too old to reply)
Charles Mills
2006-03-15 23:00:26 UTC
Permalink
Locsite FWFriendly

Charles



-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of Ronald
Wells
Sent: Wednesday, March 15, 2006 2:50 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTP passive mode?


Is there a command to enter on FTP for passive mode??

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Chris Mason
2006-03-16 00:19:47 UTC
Permalink
Charles,

... where FWFriendly stands for "firewall-friendly" as is explained in
section 5.34, "LOCSIte subcommand--Specify site information to the local
host" of z/OS V1R7.0 Communications Server IP User's Guide and Commands,
SC31-8780-05
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B950

<quote>

FWFriendly

Specifies that the FTP client is firewall-friendly. This means that data
connections will be set up from the FTP client to the FTP server.

Note: When the FTP server has an IPv6 address, data connections are always
set up from the FTP client to the FTP server without reference to the
FWFriendly setting.

</quote>

Obvious really :-{

I wonder why this description doesn't include the word "passive".

Chris Mason

----- Original Message -----
From: "Charles Mills" <***@mcn.org>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMTCP-***@VM.MARIST.EDU>
Sent: Thursday, 16 March, 2006 12:00 AM
Subject: Re: [IBMTCP-L] FTP passive mode?
Post by Charles Mills
Locsite FWFriendly
Charles
-----Original Message-----
Wells
Sent: Wednesday, March 15, 2006 2:50 PM
Subject: Re: FTP passive mode?
Is there a command to enter on FTP for passive mode??
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Charles Mills
2006-03-16 14:32:28 UTC
Permalink
I personally hate to see non-standard defaults as it is likely to confuse
vendor and similar scripts that expect a certain standard environment. Just
my opinion.

If you have to use it for every FTP, then I have to say I can't blame you
for wanting to change it. Beats a dozen calls a day from whiney users <g>.

Frankly, in my medium amount of FTP experience, I don't know why it's not
the default. Doesn't seem to hurt anything. If it hurts performance, it's
not visible in casual observation.

Charles



-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of Ronald
Wells
Sent: Thursday, March 16, 2006 6:23 AM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTP passive mode?


thanks all....
would it be best to set this as a default in the parm's>> ftpdata ??

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Steven St.Jean
2006-03-16 17:16:04 UTC
Permalink
Charles,
Post by Charles Mills
Frankly, in my medium amount of FTP experience, I don't know
why it's not the default. Doesn't seem to hurt anything.
This was also the recommendation of RFC 1579, "Firewall-Friendly FTP" .
When we implemented it in the TCPaccess FTP client at Interlink, we did just
that and made it the default behavior. It was a nightmare.

The whole thing depends on FTP servers supporting the PASV command. RFC
1579 blithely assumes that non-conforming servers "will return a '500
Command not understood' message; it is a simple matter to fall back to
current behavior." If only it were so simple!

After we'd made the change, we (or rather, our customers) discovered servers
who only thought they supported PASV, but didn't. They would send a 227
reply with a malformed IP address or port number. Or they would send a
valid 227 reply, but then they would not listen on the advertised port.

To make matters worse, we chose to implement the client's "FWFriendly"
command as a toggle. By the time we'd discovered there was a problem, a
number of customers had added the FWF command to their FTPs to turn the new
behavior off. If we reversed the default, we would cause all those
customers to revert to the unwanted behavior. We were stuck.

That was more than ten years ago now, and most of those server
implementations have probably been cleaned up, in large part because of the
problems exposed by firewall-friendly clients.

Still, the CS guys were wise to ignore the RFC and leave the old default in
place.

Steven St.Jean
Senior Developer
Software Diversified Services
http://www.sdsusa.com
Post by Charles Mills
-----Original Message-----
Behalf Of Charles Mills
Sent: Thursday, March 16, 2006 9:32 AM
Subject: Re: [IBMTCP-L] FTP passive mode?
I personally hate to see non-standard defaults as it is
likely to confuse vendor and similar scripts that expect a
certain standard environment. Just my opinion.
If you have to use it for every FTP, then I have to say I
can't blame you for wanting to change it. Beats a dozen calls
a day from whiney users <g>.
Frankly, in my medium amount of FTP experience, I don't know
why it's not the default. Doesn't seem to hurt anything. If
it hurts performance, it's not visible in casual observation.
Charles
-----Original Message-----
Behalf Of Ronald Wells
Sent: Thursday, March 16, 2006 6:23 AM
Subject: Re: FTP passive mode?
thanks all....
would it be best to set this as a default in the parm's>> ftpdata ??
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access
message: INFO IBMTCP-L
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Charles Mills
2006-03-16 17:31:33 UTC
Permalink
Oh, I hear you. Toggles are ALWAYS a DISASTER for the sort of reasons you
allude to. What's a script supposed to do?

I didn't mean in some narrow sense "I think the CS client should send a PASV
command by default." I meant in a larger sense "I don't understand what the
negative would be if all FTP ran passive."

Good to hear from you. We were Interlink partners at my old company. It was
a good product - only about two or three times as fast as the competition.

Charles



-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of Steven
St.Jean
Sent: Thursday, March 16, 2006 9:16 AM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTP passive mode?


Charles,
Post by Charles Mills
Frankly, in my medium amount of FTP experience, I don't know
why it's not the default. Doesn't seem to hurt anything.
This was also the recommendation of RFC 1579, "Firewall-Friendly FTP" .
When we implemented it in the TCPaccess FTP client at Interlink, we did just
that and made it the default behavior. It was a nightmare.

The whole thing depends on FTP servers supporting the PASV command. RFC
1579 blithely assumes that non-conforming servers "will return a '500
Command not understood' message; it is a simple matter to fall back to
current behavior." If only it were so simple!

After we'd made the change, we (or rather, our customers) discovered servers
who only thought they supported PASV, but didn't. They would send a 227
reply with a malformed IP address or port number. Or they would send a
valid 227 reply, but then they would not listen on the advertised port.

To make matters worse, we chose to implement the client's "FWFriendly"
command as a toggle. By the time we'd discovered there was a problem, a
number of customers had added the FWF command to their FTPs to turn the new
behavior off. If we reversed the default, we would cause all those
customers to revert to the unwanted behavior. We were stuck.

That was more than ten years ago now, and most of those server
implementations have probably been cleaned up, in large part because of the
problems exposed by firewall-friendly clients.

Still, the CS guys were wise to ignore the RFC and leave the old default in
place.

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Steven St.Jean
2006-03-16 18:19:55 UTC
Permalink
Charles,
[TCPaccess] was a good product - only about two or three
times as fast as the competition.
At one time, that was true. The president of Interlink once approached IBM
with a serious proposal that they should give up trying to develop an IP
protocol stack over MVS, and instead resell ours.

They didn't take him up on it. Instead, they went to work and improved
their own product's performance by several orders of magnitude.

I like to think we had something to do with that.

Steven
-----Original Message-----
Behalf Of Charles Mills
Sent: Thursday, March 16, 2006 12:32 PM
Subject: Re: FTP passive mode?
Oh, I hear you. Toggles are ALWAYS a DISASTER for the sort of
reasons you allude to. What's a script supposed to do?
I didn't mean in some narrow sense "I think the CS client
should send a PASV command by default." I meant in a larger
sense "I don't understand what the negative would be if all
FTP ran passive."
Good to hear from you. We were Interlink partners at my old
company. It was a good product - only about two or three
times as fast as the competition.
Charles
-----Original Message-----
Behalf Of Steven St.Jean
Sent: Thursday, March 16, 2006 9:16 AM
Subject: Re: FTP passive mode?
Charles,
Post by Charles Mills
Frankly, in my medium amount of FTP experience, I don't
know why it's
Post by Charles Mills
not the default. Doesn't seem to hurt anything.
This was also the recommendation of RFC 1579,
"Firewall-Friendly FTP" .
When we implemented it in the TCPaccess FTP client at
Interlink, we did just that and made it the default behavior.
It was a nightmare.
The whole thing depends on FTP servers supporting the PASV
command. RFC
1579 blithely assumes that non-conforming servers "will
return a '500 Command not understood' message; it is a simple
matter to fall back to current behavior." If only it were so simple!
After we'd made the change, we (or rather, our customers)
discovered servers who only thought they supported PASV, but
didn't. They would send a 227 reply with a malformed IP
address or port number. Or they would send a valid 227
reply, but then they would not listen on the advertised port.
To make matters worse, we chose to implement the client's "FWFriendly"
command as a toggle. By the time we'd discovered there was a
problem, a number of customers had added the FWF command to
their FTPs to turn the new behavior off. If we reversed the
default, we would cause all those customers to revert to the
unwanted behavior. We were stuck.
That was more than ten years ago now, and most of those
server implementations have probably been cleaned up, in
large part because of the problems exposed by
firewall-friendly clients.
Still, the CS guys were wise to ignore the RFC and leave the
old default in place.
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access
message: INFO IBMTCP-L
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Fred Bohle
2006-03-20 18:00:11 UTC
Permalink
Steven, you got it backwards, IBM approached Interlink with that
request.
The (ex)pres. turned them down !!!!

Fred

-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of
Steven St.Jean
Sent: Thursday, March 16, 2006 1:20 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTP passive mode?

Charles,
[TCPaccess] was a good product - only about two or three times as fast
as the competition.
At one time, that was true. The president of Interlink once approached
IBM with a serious proposal that they should give up trying to develop
an IP protocol stack over MVS, and instead resell ours.

They didn't take him up on it. Instead, they went to work and improved
their own product's performance by several orders of magnitude.

I like to think we had something to do with that.

Steven
-----Original Message-----
Charles Mills
Sent: Thursday, March 16, 2006 12:32 PM
Subject: Re: FTP passive mode?
Oh, I hear you. Toggles are ALWAYS a DISASTER for the sort of reasons
you allude to. What's a script supposed to do?
I didn't mean in some narrow sense "I think the CS client should send
a PASV command by default." I meant in a larger sense "I don't
understand what the negative would be if all FTP ran passive."
Good to hear from you. We were Interlink partners at my old company.
It was a good product - only about two or three times as fast as the
competition.
Charles
-----Original Message-----
Steven St.Jean
Sent: Thursday, March 16, 2006 9:16 AM
Subject: Re: FTP passive mode?
Charles,
Post by Charles Mills
Frankly, in my medium amount of FTP experience, I don't
know why it's
Post by Charles Mills
not the default. Doesn't seem to hurt anything.
This was also the recommendation of RFC 1579, "Firewall-Friendly FTP"
.
When we implemented it in the TCPaccess FTP client at Interlink, we
did just that and made it the default behavior.
It was a nightmare.
The whole thing depends on FTP servers supporting the PASV command.
RFC
1579 blithely assumes that non-conforming servers "will return a '500
Command not understood' message; it is a simple matter to fall back to
current behavior." If only it were so simple!
After we'd made the change, we (or rather, our customers) discovered
servers who only thought they supported PASV, but didn't. They would
send a 227 reply with a malformed IP address or port number. Or they
would send a valid 227 reply, but then they would not listen on the
advertised port.
To make matters worse, we chose to implement the client's "FWFriendly"
command as a toggle. By the time we'd discovered there was a problem,
a number of customers had added the FWF command to their FTPs to turn
the new behavior off. If we reversed the default, we would cause all
those customers to revert to the unwanted behavior. We were stuck.
That was more than ten years ago now, and most of those server
implementations have probably been cleaned up, in large part because
of the problems exposed by firewall-friendly clients.
Still, the CS guys were wise to ignore the RFC and leave the old
default in place.
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions, send
message: INFO IBMTCP-L
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions, send
email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Gary Bortner
2006-03-20 18:19:59 UTC
Permalink
Are you sure you're not thinking about CPT? I heard IBM came and asked about just buying CPT and we figured that if they want it, it must be pretty good, so we said no.

Gary


-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU]
Sent: Monday, March 20, 2006 12:00 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: [IBMTCP-L] FTP passive mode?

Steven, you got it backwards, IBM approached Interlink with that
request.
The (ex)pres. turned them down !!!!

Fred

-----Original Message-----
From: IBM TCP/IP List [mailto:IBMTCP-***@VM.MARIST.EDU] On Behalf Of
Steven St.Jean
Sent: Thursday, March 16, 2006 1:20 PM
To: IBMTCP-***@VM.MARIST.EDU
Subject: Re: FTP passive mode?

Charles,
[TCPaccess] was a good product - only about two or three times as fast
as the competition.
At one time, that was true. The president of Interlink once approached
IBM with a serious proposal that they should give up trying to develop
an IP protocol stack over MVS, and instead resell ours.

They didn't take him up on it. Instead, they went to work and improved
their own product's performance by several orders of magnitude.

I like to think we had something to do with that.

Steven
-----Original Message-----
Charles Mills
Sent: Thursday, March 16, 2006 12:32 PM
Subject: Re: FTP passive mode?
Oh, I hear you. Toggles are ALWAYS a DISASTER for the sort of reasons
you allude to. What's a script supposed to do?
I didn't mean in some narrow sense "I think the CS client should send
a PASV command by default." I meant in a larger sense "I don't
understand what the negative would be if all FTP ran passive."
Good to hear from you. We were Interlink partners at my old company.
It was a good product - only about two or three times as fast as the
competition.
Charles
-----Original Message-----
Steven St.Jean
Sent: Thursday, March 16, 2006 9:16 AM
Subject: Re: FTP passive mode?
Charles,
Post by Charles Mills
Frankly, in my medium amount of FTP experience, I don't
know why it's
Post by Charles Mills
not the default. Doesn't seem to hurt anything.
This was also the recommendation of RFC 1579, "Firewall-Friendly FTP"
.
When we implemented it in the TCPaccess FTP client at Interlink, we
did just that and made it the default behavior.
It was a nightmare.
The whole thing depends on FTP servers supporting the PASV command.
RFC
1579 blithely assumes that non-conforming servers "will return a '500
Command not understood' message; it is a simple matter to fall back to
current behavior." If only it were so simple!
After we'd made the change, we (or rather, our customers) discovered
servers who only thought they supported PASV, but didn't. They would
send a 227 reply with a malformed IP address or port number. Or they
would send a valid 227 reply, but then they would not listen on the
advertised port.
To make matters worse, we chose to implement the client's "FWFriendly"
command as a toggle. By the time we'd discovered there was a problem,
a number of customers had added the FWF command to their FTPs to turn
the new behavior off. If we reversed the default, we would cause all
those customers to revert to the unwanted behavior. We were stuck.
That was more than ten years ago now, and most of those server
implementations have probably been cleaned up, in large part because
of the problems exposed by firewall-friendly clients.
Still, the CS guys were wise to ignore the RFC and leave the old
default in place.
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions, send
message: INFO IBMTCP-L
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions, send
email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L

----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L
Continue reading on narkive:
Loading...