HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Release Notes

Problem:

The SMTP SFF feature ( TCPIP$SMTP_SFF.EXE image) loops for a mail message that contains a single header longer than 7192 bytes. If such a message is delivered to a recipient who has email forwarded to a PIPE% MAILSHR mechanism that uses SFF (such as SpamAssassin), the symbiont will hang, waiting for the looping PIPE% child process.

Solution:

A fix has been implemented in this release.

4.15.3 SMTP Fails to Send Mail with a Record Size Greater than 4093

Problem:

SMTP symbiont had a buffer limit of 4093 characters per record it reads from the control file (CF). Any record that exceeded this limit resulted in %TCPIP-E-SMTP_CFGETERROR and deletion of that control file. This eventually resulted in loss of mail.

Solution:

With this release, the read buffer limit of the SMTP symbiont is made flexible to extend itself to the largest record size limit of a message.

4.15.4 Unprivileged User Sending MAIL Results in Security Alarms for Queue CONTROL and READ access

Problem:

When a user sends MAIL, this would be submitted to the SMTP symbiont server queue i.e., TCPIP$SMTP_nodename_00. The SMTP has to check for the existence of this queue. Hence when an unprivileged user sends a mail, the security alarms for queue control and read access are being generated.

Solution:

The code has been rectified to suppress these security alarms while searching for the queue.

4.15.5 MAIL to SMTP% Causes Security Alarms

Problem:

When a user without privileges turned on but with SYSPRV granted in the SYSUAF as an authorized privileges sends MAIL to %SMTP, this causes security alarms.

Solution:

This fix is provided in this release. The solution was to provide the appropriate privileges.

4.15.6 ACCVIO Due to Improper Parsing

Problem:

Upon starting SMTP or issuing the TCPIP SHOW MX command, there could be an ACCVIO due to improper parsing of the Authority section of the DNS response message.

Solution:

This problem is corrected in this release.

4.15.7 Selecting MX Records to Route Mails Correctly

Problem:

Selection of MX records to route mails to destination did not work according to the preference values. When multiple MX records from the DNS server are given and one of them has a preference value of 32768 or 65535, then the MX record with that value will be used first instead of other MX records with lower preference values.

Solution:

This problem is corrected in this release.

4.16 Startup Problems Corrected in This Release

The following sections describe Startup problems fixed in this release.

4.16.1 Unrecognized Command Verb Errors

Problem:

Previously, users of site specific startup and shutdown command procedures could get %DCL-W-IVVERB, unrecognized command verb errors if they attempt to define/use symbols from within those procedures.

Solution:

This problem has been corrected.

4.17 SNMP Problems Fixed in This Release

The following sections describe SNMP problems fixed in this release.

4.17.1 SNMP Poll Time Is Not Configurable

Problem:

The SNMP poll time could not be changed. At times, this would cause the SNMP process to loop consuming high CPU utilization.

Solution:

The default reset/refresh value of SNMP_POLL_TIME value is 30 seconds. This release allows the user to set the desired poll time.

4.18 Sockets API Problems Fixed in This Release

The following sections describe Sockets API problems fixed in this release.

4.18.1 Socket Function getaddrinfo() Hangs

Problem:

Two successive calls to getaddrinfo() in the same program cause the second call to hang. This is only true if the af parameter is AF_INET6 and the ai_flags parameter has not been set to AI_ALL or AI_ADDRCONFIG.

Solution:

This problem is corrected in this release.

4.19 SSH Problems Fixed in This Release

The following sections describe SSH problems fixed in this release.

4.19.1 OpenVMS SSH Does Not Support Mixed Case Passwords

Problem:

OpenVMS SSH does not support mixed case passwords.

Solution:

Mixed passwords supported, assuming the username has the PWDMIX flag set. Note that when converting an account to use mixed case passwords, for access through SSH or other method, you must exercise care in resetting the password. Specifically, beware of the following sequence:

• pwdmix flag not set, password: changeme (Can be entered in any case.)
• set pwdmix flag; now can login only with CHANGEME (all uppercase)
• reset password to be changme (lowercase)
• now can login only with changeme (all lowercase)
• remove pwdmix flag
• Now the user may be unable to login until the password is reset by system administrator.

Note that the problems shown by this example have nothing directly to do with ssh, but are a function of OpenVMS password handling.

4.19.2 Signals Cause Extraneous or Cryptic Messages

Problem:

Signals received by ssh client and server result in the display of extraneous or cryptic messages.

Solution:

Some signals are now silently ignored; others result in standard VMS/DCL output.

4.19.3 CTRL/C Did Not Work During sftp2/scp2 filecopy

Problem:

