 USR56K
join:2000-05-20
Lynnwood, WA
1 edit | MPE FTP error code translation? For the life of me, I can't find out what FTPLASTERR = 3473608 means. It originated from an HP e3000 system which failed to connect to a Windows FTP server.
Thoughts?
--
If it's not on Google, then it doesn't exist.
**DC++ FAQ** |
|
Reviews:
 ·Frontier FiOS
| Re: HP-UX FTP error code translation? An e3000 is an MPE/iX box not a HP-UX box.
I haven't worked on an MPE box in over a decade; however, if you have a login you should be able to look at that job stream to understand the context of why that return code is being set. From what I recall any non-null return is custom so assuming the job is documented you should be able to figure out what it means.
In case your MPE-fu is rusty HP still appears to have the command reference kicking around online ->
»bizsupport1.austin.hp.com/bc/doc···0563.pdf
If you can't login the other thing I'd suggest is taking a packet capture and looking at the actual FTP conversation to see what is being sent/returned between hosts to see if it looks correct.
--
Jon Cellini
You've glimpsed the fist within the Bene Gesserit glove. Few glimpse it and live. |
|
USR56K
join:2000-05-20
Lynnwood, WA | reply to USR56K
Below is a snippet of the failed job. Unfortunately, it doesn't seem very useful. Not sure why its stating password required when it IS being passed to it too.
165 Connected to 140.xxxxxxxx. (FTPINFO 40)
166 ftp> user USERNAME PASSWORD
167 331 Password required for USERNAME.
168 UnKnown Socket Error.
170
171 END OF PROGRAM
172 FTPLASTERR = 3473608
173 FTPXFERFILES = 0
174 FTPREQFILES = 0
175 FTPREPLACE = TRUE
176 FTPLASTREPLY = 331 Password required for USERNAME.
177 FTPLASTMSG = UnKnown Socket Error.
On the Windows FTP server, I see status code 230 for the USERNAME in question, so I'm fairly sure its logging in properly.
--
If it's not on Google, then it doesn't exist.
**DC++ FAQ** |
|
 dennismurphyPut me on hold? I'll put YOU on holdPremium
join:2002-11-19
Parsippany, NJ
·Verizon FiOS
 ·Optimum Online
