The following sections describe IPv6 problems fixed in this release.

4.7.1 TCPIP$IP6_SETUP.COM Problems

This section describes TCPIP$IP6_SETUP.COM problems fixed in this release.

• Problem:
  The TCPIP$IP6_SETUP.COM command procedure for configuring IPv6 has the following problems:
  • Attempts to configure a 6to4 tunnel fail.
  • All routes required for 6to4 relay router are not configured.
  • The endpoints for automatic tunnels are not configured correctly.
  • IPv6 over IPv6 manual tunnels cannot be configured.
  • Errors are generated in the IPv6 configuration and initialization files during IPv6 host or router configuration.
  • Manual routes cannot be configured.
  
  Solution:
  The configuration command procedure now enables you to successfully configure 6to4 tunnels, all routes required for a 6to4 relay router, automatic tunnels, IPv6 over IPv6 manual tunnels, and manual routes. (For more information, refer to the HP TCP/IP Services for OpenVMS Installation and Configuration guide.)
• Problem:
  The TCPIP$IP6_SETUP.COM command procedure requires that TCP/IP Services be started in order to verify specified addresses.
  Solution:
  This problem is corrected in this release. TCP/IP Services no longer needs to be started in order to run TCPIP$IP6_SETUP.COM.

Problem:

When invoking an iptunnel create command that specifies IPv4 addresses for the tunnel source or end points, numerous DNS name resolution queries are sent to the name server even though resolution is not needed. These queries could result in a delay.

Solution:

This problem is corrected in this release.

4.8 NFS Server Problems Fixed in This Release

The following sections describe NFS server problems fixed in this release.

4.8.1 NFS Server Overwrites Files with Case-Sensitive Lookup

With OpenVMS Version 7.3-1 and higher the /CASE_LOOKUP=BLIND qualifier with the SET PROCESS command causes the case of file names to be ignored during lookups, while /CASE_LOOKUP=SENSITIVE causes the case of file names to be considered. However, if case sensitivity is not enabled on the NFS server, and the NFS client attempts to create both of those files, unexpected results can happen. For example the second file might overwrite the first.

With this release of TCP/IP Services, the TCP/IP management command ADD EXPORT has two new options: CASE_BLIND and CASE_SENSITIVE, which control UNIX-like case sensitivity for NFS server file lookups. For example, when case sensitivity is enabled, NFS preserves the case in the file names AaBBc.TXT and AABBC.TXT, regarding them as two different files.

In general, TCP/IP Services clients (not servers) determine whether lookups are case sensitive because they perform lookups in their local directory cache rather than on the server. However, when a file is being created, the server controls whether case sensitivity is in effect. Make sure that the case-sensitivity options for the server and client match; otherwise, unexpected results can occur.

For more information on the CASE_BLIND and CASE_SENSITIVE options, enter the following command:

$ TCPIP HELP ADD EXPORT

4.8.2 Directories Created by non-VMS Clients Do Not Inherit Version Limit

Problem:

Newly created directories should inherit the version limit attribute from their parent directory. When a directory is created at the request of an OpenVMS NFS client, the attribute is inherited as expected; however, directories created at the request of non-OpenVMS NFS clients do not inherit this attribute. This is a problem particularly for UNIX clients, because UNIX files only have one version, but the version limit of a new directory is set to zero (no limit).

Solution:

This problem is corrected in this release. Directories created for non-OpenVMS clients now inherit the parent directory's version limit attribute.

4.8.3 NFS Server and netstat Do Not Run Properly on Alpha Systems Not Running EV56 or Later Technologies

Problem:

On Alpha systems predating the EV56 processor, the NFS server and the netstat utility either experience excessive instruction time or do not run at all.

Solution:

This problem is corrected in this release.

4.8.4 MOUNT Server Problems Fixed in This Release

The following sections describe MOUNT server problems fixed in this release.

4.8.4.1 Improper Mount Point Verification

Problem:

The MOUNT service exhibits improper verification of mount points for exported file systems.

Solution:

This problem is corrected in this release.

4.8.4.2 Cannot Mount ODS-5 File System

Problem:

