This section includes X11 port forwarding restrictions and problems.

• to use X11 forwarding in native mode, the system must be running DECwindows MOTIF Version 1.3 or higher. In addition, the X Authority utility (xauth) is required on the system. The X11 server uses this utility for authenticating host/user connections. For more information on how to use this utility, see the HP DECwindows Motif for OpenVMS documentation.
• To display a remote X11 client application on your X11 server, you must set the display variable on the X11 client to the address of the X11 server the client is connecting to. You can verify that the variable is set correctly by using the following DCL command:

  $ SHOW LOGICAL DECW$DISPLAY

  
  For WSA display devices, use the SHOW DISPLAY command to see the display variable value.
  To set the display variable on an OpenVMS client to point to your server, use the SET DISPLAY command as in the following example, where 16.20.176.33 is the server node address:

  $ SET DISPLAY/CREATE/NODE=16.20.176.33/TRANSPORT=TCPIP

  
  SSH on OpenVMS only supports local and TCP/IP transports. If you are using a local transport, you have to be at the system where the display is to appear, and that system must be running the X11 server. For local transport, use the following command to set the display:

  $ SET DISPLAY/CREATE/TRANSPORT=LOCAL

  
  On UNIX systems, use the following command to set the display variable to point to a server node with address 16.20.176.33 and using the TCP/IP transports:

  >setenv display 16.20.176.33:0.0

  
  To use local transport, use the following UNIX command:

  >setenv display :0.0

• To set up a standard port forwarding session on a remote OpenVMS system, HP recommends that you use remote port forwarding; local port forwarding will not work.

This section includes SSH restrictions pertaining to file transfer operations.

• On OpenVMS, setting the ForcePTTYAllocation keyword to "yes" in the SSH2_CONFIG. file can result in failures when performing file copy operations. (In other implementations of SSH, setting the keyword ForcePTTYAllocation to "yes" in the SSH2_CONFIG. file has the same effect as using the -t option to the SSH command.)
• Packet-related warnings may appear when using the SFTP and SCP commands on an OpenVMS SSH client to access an OpenSSH server, as in the following example:

  sftp> ls . .bash_logout .login Warning: packet length mismatch: expected 27, got 8; connection to non-standard server?

  
  After a pause, the following message is displayed:

  sftp> Warning: packet length mismatch: expected 23, got 8; connection to non-standard server?

  
  The operation on OpenVMS succeeds despite the warnings. You can ignore the warnings. To suppress the warnings, assign the logical name TCPIP$SSH_TOLERANT_PROTOCOL_STATUS systemwide, for example:

  $ DEFINE/SYSTEM TCPIP$SSH_TOLERANT_PROTOCOL_STATUS 1

  
  To retain this assignment through each reboot, add this command to the appropriate startup command procedure.

• File transfer is limited to OpenVMS files with the following record formats (as displayed by the DIRECTORY/FULL command):
  • STREAM_LF
  • Fixed-length 512-byte records
• Not all variants of UNIX path names are supported when referring to files on OpenVMS clients and servers.
• The SCP and SFTP commands from the following Windows clients have been tested and interoperate correctly with the OpenVMS SSH server:
  • PuTTY
  • SSH Communications
  
  Other versions and other clients may work, depending on protocol implementation and factors such as whether the client can handle OpenVMS-format file specifications.
• When using the SFTP command, pressing Ctrl/C does not display "Cancel" as expected. Also, Ctrl/T does not work as in DCL to display a status line; instead, it switches two adjacent characters, as on UNIX systems. Other problems with character handling have been fixed with this release, as reported in Section 4.14.
• The SFTP ls command pauses for an extended time after displaying a page of data and then continues with the next page.
• Using SCP or SFTP command to copy a file back to itself (either in local mode, or by connecting back to the client host) fails with the following error:

  %TCPIP-E-SSH_FC_ERR_INVA, file record format invalid for copy

• The SCP command issued from a client using SSH Version 1 will not work with the OpenVMS SSH server. The OpenVMS server does not support SSH Version 1.

This section includes restrictions pertaining to transferring large files:

• The minimum version of DECC$SHR running on your system must be that which was released with OpenVMS Version 8.2.
• You may need to adjust memory parameters (WSDEF, WSQUO, WSEXTENT, and PGFLQUO) to accommodate the memory requirements of the file copy client and server. The exact value depends on system resources and virtual memory configuration. For more information, see Section 2.5.
• Once a file transfer is started using the SCP or SFTP command, you cannot use Ctrl/Y or Ctrl/C to abort the transfer; the only way to stop it is to terminate the client or server process from another session.
  • Stopping an OpenVMS client process:
    On the client, the file transfer server subprocess name is of the format username_n, where username corresponds to the current user name, and n is an integer. When the process is stopped, the following message is displayed on the client:

    %TCPIP-E-SSH_FC_ERROR, undetermined error within sshfilecopy

    
    The following messages are displayed on the OpenVMS SSH server:

    log (TCPIP$SSH_GOME:TCPIP$SSH_RUN.LOG): Mon 28 13:09:15 INFORMATIONAL: Local disconnected: Connection closed. Mon 28 13:09:15 INFORMATIONAL: connection lost: 'Connection closed.'

  • Stopping an OpenVMS server process:
    If you use the OpenVMS DCL command SHOW SYSTEM when a file transfer is active, the command displays two processes relevant to the file transfer. One has a name in the format TCPIP$SSH_n, where n is an integer. The other has a name in the format TCPIP$prefix_BGn, where n is a BG device number, and prefix is S, SS, or SSH. You must stop the BG process; stopping the TCPIP$SSH_n process results in the client hanging.
    After the server is stopped, the following messages are displayed on the client:

    Disconnected; connection lost (Connection closed.) tcpip$ssh_scp2.exe: warning: child process (/sys$system/tcpip$ssh_ssh2) exited. %TCPIP-E-SSH_FC_ERROR, undetermined error within sshfilecopy

TCPDUMP works the same way on OpenVMS as it does on UNIX systems, with the following restrictions:

• On UNIX systems, tcpdump sets the NIC (network interface controller) into promiscuous mode and everything in the transmission is sent to tcpdump .
  On OpenVMS systems, TCPDUMP only sees the packets destined for and sent from the local host. Therefore, TCPDUMP works in copy-all mode. Because it only sees a copy of the packets that are processed by the TCP/IP kernel, TCPDUMP can only trace natively IP, IPv6, and ARP protocols on Ethernet.
  TCPDUMP can format or filter packets that have been traced from another platform running TCPDUMP in promiscuous mode. In this case it will process other protocols, like DECnet.
• Ethernet is the only supported type of NIC. Other types of NICS (such as ATM, FDDI, Token Ring, SLIP, and PPP) are not supported.
• The -i option is not supported. On UNIX systems, this option specifies the interface that tcpdump is attached to.
  On OpenVMS systems, TCPDUMP obtains packets from the TCP/IP kernel.
• The -p option is not supported. On UNIX systems, this option specifies that tcpdump stops working in promiscuous mode.
  On OpenVMS, TCPDUMP does not work in promiscuous mode. Therefore, this option is set by default.
• If you are using the Ethereal software to dump IPv6 network traffic, use the following command format to write the data in the correct format:

  $ TCPDUMP -s 1500 -w filename

• Only one process at a time can issue traces. This restriction applies to both TCPTRACE and TCPDUMP.

OpenVMS provides several ways to determine the name of a device on a channel assignment. Using the SYS$GETDVI/SYS$GETDVIW system services, the DVI$_DEVNAM, DVI$_FULLDEVNAM, and DVI$_UNIT items all return information about the device. While the first two items provide the full device name, the DVI$_UNIT item returns only the unit number of the device. To form the complete device name, a program must prefix the unit number (as a string) with the device name and controller information. In the case of the TCP/IP device name, the programmer could add the string BG or BGA . For example, BG + 1234 would produce the device name BG1234: .

The TCP/IP device name may be altered in a future release. It is good programming practice to use the DVI$_DEVNAM or DVI$_FULLDEVNAM items to obtain the full device-name string. Such programs are not based on the assumption that the TCP/IP device name is BGnnnn or BGAnnnn, and will not be affected by any future changes to the TCP/IP device name.

3.14 TCP/IP Management Command Restrictions

The following restrictions apply to the TCP/IP management commands:

• TCP/IP Services Version 5.4 introduced failSAFE IP, which obsoletes the IP cluster alias address. Consequently, the following TCP/IP management commands are no longer supported:
  • SET INTERFACE /NOCLUSTER
  • SHOW INTERFACE /CLUSTER
  
  To display interface addresses, including IP cluster alias addresses, use the following TCP/IP management command:

  TCPIP> ifconfig -a

  
  To delete a cluster alias address from the active system, use a command similar to the following:

  TCPIP> ifconfig ie0 -alias 10.10.10.1

  
  The following TCP/IP management commands continue to be supported:

  • SET INTERFACE/CLUSTER
  • SET CONFIGURATION INTERFACE /CLUSTER
  • SET CONFIGURATION INTERFACE /NOCLUSTER
  • SHOW CONFIGURATION INTERFACE /CLUSTER
• SET NAME_SERVICE /PATH
  This command requires the SYSNAM privilege. If you enter the command without the appropriate privilege at the process level, the command does not work and you are not notified. If you enter the command at the SYSTEM level, the command does not work and you receive an error message.
• SET SERVICE command
  When you modify parameters to a service, disable and reenable the service for the modifications to take effect.

For more information on TCP/IP Services management commands, refer to the HP TCP/IP Services for OpenVMS Management Command Reference guide.

This chapter describes the problems corrected in this version of TCP/IP Services.

4.1 Advanced Programming Environment Problems Fixed in This Release

The following sections describe programming-related problems fixed in this release.

4.1.1 Link Conflicts Occur When Linking to the TCPIP$LIB.OLB Library

Problem:

Link conflicts occur when a program that includes references to the strdup or putenv function is linked to the TCPIP$LIB.OLB library. The linker produces the %LINK-W-MULDEF warning message, indicating a conflict with functions of the same name in the C RTL library.

Solution:

In earlier versions of TCP/IP Services, the TCPIP$LIB.OLB library included functions that have since been defined in more recent versions of the OpenVMS C RTL library. These TCPIP$LIB.OLB routines, which have the DECC$ prefix, conflict with the routines of the same name in the recent versions of the C RTL library. With this release of TCP/IP Services, the TCPIP$LIB.OLB library has been modified to prevent such conflicts.

4.2 BIND Server Problems Fixed in This Release

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

4.2.1 BIND Slave Refusing Notify Requests

Problem:

A BIND server configured as a slave can refuse notify requests from a master server. The error message written to the TCPIP$BIND_RUN.LOG on the slave includes the text "refused notify from non-master." This problem occurs when the master server has been enabled for IPv6 communication by having the listen-on-v6 directive specified in the options statement in the TCPIP$BIND.CONF configuration file.

Solution:

This problem is corrected in this release.

4.2.2 The BIND Version 9 Server Process Exits With "Assertion Failure" Error

Problem:

The BIND server process exits with one of the following messages logged in the TCPIP$BIND_RUN.LOG file:

REQUIRE((((task) != 0L) && (((const isc__magic_t*)(task))->magic == ((('T')<< 24 | ('A') << 16 | ('S') << 8 | ('K')))))) failed Sun 19 03:00:13 CRITICAL: exiting (due to assertion failure) %SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF80A6C924, PS=0000001B REQUIRE(res->item_out == isc_boolean_true) failed Fri 19 13:12:04 CRITICAL: exiting (due to assertion failure) %SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF80E6C924, PS=0000001B

Solution:

This problem is corrected in this release.

4.3 failSAFE IP Problems Fixed in This Release

The following sections describe failSAFE IP problems fixed in this release.

4.3.1 failSAFE IP Phantom Failures

Problem:

Phantom failures can occur on systems where failSAFE IP is configured with a single interface address on multiple interfaces. When LAN traffic is infrequent, failSAFE IP can signal a false error.

Solution:

This problem is corrected in this release. failSAFE IP now generates MAC-level broadcast packets, by default. The new configuration parameter GENERATE_TRAFFIC can be set to force failSAFE IP to generate gratuitous ARP packets. You can include the following new configuration parameters in the TCPIP$FAILSAFE.CONF file:

GENERATE_TRAFFIC	Enables failSAFE IP to periodically generate either MAC-level broadcasts or gratuitous ARP packets. You can also configure failSAFE IP to turn off traffic generation. Default: mac (MAC-level broadcast) Other options: arp (gratuitous ARP packets) or off The following is an example line in the configuration file setting the parameter to generate gratuitous ARP packets: GENERATE_TRAFFIC: ARP
MAC_PTY	If MAC-level broadcast traffic is being generated, this parameter allows you to specify the MAC protocol type (a two-byte hexadecimal number, such as 6005). If MAC_PTY is not specified, the MAC broadcast tries each protocol type until an available one is found. The following is an example line in the configuration file setting the MAC protocol type as 6005: MAC_PTY: 6005