CTRL/C did not work once a filecopy had started in sftp2 or scp2, stopping the ssh/sftp/scp processes was the only way to abort copy on a large file.

Solution:

After entry of CTRL/C additional steps may be needed to restart a filecopy. For sftp, for example, it may be necessary to enter the quit command, and then restart sftp; for scp it may be necessary to enter CTRL/C a second time or a $ STOP at the DCL level.

The target file may remain locked until the client side processes have been fully stopped.

The attributes on an incompletely copied target file may not be correct. In this case a manual deletion of the incomplete target file may be needed once the client side processes have either completed or been stopped.

4.19.4 Usernames with $ Not Supported

Problem:

Usernames with $ not supported.

Solution:

Any valid OpenVMS usernames are now supported.

4.19.5 Problem With Timeout in Locking of X11 xauth Authority File

Problem:

Error in tcpip$ssh_run.log indicates timeout in locking authority file, combined with failure to run X application in the ssh session started at ssh client.

Solution:

The following documentation on a new option, DecwXauthLockAction , is drawn from that included in the file sshd2_config. , included in this release:

 # Valid options are:
 # none: no special action (default)
 #   This option is also in effect if there is no value specified, or if
 #   the variable is commented out.
 # break: break lock (xauth -b)
 # ignore: ignore lock (xauth -i)
 # file: use alternate xauth filename (xauth -f {filename})
 #
 # DecwXauthLockAction none

There is a risk to using the "break" or "ignore" options. The general rule is that whichever user exits last will write a version of the xauth file which includes only the contents at the time it opened the file + any changes that user made. Any changes from other user(s) are lost.

If a user's display station has considerable activity from different users (including applications), then using "ignore" may cause problems. Perhaps in a case of the typical ssh user, the display host is single user, and is that user's dedicated display device; in that case ignore may be reasonable.

If the user is not concerned about having multiple users on a host, then either the "ignore" or "break" values may be appropriate.

Because of the potential for lost data, users may prefer the "file" option. In this case, each ssh server that starts when the xauth file is locked will write for the user a unique xauth file, to be used only by sessions supported by that instance of the ssh server. The file is located in the user's sys$login, and has a name in the format: DECW$XAUTHORITY.DECW$XAUTHnnnnnnnn where nnnnnnnn = the 8 digit hex value of the pid of ssh server process (not of the user's interactive session process). On OpenVMS, each ssh session starts a new server process, and so the xauth file will be used by a user for a single ssh session; hence there will be no conflict with either the default xauth file or xauth files from different ssh server instances. The pid of the server process is used because given the way the base UNIX code works, the file has to be created before the interactive terminal process is created.

One restriction with the "file" option, that does not apply to the "break" or "ignore" options: $ CREATE/TERM does not work.

Because the DECW$DISPLAY logical is in the job logical name table (so that the terminal process can inherit it with the ssh server process), the DECW$XAUTH logical is in that table also, for the same reason.

For more on xauth and interaction of ssh and X11, see the DECwindows/Motif documentation, especially New Features guide, and commercially published books on X11.

4.19.6 Cannot Issue a $ CREATE TERM/DETACH from an SSH Session Itself Created Using That Command

Problem:

Cannot cascade $ CREATE TERM/DETACH from ssh session (using x11 port forwarding). That is, from window created from original session window, cannot do another $ CREATE TERM/DETACH .

Solution:

Cascading is now supported.

4.19.7 SSH Client and Server Startup Fail If the Correct Version of DECwindows Motif Is Not Installed and Started

Problem:

If the host does not have the file SYS$SHARE:DECW$SETSHODISSHR.EXE installed, client and server startup fail, even if X11 port forwarding is not requested or used. The following are possible situations:

• DECwindows Motif V1.3 is installed, but not started (executable not available).

Solution:

SSH client and server do not attempt X11 processing if the file is not found or available.

4.19.8 The SFTP Client Does Not Sense the Terminal Page Size Properly

Problem:

The SFTP client does not sense the terminal page size properly. The screen output is forced to the default setting of 23 lines per page.

Solution:

This problem has been corrected.

4.19.9 SSH Filecopy Clients Cannot Use of Group Logical Names on the SFTP Server

Problem:

Users of SCP and SFTP cannot make use of group logical names on the SFTP server. This problem occurs because the group logical name table in the SFTP server process points to the TCPIP$SSH account's group logical name table of the instead of the table of the account that is being used for the file transfer.

Solution:

The SSH file copy now points the group logical name table of the SFTP server process to the table of the group of the account that is being used for the file transfer. For example, when connecting to the account "JONES" in the user group "777", the sftp server process's group logical name table will be set to point to LNM$GROUP_000777 .