When the TYPELESS_DIRECTORIES option is specified in the ADD EXPORT command, you cannot mount an ODS-5 file system even though the export entry contains a directory specification that does not end in .dir.

Solution:

This problem is corrected in this release.

4.8.4.3 Host Name Verification Occurs During Mount and Causes Failure

Problem:

When a client attempts to mount a file system, host name verification is performed even if the mountd_option_* nfs subsystem attributes were not set. An error or event message on the client may indicate permission denied. The MOUNT server may produce an OPCOM message indicating that the client host name and IP address are not consistent with the hosts database (TCPIP$HOST) or with DNS/BIND information.

Solution:

This problem is corrected in this release.

4.8.4.4 Misleading Mount Server Error

Problem:

The MOUNT server reports a misleading error message when the mount port is already in use.

If the mount port (port 10) is already in use, the mount server reports the following error:

ERROR: bind: address already in use

This can be mistaken for a BIND/DNS issue when in fact it is the C RTL call bind() that is failing.

Solution:

This problem has been corrected in this release. The message has been changed to:

ERROR: bind: mount server port(10) already in use

4.9 NTP Problems Fixed in This Release

The following sections describe NTP problems fixed in this release.

4.9.1 On High-Performance Alpha Systems NTP Fails to Adjust System Clock

Problem:

When running on certain high-performance Alpha systems, NTP may be unable to adjust the system clock; therefore, NTP will not be able to provide accurate timekeeping. When this happens, the following error message appears in the NTP log file:

%SYSTEM-F-BADLOGIC, internal logic error detected VMS timekeeping is not working as expected - can't proceed

Solution:

This problem is corrected in this release.

4.9.2 NTP Creates Lowercase File Names on ODS-5 Disks

Problem:

In previous releases of TCP/IP Services, when the NTP server creates files on ODS-5 disks, it gives them lowercase file names. This causes a file-naming inconsistency with non-ODS-5 disks, which assign uppercase names to files.

Solution:

This problem is corrected in this release. All files are created using uppercase file names.

4.10 RCP Problems Fixed in This Release

The following section describes RCP problems fixed in this release.

4.10.1 RCP File Copy Operation Involving Multiple Files or Directories Fails

Problem:

• Attempts to copy files recursively abort prematurely for no apparent reason, or they fail with a read or write error.
• Attempts to copy files might fail with the following error message:

  %CONV-F-OPENOUT, error opening !AS as output

  
  This occurs when using the /RECURSIVE qualifier or wildcards to copy files located in a directory hierarchy that is greater than eight levels deep.

Solution:

These problems are corrected in this release. RCP now supports copy operations involving directory structures greater than eight levels deep. Directory specifications up to 255 levels are now supported.

4.10.2 OpenVMS-to-OpenVMS File Copy Operations Do Not Preserve File Attributes

Problem:

RCP copy operations between OpenVMS systems do not preserve the file attributes (file organization and structure). Files are automatically converted to STREAM_LF format.

Solution:

With this release, RCP allows users to specify the /VMS qualifier to preserve file attributes (UNIX format: use the -v option).

Problem:

Attempts to copy files that are greater than 2 gigabytes in size fail.

Solution:

With this release, RCP can copy files larger than 2 GBs. The file size is limited to 4 gigabytes.

4.11 SMTP Problems Fixed in This Release

The following sections describe SMTP problems fixed in this release.

4.11.1 SMTP Receiver Does Not Check Recipient Deliverability

Problem:

The SMTP receiver does not check to see if the recipient email address in the RCPT TO SMTP protocol command is deliverable (for example, that the user account exists on the system). This check is instead deferred to the processing of the mail message in the SMTP queue by the SMTP symbiont process. By this time, the host has taken responsibility for the message and, if there is a problem delivering the message, must bounce the message itself.

This behavior is more problematic when the system receives SPAM. SPAM arrives on the host for a non-existent user and is bounced by the host's symbiont process to the email address in the SPAM's Return-Path: header. The SPAM's Return-Path: header contains an invalid email address, so the bounced SPAM is in turn bounced back to the host's POSTMASTER account. The POSTMASTER account's mail is forwarded to the SYSTEM account, which means that the SYSTEM user must constantly separate these doubly-bounced SPAMs from their valid email.