| said by USR56K:Below is a snippet of the failed job. Unfortunately, it doesn't seem very useful. Not sure why its stating password required when it IS being passed to it too.
165 Connected to 140.xxxxxxxx. (FTPINFO 40)
166 ftp> user USERNAME PASSWORD
167 331 Password required for USERNAME.
168 UnKnown Socket Error.
170
171 END OF PROGRAM
172 FTPLASTERR = 3473608
173 FTPXFERFILES = 0
174 FTPREQFILES = 0
175 FTPREPLACE = TRUE
176 FTPLASTREPLY = 331 Password required for USERNAME.
177 FTPLASTMSG = UnKnown Socket Error.
On the Windows FTP server, I see status code 230 for the USERNAME in question, so I'm fairly sure its logging in properly. That 331 message is returned from the FTP server itself,
Not the (MPE/iX) client. You would need to figure out if the FTP server is having some sort of issue with accepting the password after the username.
Maybe change the job to execute:
USER username
PASS password
Instead of:
USER username password
I bet that would work. |
|
|
|
dennismurphyPut me on hold? I'll put YOU on holdPremium
join:2002-11-19
Parsippany, NJ | reply to USR56K
Oh, and yes, this has nothing to do with HP-UX. The HP e3000 series ran MPE/iX, which has been fully retired and no longer has support from HP. |
|
SpensergigThreadkiller SupremePremium,MVM
join:2000-03-26
Bradenton, FL | But it's still in use.
I know a fairly large operation in AL that has a couple of systems stockpiled for parts.
They'll run MPE/ix until the staff in charge ages out.
(Changeover is just too expensive.) |
|
USR56K
join:2000-05-20
Lynnwood, WA | reply to dennismurphy
said by dennismurphy:That 331 message is returned from the FTP server itself,
Not the (MPE/iX) client. You would need to figure out if the FTP server is having some sort of issue with accepting the password after the username. Alright, here are the logs from the FTP server (windows 2008 r2)
#Fields: date time c-ip cs-username cs-host s-ip s-port cs-method cs-uri-stem sc-status sc-win32-status sc-substatus sc-bytes cs-bytes time-taken x-session x-fullpath x-debug
2012-01-20 22:55:10 128.XXXXX - - 140.XXXXXXX 21 USER USERNAME 331 0 0 35 13 0 f375296c-a8a4-4022-bc38-f8e85c400672 - -
2012-01-20 22:55:20 128.XXXXX FTPSERVER\USERNAME - 140.XXXXXXX 21 PASS *** 230 0 0 523 15 0 f375296c-a8a4-4022-bc38-f8e85c400672 / -
2012-01-20 22:56:13 128.XXXXX FTPSERVER\USERNAME - 140.XXXXXXX 21 QUIT - 221 0 0 14 6 0 f375296c-a8a4-4022-bc38-f8e85c400672 - -
2012-01-20 22:56:13 128.XXXXX FTPSERVER\USERNAME - 140.XXXXXXX 21 ControlChannelClosed - - 0 0 661 34 75859 f375296c-a8a4-4022-bc38-f8e85c400672 - -
said by dennismurphy:Maybe change the job to execute:
USER username
PASS password
Instead of: USER username password
I bet that would work. I should've mentioned that this MPE job worked fine when connecting to an older FTP server (Windows 2000). All that has changed in this scenario is the newer FTP server and changing the USERNAME's password. Yes, I know the FTP server/usrname/password are functional as I can connect with no problems from my Windows workstation.
As for retirement, we finally retired ours from daily production use in December. Now the task of shipping it to an off-site hosting facility for perpetual reporting needs...
--
If it's not on Google, then it doesn't exist.
**DC++ FAQ** |
|
dennismurphyPut me on hold? I'll put YOU on holdPremium
join:2002-11-19
Parsippany, NJ Reviews:
·Verizon FiOS
·Optimum Online
| Bingo. The new FTP server isn't accepting the 'USER username password' syntax.
You need to change the MPE job to send two statements:
USER username
PASS password
The problem has nothing to do with MPE, and more to do with the new FTP server. I think the two-line syntax is more 'in-spec' anyway. The fact that the one liner worked with Windows 2000 isn't surprising.  |
|
 koitsuPremium,MVM
join:2002-07-16
Mountain View, CA
kudos:14
1 edit | RFC959 and FTP-related RFCs (RFC697, RFC737, RFC743, RFC775, RFC1639, RFC2389, RFC2228, RFC2428, RFC3659) do not mention anything about USER username password being an allowed syntax. All RFCs strictly state that the username and password must be sent individually by separate USER and PASS commands.
The reason for this is that the USER command could fail separately from the PASS command, depending upon server configuration, back-end authentication configuration, and other things which I'd rather not get into here.
For permitted command syntax, see Section 4.1 (FTP Commands, subsection Access Control Commands). For proper login methodology, see Section 5.4 (Declarative Specifications, subsection Sequencing of Commands and Replies).
EDIT: Removal of my last paragraph. The CLI FTP client USR56K  is using *might* support parsing (on the client side) the username and password separately and issuing them as separate commands to the server. For example, on FreeBSD, that syntax is permitted and subsequently submitted as two commands (USER, then PASS).
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. |
|
USR56K
join:2000-05-20
Lynnwood, WA | reply to USR56K
solved Solved.
Changing the user/pass to separate lines didn't help.
The problem ended up being is that the program was set to abort (exitonerror) if there is any kind of error returned by the remote system -- even though it DID successfully log on. Once that switch was turned off, it was able to transfer the files again. The MPE ftp client still receives a 'UnKnown Socket Error.' after logon, but we haven't decided to investigate further.
--
If it's not on Google, then it doesn't exist.
**DC++ FAQ** |
|