4.19.10 VMS Text Editor and the DCL SEARCH Command See SSH Server Log File Warning Messages

Problem:

VMS text editor and the DCL SEARCH command see SSH server log file messages like WARNING: Starting image in auxiliary server mode as two separate lines with the text of message on a different line from the "WARNING:" prefix.

The DCL TYPE command functions properly by displaying one line.

This behavior may cause some customer auditing procedures to fail.

Solution:

Write the warning message as a single line.

4.19.11 SSH Client Ignores Any DNS AAAA Records Belonging to the Remote Host

Problem:

The SSH client ignores any DNS AAAA records belonging to the remote host thus effectively disabling connecting via IPv6.

Solution:

Recognize DNS AAAA records.

4.19.12 Publickey Authentication Fails

Problem:

From some clients, e.g., the PuTTY client, when the username entered is other than all lowercase, publickey authentication fails.

Solution:

The SSH server now captures the original filename as sent from the client and uses it in authentication procedure.

4.19.13 Regular Expression Syntax Parsing Not Done

Problem:

Regular expression syntax parsing not being done on for AllowHosts in sshd2_config .

Solution:

Regular expressions are now parsed using the "egrep" syntax. Variables to which this appies include AllowHost , DenyHosts , AllowUsers , and DenyUsers . See examples in sshd2_config . One OpenVMS extension was retained from previous versions: To specify allow all hosts, both of the following work:

 Standard regular expression egrep syntax:
        AllowHosts  .*

 OpenVMS extension:
        AllowHosts  *

Note that this format is the only case in which the "*" is accepted in addition to the ".*". In longer expressions, both characters ".*" are still required.

4.19.14 Login Dates Manipulation Sets Off Audit

Problem:

Manipulation of interactive and noninteractive login dates for SSH session sets off audit alrms.

Solution:

The audit alarms are now suppressed for date manipulation.

4.19.15 SFTP Server Causes Auditing Alarms

Problem:

The SFTP server causes auditing alarms in the operator's log.

Solution:

Condition causing the alarms corrected.

4.19.16 SFTP File Transfers Do Not Preserve OpenVMS File Attributes

Problem:

SFTP file transfers do not preserve OpenVMS file attributes even when the SFTP client and server are both running the TCP/IP Services implementation of SFTP. Such file transfers should preserve a file's record format and file attributes and, where applicable the RMS MRS and LRL fields.

Solution:

When both the SFTP client and server are running the TCP/IP Services implementation of SFTP, file transfers preserve the following OpenVMS file attributes:

• Record format
• File attributes
• mrs and/or lrl (where applicable)

The attributes are preserved regardless of the direction of the file's transfer: to client or to server.

4.19.17 SSH Password Change Sequence Did Not Check for Password in History File

Problem:

SSH password change sequence did not check for password in history file, or for using same new password as the old one.

Solution:

Password history is now checked, unless the username has the DISPWDHIS flag set.

4.19.18 Non-OpenVMS Clients Overwrite Files on OpenVMS Servers

Problem:

Under certain conditions, non-OpenVMS clients would cause existing file on the OpenVMS server to be overwritten on filecopy (instead of creating new version).

Solution:

A new version is created; for scp only the -k option is available to force an overwrite.

4.19.19 SSH Client Does Not See Entries in TCPIP$ETC:IPNODES.DAT

Problem:

Entries made in the TCPIP$ETC:IPNODES.DAT file are not seen by the SSH client.

Solution:

Condition interfering with reading of the IPNODES.DAT file has been corrected.

4.19.20 Limited Support for ODS-5 File Format

Problem:

SSK file copy clients and servers have limited support for the ODS-5 file format.

Solution:

This problem has been corrected. Note that the following limitations apply to this fix:

• It addresses only problems with sftp ls/get/put and scp copy of files with extended filenames. ODS-5 syntax may work in other situations, but they are neither guaranteed nor supported.
• It is not intended to handle copying of files with extended file names to target directories on ODS-2 volumes. In that case an error of the following type results:

  tcpip$ssh_scp2.exe: warning: open: ./afile,name.txt (dst): unspecified failure (server msg: 'syserr: bad file number, file: ./afile,name.txt') %TCPIP-E-SSH_FC_ERR_FAIL, undetermined error from sshfilexfer