Solution:

The SMTP receiver has been changed to check to see if the recipient email address in the RCPT TO SMTP protocol command is deliverable. This solves the problem by not letting the SPAM for the unknown user onto the host in the first place.

The Symbiont-Checks-Deliverability configuration option allows you to turn this feature on and off. Enter this configuration option in the SMTP configuration file (SMTP.CONFIG).

When this option is set to TRUE, the symbiont checks deliverability of RCPT TO recipients. Setting Symbiont-Checks-Deliverability to FALSE (the default) tells the receiver to check the deliverability

4.11.2 SMTP Accepts Mail from Senders Who Should Be Blocked

Problem:

SMTP might accept mail from senders who should be blocked. These are senders listed in the anti-SPAM Reject-Mail-From field of the SMTP.CONFIG file. SMTP fails to block such mail when the entries in the Reject-Mail-From field exceed the 500-character limit for SMTP.CONFIG fields.

Solution:

This problem is corrected in this release. HP has increased the character limit for fields in the SMTP.CONFIG file from 500 to 10,000.

4.11.3 Two Messages Acquire Same Value in Message-ID Header

Problem:

Any two messages composed in the same one-hundredth of a second will acquire the same value in their Message-ID header. This can cause some mail systems to delete the second of the two messages as a duplicate. Message-IDs should be unique.

Solution:

This problem is corrected in this release. Any two messages created in the same one-hundredth of a second will acquire unique values in their Message-ID headers.

4.11.4 Potential Problems Caused by Multiple Addresses in SMTP To: or Cc: Header

Problem:

Multiple addresses in the To: SMTP mail header that is composed in OpenVMS mail are not separated into multiple lines of text but instead appear on one line. For recipients of such messages on OpenVMS, if the length of this To: line exceeds the OpenVMS mail line length limit of 255 characters, the SMTP symbiont breaks the line into multiple lines when delivering the message, but the lines after the first one are not indented (tabbed in). As a result, the lines will appear as malformed headers. This can cause incorrect behavior with some automated programs that read e-mail. The same problem exists for Cc: lines longer than the OpenVMS mail limit.

Solution:

This problem is corrected in this release. When a user composes a mail message, the SMTP software that builds the SMTP To: and Cc: headers ensures that a To: or Cc: header line does not exceed 75 characters. If adding the next recipient address to a header line would cause the line to exceed 75 characters, the SMTP software inserts a line feed and tab into the headers before adding that recipient address.

4.12 SNMP Problems Fixed in This Release

The following sections describe SNMP problems fixed in this release.

4.12.1 TCPIP$CONFIG.COM Refuses SNMP Community Names Containing Special Characters

Problem:

With Versions 5.1 and 5.3 of TCP/IP Services, TCPIP$CONFIG.COM checks for special characters, and disallows community names containing any special character.

Solution:

This release relaxes these restrictions. However, TCPIP$CONFIG.COM does not accept a space in an SNMP community name. In addition, a quotation mark (") specified as part of a community name might not be handled correctly by TCPIP$CONFIG.COM. A message warns the user to check the validity of the name with the SHOW CONFIGURATION SNMP command, and, if necessary, to correct the name with the SET CONFIGURATION SNMP command.

4.13 Sockets API Problems Fixed in This Release

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

4.13.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.14 SSH Problems Fixed in This Release

The following sections describe SSH problems fixed in this release.

4.14.1 SSH Server Does Not Allow Password Change

Problem:

The SSH server does not support password change requests for non-VMS clients when account passwords have expired.

Solution:

If the SSH configuration option AllowNonvmsLoginWith ExpiredPwd is set to "yes" and the password has expired, the server sends a request to the client to prompt the user for a new password. The user must change the password, or the account will be locked out, and the next attempt to log in will fail.

However, if the OpenVMS account has the DisForce_Pwd_Change flag set in the SYSUAF, the server allows the user to log in, displaying the following message:

WARNING - Your password has expired; update immediately with SET PASSWORD!

The DisForce_Pwd_Change flag must be applied to each OpenVMS account individually.

The default setting for the AllowNonvmsLoginWith ExpiredPwd option has been changed to "yes." If the AllowNonvmsLoginWithExpiredPwd option is set to "no," the server does not allow password authentication for non-OpenVMS clients when the password has expired. The user does not have the option to change the password. For more information, refer to Section 5.2.

4.14.2 Language Tag Support

Problem:

The password change request that is sent to the SSH client can include a language tag. Some clients do not support the language tag.

Solution:

You can control this feature using the DisableLanguageTag configuration option in the SSH server configuration file (SSHD2.CONFIG). By default, OpenVMS password change requests include the language tag. If the client that does not expect the language tab receives it, the client will issue an error message. You can disable sending the language tag by setting the DisableLanguageTag option to "yes" in the SSH server configuration file. This prevents the language tag from being included in any password change request.

4.14.3 Accepting Two Passwords

Problem:

The OpenVMS SSH server does not support a secondary password for password authentication.

Solution:

The SSH server detects when a user has a second password. In this case, OpenVMS prompts for the second password. If one password has expired, the user is prompted to change the password. If both passwords have expired, the user is prompted to change the first one, and then is prompted to change the second one.

In order for the SSH client to accept the OpenVMS prompt for the second password, one or both of the following configuration options must be set to 2:

• In the client configuration file (SSH2_CONFIG): NumberOfPasswordPrompts
• In the server configuration file (SSHD2_CONFIG): PasswordGuesses

Both configuration files may be stored in TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]. In addition, the user can have a client configuration file in the user-specific SSH directory ([username.SSH2]).

The second password prompt is enabled by forcing an error situation on OpenVMS for the first password; this is handled by the OpenVMS software internally. However, the message displayed after entering the first password depends on the client software. No intrusion record is created if authentication is enabled. However, if either password is entered incorrectly, an intrusion record is created.

Some clients accept the second password request even if both passwords have expired. However, some clients do not accept the second password request; these clients function correctly when only one of the passwords has expired.

4.14.4 Native-Mode X11 Port Forwarding Does Not Work

Problem:

SSH for OpenVMS does not support the native-mode SSH mechanism for implementing X11 port forwarding (using the -x or +x SSH command options, or the ForwardX11 keyword in the client configuration file and the AllowX11Forwarding keyword in the server configuration file). SSH only supports standard port forwarding, requiring special setup actions to enable the X11 functionality.

Solution:

This problem is corrected in this release. For more information, see Table 5-2.

4.14.5 SFTP Double Echo and Key-Handling Problems

Problem:

Before using SFTP to connect to a remote system, characters typed at the SFTP prompt (SFTP>) are double echoed. In addition, when connected to the remote system, the left and right arrow keys do not work as expected, as well as the Ctrl/X, Ctrl/W, and Ctrl/C sequences (to erase line, refresh line, and exit, respectively).

Solution:

These problems are corrected in this release. However, pressing Ctrl/C does not display "Cancel" as expected.

4.14.6 SSH, SFTP, and SCP Commands Fail or Do Not Work Properly in Batch Mode

Problem:

The SSH, SCP, and SFTP commands fail or work improperly in batch mode.

Solution:

This problem is corrected in this release.

For restrictions pertaining to batch mode, see Section 3.11.10.

4.14.7 RSA Key Types Not Accepted

Problem:

In prior versions of SSH for OpenVMS, RSA keys are accepted for client authentication to the server, but not accepted for server authentication to the client.

Solution:

Starting with this release of TCP/IP Services, both RSA and DSA key types are accepted for client authentication to the server as well as server authentication to the client.

4.15 SSL Problems Fixed in This Release

The following sections describe SSL problems fixed in this release.

4.15.1 After Installing SSL, POP SSL Ceases to Function

Problem:

After installing the SSL V1.2 kit on TCP/IP Services, POP SSL support ceases to function. The POP server will not listen on its SSL port and, consequently, will not service clients coming in through SSL. The TCPIP$POP_RUN.LOG POP server log file contains these lines:

POP server will not listen for SSL connections. SSL$LIBCRYPTO_SHR32_INIT status: %LIB-E-KEYNOTFOU, key not found in tree

Solution:

This problem is corrected in this release.