For more information about configuring failSAFE IP, see the HP TCP/IP Services for OpenVMS Management guide.

4.3.2 Users Cannot Change the Location for the failSAFE IP Log File

Problem:

failSAFE IP log files are always named:

SYS$SYSDEVICE:[TCPIP$FSAFE]TCPIP$FAILSAFE_node-name.LOG

Users cannot specify alternate locations on their systems.

Solution:

This problem is corrected in this release. The new configuration parameter LOGFILE allows users to specify a log file location other than the default.

LOGFILE

Specifies the file specification for the log file created by failSAFE IP. The default is SYS$SYSDEVICE:[TCPIP$FSAFE]TCPIP$FAILSAFE_ node-name.log. Specify the parameter and location as in the following example: LOGFILE: DEV1:[STATS]FAILSAFE.LOG

For more information about configuring failSAFE IP, see the HP TCP/IP Services for OpenVMS Management guide.

4.3.3 SHOW INTERFACE Command Does Not Display Pseudointerface Addresses

Problem:

After an interface fails or recovers an alias address, the TCP/IP management command SHOW INTERFACE does not display pseudointerface addresses.

Solution:

This problem is corrected in this release.

4.4 FTP Server Problems Fixed in This Release

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

4.4.1 FTP Does Not Allow IP Address Specification

Problem:

The FTP server does not allow you to specify an IP address other than that of the connected client, or the specification of a privileged port, in the PORT, LPRT, or EPRT commands. Any such commands are rejected with the following error:

500 Illegal {PORT|LPRT|EPRT} command.

The FTP server and client prevent data connection "theft" by a third party. For the FTP server, this applies to passive-mode connections from an IP address other than the client's, or from a privileged port. For the FTP client, this applies to active-mode connections from an IP address other than the server's, or from a port other than port 20.

Solution:

If this software change is not acceptable, you can restore the original behavior by defining the following logical names:

Server	Client
TCPIP$FTPD_ALLOW_ADDR_REDIRECT	TCPIP$FTP_ALLOW_ADDR_REDIRECT
TCPIP$FTPD_ALLOW_PORT_REDIRECT	TCPIP$FTP_ALLOW_PORT_REDIRECT

These logical names allow you to relax the IP address and port checks in the FTP server and the FTP client.

4.4.2 DCL DIRECTORY or UNIX ls Command Returns "Illegal Port Command" Error

Problem:

On an FTP client, if you use a password with an embedded space to log into an OpenVMS FTP server, the following error message is returned in response to the DCL command DIRECTORY or the UNIX command ls :

500 Illegal PORT command.

Solution:

This problem is corrected in this release.

4.5 FTP Client Problems Fixed in This Release

The following sections describe FTP client problems fixed in this release.

4.5.1 FTP Client Fails to Delete Interim Files after GET/MGET Commands

Problem:

After an FTP GET or MGET command entered with wildcard characters completes, the temporary TCPIP$FTP_TEMPnnnnnnnn.TMD files created by FTP are supposed to be deleted from the SYS$SCRATCH area. However, if no files match the wildcard criteria, FTP fails to delete any of the temporary files. (If at least one file matches the wildcard criteria, FTP successfully deletes any TCPIP$FTP_TEMPnnnnnnnn.TMD files created in SYS$SCRATCH.)

Solution:

This problem is corrected in this release.

4.6 IMAP Problems Fixed in This Release

The following sections describe IMAP problems fixed in this release.

4.6.1 Mail Message Lost after IMAP Move and Purge

Problem:

If you manually move a message out of a folder and then use IMAP to purge the source folder, the mail is lost.

This problem occurs when you:

1. Select a mail file using the IMAP client.
2. Read the message using OpenVMS Mail and move it to another folder.
3. Enter the Expunge command on the selected folder, using the IMAP client.

The message disappears from the destination folder. If the message was copied to a new folder, the folder ceases to exist.

Solution:

This problem is corrected in this release.

4.6.2 IMAP CLOSE Command Does Not Function Properly

Problem:

When a client logs out by issuing the IMAP CLOSE command, the IMAP server does not delete all the messages marked for deletion.

Solution:

This problem is corrected in this release. When you enter the CLOSE command, the IMAP server deletes all the messages marked for deletion.