Re: FTP Error 426
- From: chrismason@xxxxxxxxxxxx (Chris Mason)
- Date: 20 May 2007 15:05:49 -0700
John, George and Pat
Regarding the "Urgent flag", from RFC 793 - Transmission Control Protocol:
<quote>
2.8. Data Communication
...
TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly.
...
3.1. Header Format
...
Control Bits: 6 bits (from left to right):
URG: Urgent Pointer field significant
...
Urgent Pointer: 16 bits
This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set.
</quote>
Going back to the original post from John:
The FTP server received an Out Of Band ABOR subcommand from the FTP client ...
I guess it could be said this is a case of "too much information" - or just information badly expressed. It would be better if it had said the following:
"The FTP client has sent an FTP abort (ABOR) command[1] (naturally sent as TCP 'out-of-band' or 'urgent' data) to the FTP server ..."
[1] If the terminology used by RFC 959 is followed - as it ought to be - the correct description is "command" not "subcommand", specifically an "FTP service command", see section 4.1.3.
Regarding SNA "expedite", from SNA Formats:
<quote>
EFI - Expedited Flow Indicator. It has the following meaning:
0 normal flow
1 expedited flow
Note: The EFI designates whether the PIU belongs to the normal or expedited flow.
Normal-flow PIUs are kept in order on a session basis by PC; so are expedited-flow PIUs.
Expedited-flow PIUs can pass normal-flow PIUs flowing in the same direction at queuing points in TC within half-sessions and boundary function session connectors.
</quote>
Regarding the comparison of SNA "expedite" and TCP "urgent": DFASY is the keyword in assembler macros used in the VTAM API in order to refer to request units which are sent with the "expedited flow indicator" - as opposed to DFSYN. The "urgent" or "out-of-band" function of TCP is variously identified with C #defines in the socket API as it applies to the TCP protocol with MSG_OOB, SO_OOBINLINE and SIOCATMARK.
Since the "expedited flow indicator" is preserved in the various SNA formats for the "transmission header", it stands a chance of being respected at any queuing point within the SNA connection-oriented network, a chance absolutely denied the "urgent" or "out-of-band" function of TCP in the connection-less IP network[2]. Thus I hesitate to draw what would be a false comparison between what the "expedited flow indicator" can achieve in an SNA network with what the I now feel at liberty to qualify as the *so-called*[2] "urgent" or "out-of-band" function of TCP.
[2] Oh dear, am I letting my affiliations show again! I have these Dr Strangelove moments from time to time. <g>
What George reported in his "On the meaning of out-of-band:" is clearly taken from an FTP source since it mentions the ABOR command and is entirely compatible with what I described earlier - as is what Pat found.
Also George may have found a possible explanation in his "On the return code 426:". As John eventually revealed in the response to Greg Shirey, the failure happens immediately after the data connection is supposed to be established and, as mentioned originally, it happens a number of times before the FTP transfer finally succeeds.
If the failure was absolute and immune to retrying I would suspect a firewall adamantly opposed to supporting FTP - or perhaps only traditional - as opposed to what CS IP calls "firewall-friendly" - FTP. As it is I wonder if it isn't - a wild guess - a firewall being slow to respond to being able to "approve" the FTP data connection.
Of course, it's quite a handy procedure actually to follow up any error messages that might happen to appear.
Checking out
EZA1735I Std Return Code = 04426, Error Code = 00002
We find that
04 = the subcommand code
426 = the last reply code received from the FTP server.
and
00002 = the client error code set by the FTP client.
Referring to 4.11.2 FTP client error codes in z/OS Communications Server IP User's Guide and Commands V1R8, we find the following, somehow truncated from a 5 digit number to a 2 digit number:
"02 FTP_SERVER_ERROR Error reply returned by the server."
This seems to suggest that the client got the impression that the server was behaving badly[3]. Perhaps tracing can reveal what really happens - which is fine if it is reproducible as implied.
[3] Beware of course that in "smoke and mirrors" world of networking, whether SNA or IP - but particularly IP - what arrives is not always what was sent by the supposed partner.
Well, conscientious as ever - I hope - I thought it best not to mention something without researching a little. It turns out that FWFRIENDLY is a "client-side" parameter - so why not give it a try. Also I was directed to the EPSV4 parameter, the description of which has the right sort of "ring" about it - "If your client has trouble establishing a data connection" - as a possible way out of the problem as described - with all the key functions piled together, "security protected", "encrypted session", "NAT", "firewall" ... you name it, we've got it covered!
Chris Mason
----- Original Message ----- From: "Patrick O'Keefe" <patrick.okeefe@xxxxxxxxxxxx>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@xxxxxxxxxxx>
Sent: Saturday, May 19, 2007 2:51 AM
Subject: Re: FTP Error 426
On Fri, 18 May 2007 11:26:35 -0500, George Kozakos <gkozakos@xxxxxxxxxxx> wrote:
...
On the meaning of out-of-band:
It relates to the method
of signaling between the client and server. Normally subcommands
are processed one after the other and are received within the data
stream (or in band). In the case of an ABOR, you don't want the other
end to wait to get your command, so it is sent Out of Band. You really
want to interrupt the other end and have it respond to the ABOR
instead of finishing what it was doing.
Out of Band is a method of signalling that gets processed immediately.
Please don't ask me what any of that means.
...
There was apparently a change in terminology somewhere along the
line. I found a few pages on the web that said "out of band" TCP data
is TCP data sent with the "Urgent" flag. THAT is mentioned in the TCP
RFC (RFC0793 / STD0007) - data sent outside of the normal TCP flow
controls, data that should be acted on right away by the receiver. The
"out of band" idea is that this urgent data should be processed even if
there is buffered "in band" data ahead of it.
But in this case we already sort of new that. An ABORT was sent
and the receiver should process it right away. Ok. But why?
The only thing you can say for sure is that the remote end didn't like
something. Hopefully there is some indication of a problem on the
remote end. While there isn't much to go on, but it may be significant
that this an ABORT request (which is part of FTP, I think) rather than
a RESET flag.
Pat O'Keefe
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- References:
- Re: FTP Error 426
- From: Patrick O'Keefe
- Re: FTP Error 426
- Prev by Date: Re: Compuware installs get an "F"
- Next by Date: Re: (Hopefully) simple SMPE question
- Previous by thread: Re: FTP Error 426
- Next by thread: RE: 3350 errors
- Index(es):
Relevant Pages
|
Loading