• When wildcards are used in file specification not all files with ODS-5 extended file name may be retrieved. For example: sftp>get *.*;* retrieves all files, while sftp get afil*.txt does not get fines with ODS-5 characters:

  sftp> get *.*;* afile2.txt;1 | 8B | 0.0 kB/s | TOC: 00:00:01 | 100% afile^%name.txt;2 | 1008B | 1.0 kB/s | TOC: 00:00:01 | 100% afile^,name.txt;1 | 6B | 0.0 kB/s | TOC: 00:00:01 | 100% afile^^^%name.txt;1 | 12B | 0.0 kB/s | TOC: 00:00:01 | 100% AFILE__NAME.TXT;1 | 20B | 0.0 kB/s | TOC: 00:00:01 | 100% sftp> get afil*.txt afile2.txt | 8B | 0.0 kB/s | TOC: 00:00:01 | 100% afile__name.txt | 20B | 0.0 kB/s | TOC: 00:00:01 | 100%

Problem:

SFTP2 image exits with status "normal" ever after errors are encountered.

Solution:

The following DCL exit codes are now supported for batch procedure exit. Of these, only TCPIP$_SSH_FC_ERR_TGT_EXISTS is a new code:

TCPIP$_SSH_FATAL "non-specific fatal error condition"
TCPIP$_SSH_FC_OK "operation was successful"
TCPIP$_SSH_FX_OK "the operation completed successfully"
TCPIP$_SSH_INFORMATIONAL "ssh informational"
TCPIP$_SSH_ERROR "non-specific error condition"
TCPIP$_SSH_FX_EOF "the operation failed because of trying to read at end of file"
TCPIP$_SSH_FX_NO_SUCH_FILE "the requested file does not exist"
TCPIP$_SSH_FX_PERM_DENIED "insufficient privileges to perform the operation"
TCPIP$_SSH_FX_FAILURE "the requested operation failed"
TCPIP$_SSH_FX_BAD_MESSAGE "a badly formatted message was received; error or incompatibility in the protocol implementation"
TCPIP$_SSH_FX_NO_CONNECTION "connection has not been established (yet)"
TCPIP$_SSH_FX_CONNECTION_LOST "connection to the server was lost, and the operation could not be performed"
TCPIP$_SSH_FX_OP_UNSUPPORTED "operation is unsupported by the fileserver"
TCPIP$_SSH_FX_INVAL_RFMT "record format not supported"
TCPIP$_SSH_FX_OUT_OF_MEMORY "out of dynamic memory"
TCPIP$_SSH_FC_ERROR "error in ssh file transfer operation"
TCPIP$_SSH_FC_ERR_DEST_NOT_DIR "destination is not directory or does not exist"
TCPIP$_SSH_FC_ERR_ELOOP "maximum symlink level exceeded"
TCPIP$_SSH_FC_ERR_CONN_FAILED "connecting to host failed"
TCPIP$_SSH_FC_ERR_CONN_LOST "connection broke for some reason"
TCPIP$_SSH_FC_ERR_NO_SUCH_FILE "file doesn't exist"
TCPIP$_SSH_FC_ERR_PERM_DENIED "no permission to access file"
TCPIP$_SSH_FC_ERR_FAILURE "error in ssh file transfer operation"
TCPIP$_SSH_FC_ERR_PROTO_MSMTCH "file transfer protocol mismatch"
TCPIP$_SSH_FC_ERR_INVAL_RFMT "file record format invalid for copy"
TCPIP$_SSH_FC_ERR_TGT_EXISTS "target file already exists"

If multiple errors are encountered, exit status reflects the last error. The following logical names are available to control behavior for the new functionality. To use these names define them to have a value "TRUE" (case insensitive) or any non-zero numeric value.

• TCPIP$SFTP_ALWAYS_EXIT_NORMAL : preserves old behavior of sftp exiting with status $STATUS "%X00000001" (normal), no matter what errors occurred during a session.
• TCPIP$SSH_SFTP_BATCH_ABORT_ON_ERROR : by default an sftp batch procedure continues after any errors except for failure of a cd (change directory) command. This behavior is the same as that for the base UNIX code. Setting this logical enables the OpenVMS-specific behavior of the procedure exiting after the first error is encountered.

4.19.22 SFTP Batch Procedure Files Need Special Format

SFTP batch files must be in sream_lf format, or have each line except the last terminated by a linefeed (ASCII 10). Solution:

This version detects if a batch file is not in stream_lf format, and if it is not, attempts to convert it to stream_lf format. The following message is displayed when the process begins, where batchfile is the filename of the sftp batch file):

Warning: Converting file fail4.cmd to Stream_LF.

The following message indicates succesful conversion:

Warning: File {batchfile} converted successfully to Stream_LF.

openvms_specific/OPENVMS_SPECIFIC.C:1885: Error calling
CONV$PASS_FILES for {batchfile}. STATUS = %NONAME-E-NOMSG,
Message number n