|
|
 |
HP Services Software Patches - ucxeco7-032
|
*DEC TCP/IP] UCXECO7-032 TCP/IP V3.2 for OPENVMS VAX/Alpha ECO Summary"-
Copyright (c) Digital Equipment Corporation 1995. All rights reserved.
PRODUCT: DEC TCP/IP Services V3.2 for OpenVMS VAX
DEC TCP/IP Services V3.2 for OpenVMS Alpha
OP/SYS: OpenVMS VAX
OpenVMS Alpha
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: UCXECO7-032
ECO Kits Superseded by This ECO Kit: None
ECO Kit Approximate Size: 36,995 Blocks
Kit Applies To: OpenVMS VAX V5.5 and higher
OpenVMS Alpha V1.5, V6.1
System Reboot Necessary: Yes
ECO KIT SUMMARY:
An ECO kit exists for DEC TCP/IP Services V3.2 on OpenVMS VAX V5.5
and higher and OpenVMS Alpha V1.5 through V6.1. This kit addresses
the following problems.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 Kernel images
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 29-NOV-1994 AXP and VAX
Images:
UCX$BGDRIVER.EXE UCX V3.2-9A (Alpha)
UCX$INTERNET_SERVICES.EXE UCX V3.2-9A
UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9A
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9A
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9A
Problems:
1. System crash in routine INET_SOACCEPT upon referring to the
socket structure pointed at by the Listener UCB.
2. System crash due to corrupted pool when issuing the
UCX SHOW COMM/MEM command.
Solution:
1. By the time that INET_SOACCEPT is called the socket that
belonged to the Listener UCB may already be deassigned.
In that case the UCB$L_BG_SOCKET field in the Listener
UCB will be zero and a reference to the structure will
cause a crash. We add code to look for this possibility
and avoid the access violation if the field has been
zeroed.
2. In routine INET_SENSE_MBUF_COUNTERS in INET_SENSEMODE.MAR,
some byte arithmetic was incorrect when the byte value
was greater than 128 decimal (i.e. 80 hex). The 80 hex is
a negative integer and as a result we calculated the size
of an allocated pool buffer incorrectly then proceeded to
use more space than we had allocated.
ECO B 4-JAN-1995 AXP and VAX
Images:
UCX$BGDRIVER.EXE UCX V3.2-9B (Alpha)
UCX$INTERNET_SERVICES.EXE UCX V3.2-9B
UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9B
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9B
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9B
Problem:
When two processes (such as a parent and a child) share a
socket, only the actual creator is allowed to perform
IO$_DEACCESS QIOs.
Solution:
Check if the socket is shareable, the issuing process has
the SHARE privilege, or the issuer's parent process owns
the device. Only deny access if all four checks fail.
Also, when access is disallowed, return SS$_NOPRIV rather
than SS$_ACCVIO.
ECO 2 Updates:
--------------
ECO C 9-JAN-1995 AXP
Images:
UCX$BGDRIVER.EXE UCX V3.2-9C (Alpha)
Problem:
Use of the #pragma member_alignment preprocessor option
on Alpha has led in one instance to a misalignment of
data structures between the C code and Macro code. The
data structure in question is the inpcb structure.
Although it is not certain what all the ramifications of
this problem are, this problem has probably contributed to
several unexplained Alpha crashes, especially those
involved with dynamic routing.
Solution:
An explicit word filler was introduced into the $INPCBDEF in
INET_NPGD.SDL and the INET_SETMODE.MAR module was
recompiled after the libraries were rebuilt. This should
resync the data structures. However, it should be noted
that the source for INET_NPGD.SDL is now in the
[...SRC_PAT.NET] tree for V3.1 and the a build for
...SRCLIB SRCLIB... was done for only the two Alpha
streams. That means that for the VAX side we should avoid
doing a library rebuild during the rest of the life of
V3.1 and its ECOs.
Note: This is the same action as was done in ECO R of V3.1.
ECO D 12-JAN-1995 AXP and VAX
Images:
UCX$BGDRIVER.EXE UCX V3.2-9D (Alpha)
UCX$INTERNET_SERVICES.EXE UCX V3.2-9D
UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9D
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9D
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9D
UCX$INETACP.EXE UCX V3.2-9D
Problem:
1. System crash occurs in routine INET_IPINTR+1F3 upon
referring to the supposed IF_UCB structure pointed at by
R8. However R8 contains zero.
2. System crash occurs in the UCX$INET_ROUTED process or
while running in UCP during execution of a SHOW INTERFACE
command.
3. System crash occurs in INETACP at
INETACP_SERV_ACCEPT+1B1 in INETACP_CREPROC.MAR.
4. System hangs for between 10 and 15 minutes when FTP is
aborted from a remote Macintosh.
Solution:
1. At this point in the code, R8 is pointing at the
IF_UCB of the interface over which the current MBUF is
received. Since the loopback interface does not have an
IF_UCB structure, if the current MBUF had been received
over the loopback interface, then we have a crash. For
now, we will simply prevent the crash by dropping the
packet on the floor if R8 is zero.
2. If the local interface, LO0, is deleted through a SET
NOINTER LO command, the BGDRIVER database is left in an
inconsistent state. The solution is to disallow the
deletion of this interface at the driver level. In the
subroutine INETACP_DELETE_ETHERNET, in the
INETACP_ETHERNET.MAR module, we test if the interface to
be deleted is that of LO0, and if it is, we terminate the
request.
3. In trying to accept a connection we fail because we
have surpassed the maximum number of sockets. In
cleaning up we crash after referring to a field,
REQCB$L_UCB_2 that has not been initialized in this path.
The solution is to initialize this field and also
REQCB$W_CHAN_2 when the REQCB is created, in the
INET_ACCESS routine, INET_REMOTE_ACCEPT.
4. In the INET_RCV_XMT.MAR module, in subroutine
INET_ENQ_IO, if R1 was to contain a negative number in
it, the result would be a long, long, loop, encompassing
billions of passes, at elevated IPL. To eliminate this
possibility, we introduce a sanity check into the loop.
ECO 4 Updates:
--------------
ECO E 24-JAN-1995 AXP and VAX
Images:
UCX$BGDRIVER.EXE UCX V3.2-9E (Alpha)
UCX$INTERNET_SERVICES.EXE UCX V3.2-9E
UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9E
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9E
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9E
UCX$INETACP.EXE UCX V3.2-9E
Problem:
1. System crashes in the INET_FREE_MBUF_CHAIN when
calling @VCRP$A_DEALLOC_RTN and trying to deallocate a
VCRP.
Solutions:
1. In the IP_INPUT_VMS.C module, explicitly declared
several instances of invocations of the "sizeof"
function used in comparisons to be of the type (int) to
force the generated code to use signed comparison
instructions. The problem caused to incorrectly clobber
packets with bogus options.
Note:
The crash was caused by something clearing the
VCRP$A_DEALLOC_RTN field and that we never demonstrated
how the evident error, which did cause us to mangle a
received datagram, actually caused the crash. However,
given that the error did cause clobbering of data, it is
not to much to accept that it also led to the crash.
ECO F 17-FEB-1995 AXP and VAX
Images:
UCX$BGDRIVER_SEC.EXE UCX V3.2-9F (Alpha)
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9F
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9F
Problem:
Security Driver interface is broken. When calling
@ip_secvec$l_ip_input the R8 is supposed to be pointing to
the IF structure, not the IF_UCB structure.
Solutions:
Fix code to put correct value in the R8.
ECO G 21-FEB-1995 AXP and VAX
Images:
UCX$BGDRIVER_SEC.EXE UCX V3.2-9G (Alpha)
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9G
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9G
UCX$INETACP.EXE UCX V3.2-9G
Problem:
1. Due to a change in behavior for OpenVMS AXP T6.2-FT2,
we need to specify the LOGINOUT.EXE image, rather than
the DCL.EXE image, when starting a new server process.
2. Due to a typo, one code path in the ECO F fix for the
Security Driver did not properly setup the R8.
Solution:
1. Have the Auxiliary Server use the LOGINOUT.EXE image.
2. Fix typo.
ECO 5 Updates:
--------------
ECO H 21-MAR-1995 VAX / AXP
Images:
UCX$BGDRIVER_SEC.EXE UCX V3.2-9H (Alpha)
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9H
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9H
UCX$INETACP.EXE UCX V3.2-9H
Problem:
When using SELECT on a multi-processor, with null lists,
SELECT fails with a strange error code in the IOSB.
The routine INET_SELECT_BUILD_LIST, when called with null
lists was not setting a status code into R0. As a
result, the previous contents of R0 were retained. On
single CPU systems, this previous value was SS$_NORMAL,
however on multi-processor systems this value was a
system address in the data structure associated with
IOLOCK_8.
Solution:
On entry to INET_SELECT_BUILD_LIST initialize R0 to SS$_NORMAL.
ECO 6 Updates:
--------------
ECO I 3-APR-1995 VAX / AXP
Images:
UCX$BGDRIVER_SEC.EXE UCX V3.2-9I (Alpha)
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9I
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9I
UCX$INETACP.EXE UCX V3.2-9I
Problem:
System crash at INET_SEL_READ_ALL+14 due to the fact that
the temporary space allocated for a SELECT has been
deallocated.
In the preprocessing of a SELECT operation we test to see
if the UCB that serves as the head of the SELECT list
is already active. If so, we return an SS$_DEVACTIVE
status and terminate the call. Unfortunately we also
were deallocating the temporary space associated with
the first SELECT call. When an event occurred we
then crashed due to the absence of the temporary list.
Solution:
In a failure in preprocessing for SELECT, avoid
deallocating the temporary space if the space was NOT
allocated explicitly during this call.
ECO 7 Updates:
--------------
ECO J 10-MAY-1995 VAX and AXP
Images:
UCX$BGDRIVER.EXE UCX V3.2-9J (Alpha)
UCX$INTERNET_SERVICES.EXE UCX V3.2-9J
UCX$INTERNET_SERVICES_V6.EXE UCX V3.2-9J
UCX$INTERNET_SERVICES_SEC.EXE UCX V3.2-9J
UCX$INTERNET_SERVICES_SEC_V6.EXE UCX V3.2-9J
UCX$INETACP.EXE UCX V3.2-9J
Problem:
1. Crash in SBDROP which calls PANIC due to what appears to be
an inconsistent receive socket buffer.
2. Crash in PWIP, in adjTCPwindow, with an access violation due
to referencing a stale UCB.
Solution:
Both the above crashes may be triggered when the PWIP application
chooses to close a connection before it has deallocated all
the MBUFs that have been passed to it. The solution to both
of these problems can be achieved by redesigning the mechanism
used to handle deferred TCP window adjustment for PWIP.
Formerly, we used two UCB fields, UCB$L_BG_So_cc and
UCB$L_BG_So_mbcnt, to keep track of the SO_CC and SO_MBCNT
values associated with MBUFS passed up to Pathworks or DECnet/OSI.
The redesigned mechanism makes use of a new structure, the DWAB
(Deferred Window Adjustment Block), to keep track of these
quantities.
This redesign goes hand in hand with PWIP changes to
PWIPDRIVER_READ.C and PWIP_DRIVER_SUPP.C. It is
imperative to install both changes, (i.e. NET and PWIP),
simultaneously.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$INETDRIVER.EXE
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 06-JAN-1995 VAX
Images:
UCX$INETDRIVER.EXE
Problem:
CPU crash with KNRLSTAKNV error code. Crash is due to
the occurrence of an IPL 3 (RESCHED) interrupt while
the SP is at or near a page boundary and the
page at the next lower address range has never been
modified (i.e. the M bit is clear in the PTE). The
problem arises from the inability of some CPUs to
handle an M bit trap while pushing the PC/PSL onto
the kernel stack.
Solution:
"Pre-modify" the pages of the newly allocated kernel stack.
ECO 7 Updates:
--------------
ECO B 28-APR-1995
Images:
UCX$INETDRIVER.EXE UCX V3.2-9B
Problem:
PGFIPLHI bugcheck in IOC$VERIFYCHAN called from
INET_CANCEL.
Solution:
Release forklock before calling IOC$VERIFYCHAN.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$TNDRIVER.EXE
---------------------------------------------------------------------------
ECO 3 Updates:
--------------
ECO B 26-JAN-1995
Images:
UCX$TNDRIVER.EXE UCX V3.2-9B
Problem:
System crash with CPUSPINWAIT due to corrupted TIMER queue.
Solution:
Synchronize use of UCB based TQE between TN$CANCEL_TIMER
and the various timer routines that are invoked. We add
a field, UCB$L_TN_TIMER_FLAG, which is normally set to zero.
In TN$CANCEL_TIMER, if the call to EXE$RMVTIMQ does NOT
remove the TQE (because it has already been REMQUEd by
the system and its thread is presumably looping, waiting to
acquire the spinlock) we set UCB$L_TN_TIMER_FLAG to -1.
Then in the three timer routines, TN$DISCONN_TIMEOUT,
TN$FREE_UCB_TIMER, and TN$LOGIN_TIMER, we test the flag
and if it is negative, we clear it and then simply
dismiss the call, since it was the intention of the caller
of the TN$CANCEL_TIMER to cancel the timer in the first place.
ECO D 8-FEB-1995
Images:
UCX$TNDRIVER.EXE UCX V3.2-9D
Symptom:
When the UCX TELNET server received both a DO ECHO and a WILL
ECHO from the remote host, only the first would get a response.
Solution:
Set the remote echo flag, rather than the local echo flag, when
a WILL ECHO message is received.
ECO 5 Updates:
--------------
ECO E 3-MAR-1995 AXP AND VAX
Images:
UCX$TNDRIVER.EXE UCX V3.2-9E
Symptom:
System crashes with INVEXCEPTN due to sub-negotiation buffer
overrun when receiving data from XYPLEX Terminal Server.
Solution:
Initialization of the sub-negotiation buffer incorrectly
calculated the end of the buffer. When an illegal
sequence of many, many hundreds of bytes of data arrived
the buffer overran and clobbered a pointer that led to a
crash. The solution is to correctly limit the size of
the sub-negotiation buffer.
ECO 6 Updates:
--------------
ECO F 4-MAR-1995 AXP AND VAX
Images:
UCX$TNDRIVER.EXE UCX V3.2-9F
Symptom:
System crash with DOUBLDEALO due to TNDRIVER UCB overrun
into following ORB.
Solution:
The UCB$T_TEL_REM_HOST_PORT field is filled in by a MOVC3
instruction whose length operand is picked up from the
associated BG UCB without verification. New code has
been added to verify that the length is no bigger than
the size of the field and to limit to the MOVC3 to this
upper bound.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$TELNET.EXE
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 09-NOV-1994 AXP AND VAX
Images:
UCX$TELNET.EXE V3.2 - 9A
Problem:
The PRINT-SCREEN function on AXP returns "file not found".
Solution:
In [TELNET]RMSFILEIO.BLI, code a new macro
ACTUALPOSITION() to replace the existing macro
ACTUALNUMBER(), which does not function properly due to a
compiler problem. Instead of attempting to create the file,
it always attempts to append to it.
Problem:
If the server requests a print screen on VAX, a loop with the error
message "file not found" is entered.
Solution:
In [TELNET]STESCREEN.B32, clear the PRINTING flag to prevent the
STE from continuously attempting to print on an error. The error
handler unwinds and continues with the flag left clear to prevent
the same error from occurring over and over again.
ECO 6 Updates:
--------------
ECO C 2-FEB-1995
Images:
UCX$TELNET UCX V3.2-9C
Symptoms:
Un-privileged user gets operator authorized in subprocess
(SPAWN command).
Solution:
Modify spawn routine to take away the operator privilege if
not authorized.
ECO G 06-APR-1995 AXP/VAX
Images:
UCX$TELNET.EXE V3.2-09G
Problem:
When using IBM-3278-4 model terminals, TN3270 signals the message
"network resource not available".
Solution:
In [TELNET]TELNET$CLIENT_NET.C, remove the IO$M_NOWAIT modifier
to the write $QIO. This allows TELNET to wait for the
transmission of the data instead of returning to command mode
with a resource problem.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 BIND Server
---------------------------------------------------------------------------
ECO 7 Updates:
--------------
ECO B 16-MAY-1995
Images:
UCX$NSLOOKUP.EXE UCX V3.2-9B
Problem:
"mcr ucx$nslookup" with wrong bind-server name in command line
gave an accvio.
With wrong server-name passed, an error loop was invoked which
apparently invoked "perror" call with a null string. VAXC could
not handle "perror" when a null string was passed as an argument.
Solution:
Replaced with an error message.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 BIND resolver
---------------------------------------------------------------------------
ECO 7 Updates:
--------------
ECO B 03-APR-1995 AXP/VAX
Images:
UCX$ACCESS_SHR.EXE UCX V3.2-9B
Problem:
When the BIND resolver receives a response from a nameserver
indicating that datagram truncation has occurred, then fails
to establish a stream (TCP) connection, and finally tries
the next server in the list, the resolver uses an excessive
timeout in waiting for a response from this second server.
If this occurs when the UCX$INETACP process is calling the
resolver, the result can be an apparent UCX-wide hang.
Solution:
In RES_SEND.C, perform bounds checking on the timeout calculation.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$BOOTP.EXE
---------------------------------------------------------------------------
ECO 2 Updates:
--------------
ECO A 16-JAN-1994 AXP/VAX
Images:
UCX$BOOTP.EXE V3.2-09A
Problem:
BOOTP server is not providing the optional vendor data
for boot file size - i.e. tag type 13 in RFC1497
Confusing code, expecting to find file size in bootp
database, when in fact the server looks up the file size
directly.
Solution:
Remove the check for file size in the BOOTP database
record and just use the size, if any, from the
GetFileSize() routine.
Problem:
BOOTP server is not providing the optional vendor
data for Gateways - i.e. tag type 3 in RFC1497
Transposed arguments in a memcpy() call.
Solution:
Fix typo. This is a day-one problem - indicates some
need for more thorough testing (even though this
data is optional, it should work).
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$FTP.EXE.
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 5-DEC-1994 AXP and VAX
Images:
UCX$FTP.EXE UCX V3.2-9A
Problem:
GET strips device and directory from local filespec.
Solution:
Comment out this code.
ECO B 7-DEC-1994 VAX/AXP
Images:
UCX$FTP.EXE UCX V3.2-9B
Problem:
User gets number of bytes transferred even if none were
due to error.
Solution:
Fix send_data and recv_data to eliminate this.
ECO 2 Updates:
--------------
ECO C 27-DEC-1994 VAX/AXP
Images:
UCX$FTP.EXE UCX V3.2-9C
Problem:
Tape needs 14 bytes minimum on sys$write.
Solution:
Fix recv_bin and recv_normal_bin to pad to 14.
ECO 7 Updates:
--------------
ECO D 11-APR-1994 VAX/AXP
Images:
UCX$FTP.EXE UCX V3.2-9D
Problem:
Disable port did not work.
Solution:
Fixed initconn to use correct port if PORT command disabled
and to add REUSEADDR on control port because it may be used
as a dataport.
Also changed a test of sendport == -1 to sendport == 1.
Sendport cannot be -1.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 UCX$FTPC.EXE and UCX$FTPD.EXE
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 17-NOV-1994 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9A
Problem:
Using node:: syntax produces errors on get and put.
Solution:
Do not try checking file access or checking whether the
file is a directory or not over the net.
Notes:
1. This means that one can copy a file that is a
directory, but it will be garbage on the target end.
2. The error, if the access is denied, is not a privilege
error: it is 'Failed to open file'.
ECO B 30-NOV-1994 AXP/VAX
Images:
UCX$FTPC.EXE UCX V3.2-9B
Problem:
Fixed various file parsing errors in rnfr and retr to
correctly handle multi-directory linked logicals.
Solution:
Fixed an error in check_filetype that was leaving
assigned channels.
ECO C 2-DEC-1994 AXP/VAX
Images:
UCX$FTPC.EXE UCX V3.2-9C
Problem:
When an even number of subdirectories is involved in
checkdir_access the user gets a 'privilege' error.
Solution:
Fix btest of NAM$V_DIR_LVLS to check all 3 bits.
ECO 2 Updates:
--------------
ECO D 21-DEC-1994 AXP/VAX
Images:
UCX$FTPC.EXE UCX V3.2-9D
Problem:
Cannot write to tape at all.
Solution:
Fixed recv_vms_plus_bin, recv_normal_bin to handle tape
requests by making it not check access if tape device
specified.
Problem:
RMS-write error writing to tape
Solution:
Fixed appe_vms_plus_bin, appe_normal_bin,
recv_normal_bin and recv_vms_plus_bin to make all
tape writes >= 14 bytes.
Changed l_print call to dev_cls.
Fixed code to write at least 14 bytes to tape (tape driver
restriction).
Problem:
DIR with node:: does not work:
gives "NO privilege" and outputs incorrect string
Solution:
Do not perform a checkfl_access (in list).
Pass correct buffer to prntdirinf.
ECO E 11-JAN-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9E
Problem:
Cannot put to a searchlist logical.
Solution:
Fixed stor() problem.
ECO 4 Updates:
--------------
ECO F 23-JAN-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9F
Problem:
The $parse leaves channels behind, if search list is involved.
Solution:
Changed many places in many routines to clean up channels after
the $parse: retr,stor,check_filetype.
Added a new routine to do it ( dassign_parse_chan() ).
ECO G 27-FEB-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9G
Problem:
Could not write to a non-directory device. (e.g. LTA:,
terminal)
Solution:
Do not check directory on such devices.
ECO 5 Updates:
--------------
ECO H 21-MAR-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9H
Problem:
Put to a concealed device with dir of [000000] failed.
Solution:
Made stor not pre-check directory access.
ECO 7 Updates:
--------------
ECO I 11-APR-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9I
Problem:
Sendport (disable port) does not work.
Solution:
Fixed dataconn to use correct port if PORT command disabled.
Fixed connect in dataconn to retry for 32 seconds.
Also modified all retry_cnt loops to 32 not 30.
ECO J 20-APR-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9J
Problem:
The checkdir_access is looking for ']' if there are
subdirectories in the target spec of a 'put' command.
If the customer uses angle brackets, this search fails,
causing 'protection' error on a 'put'.
Solution:
Modify stor not to checkdir_access if '<' present.
ECO K 25-APR-1995 VAX/AXP
Images:
UCX$FTPC.EXE UCX V3.2-9K
UCX$FTPD.EXE UCX V3.2-9K
Problem:
Exclamation points in UCX$FTP_SERVER_ANNOUNCE and
UCX$FTP_ANONYMOUS_WELCOME messages messed things up.
Solution:
Modify FTP$SERVER_ANONYMOUSD\send_server_message call to
sendreply FTP$SERVER_ANONYMOUSD\send_client_message call
to postreply.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 SMTP Mail Facility
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A VAX/AXP
Images:
UCX$SMTP_MAILSHR.EXE UCX V3.2-9A
UCX$SMTP_RECEIVER.EXE UCX V3.2-9A
UCX$SMTP_SYMBIONT.EXE UCX V3.2-9A
UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9A
UCX$UUENCODE.EXE UCX V3.2-9A
UCX$UUDECODE.EXE UCX V3.2-9A
Problem:
If mail comes in from a non-SMTP user to a user who has
forwarded their mail via SMTP on the local system, the
VMSmail From line will reject the reply command. If the
non-SMTP transport from which the mail comes is DECnet,
the From line is enclosed in double quotes. If the
non-SMTP transport is MTS, the From line is enclosed in
double quotes and also contains backslashes preceding the
inner double quotes in the address. The old code would
produce:
From: "SOMNOD::SOMEBODY"
rather than
From: SOMNOD::SOMEBODY
or this:
From: "MRGATE::\"MRGATE::SUMNOD::SENDING_USER\""
rather than
From: MRGATE::"MRGATE::SUMNOD::SENDING_USER"
Solution:
Fixed.
Problem:
UCX SMTP does not recognize mail to be delivered to the
domain specified by the substitute domain as local. This
required the workaround of defining an alias in the local
host database matching the substitute domain. For example,
if UCX host "abc.def.com" has an SMTP substitute domain of
"def.com" defined and mail goes to host "abc.def.com"
addressed to "jones@def.com" this mail would not be
recognized as local and delivered locally to user jones
unless an alias "def.com" for the host "abc.def.com" was
defined in the local host database.
Solution:
Fixed. UCX SMTP now recognizes mail sent to the
substitute domain as local. In the event that you do not
want it to recognize mail sent to the substitute domain
as local, define the system logical
UCX$SMTP_NO_SUBS_DOMAIN_INBOUND before starting the SMTP
mail queue.
Problem:
For inbound mail, UCX SMTP would never put anything in to
the VMSmail CC line.
Solution:
For inbound mail, UCX SMTP now sets the VMSmail CC line.
(See next problem/solution for more information.)
Problem:
For inbound mail, UCX SMTP would unconditionally put the
RFC To header in to the VMSmail To: line.
Solution:
For inbound mail, UCX SMTP now puts the X-VMS-To RFC
header in to the VMSmail To: line for inbound mail if an
X-VMS-To RFC header is present. If one is not then the RFC
To: header will go into the VMSmail To: line. The same is
now true for the VMSmail CC: line. That is, if an
X-VMS-Cc RFC header is present it will go in to the
VMSmail CC: line. Otherwise any RFC CC header will go in
to the VMSmail CC: line. If it is not desired to put the
X-VMS-... headers in the VMSmail To: and CC: lines then
define the system logical UCX$SMTP_INBOUND_NOXVMS before
SMTP execution queue startup.
ECO 5 Updates:
--------------
ECO B 23-MAR-1995 VAX/AXP
Images:
UCX$SMTP_MAILSHR.EXE UCX V3.2-9B
UCX$SMTP_RECEIVER.EXE UCX V3.2-9B
UCX$SMTP_SYMBIONT.EXE UCX V3.2-9B
UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9B
UCX$UUENCODE.EXE UCX V3.2-9B
UCX$UUDECODE.EXE UCX V3.2-9B
Problem:
Commands VRFY and EXPN do not work. Even though the VRFY
command is optional in its implementation, some systems
rely on it by doing a VRFY on a user or an EXPN on a
list before sending mail to it.
Solution:
Fixed.
Problem:
UCX SMTP receiver cannot handle multi-line reply to the
HELO command.
Solution:
Fixed.
ECO 7 Updates:
--------------
ECO C 5-JUN-1995 VAX/AXP
Images:
UCX$SMTP_MAILSHR.EXE UCX V3.2-9C
UCX$SMTP_RECEIVER.EXE UCX V3.2-9C
UCX$SMTP_SYMBIONT.EXE UCX V3.2-9C
UCX$SMTP_PARSESHR_TV.EXE UCX V3.2-9C
UCX$UUENCODE.EXE UCX V3.2-9C
UCX$UUDECODE.EXE UCX V3.2-9C
Problem:
When many inbound SMTP connections are made at the same
time, UCX SMTP will sometimes create control file names
that are identical for more than one mail. This causes
UCX SMTP to deliver one of the versions of the control
file multiple times and not to deliver the rest at all.
Solution:
Made UCX SMTP sensitive to the file version number so
that files with the same name are properly handled.
Problem:
It is impossible to send a file using UCX SMTP with lines
greater than 512 characters and less than 1000
characters. UCX SMTP inserts . The SMTP RFC allows
up to 1000 characters.
Solution:
Up buffer size to 1000 (inclusive of ). Note that
this fix applies to outbound mail. For mail received from
SMTP and delivered locally via VMS mail we must still add
line breaks () every 255 characters because this
size is a VMS mail limit.
Problem:
If SYS$SCRATCH is defined to a bad value for the SMTP
symbiont process (that is, a directory where a file
cannot be created for some reason) UCX SMTP symbiont
cannot deliver any local mail.
Solution:
Use RMS Parse call to check SYS$SCRATCH directory
validity in mainline of SMTP symbiont. If invalid, then
redefine SYS$SCRATCH to point to the postmaster
directory.
Problem:
SMTP addresses placed in SMTP mailing list files could not
contain comments. (This applies to the mailing lists in
SYS$SPECFIC:[UCX_SMTP] which contain SMTP addresses and
are processed by the SMTP symbiont. This does not apply
to VMS mail distribution lists which contain SMTP
addresses in the SMTP%"..." format.)
Solution:
Fixed.
Reference:
None.
Problem:
Cannot use SET FORWARD/USER=username SMTP%"..." to send to
multiple SMTP addresses.
Solution:
You can now use SET FORWARD/USER=username SMTP%"..." to
forward mail to multiple recipients. For example. Say the
following forward is defined on host xyz.com:
MAIL> SET FORWAR/USER=HOTLINE SMTP%"""kim@xyz.com, joe@abc.xyz.com"""
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
More than one name here -->--->------->-----+
This will cause mail sent to the user HOTLINE to be sent
via SMTP to kim@xyz.com and to joe@abc.xyz.com. If you
are sending mail to HOTLINE from the host on which the
forwarding has been defined then you can send to that
username directly like this:
MAIL> send
To: HOTLINE
...
If you are on another host you can send to
hotline@xyz.com and UCX SMTP on host xyz will expand the
mail to go to kim@xyz.com and to joe@abc.xyz.com. Note
that this is limited by maximum length of a VMS mail
command line, 256 characters.
Problem:
1. On AXP systems, ANALYZE MAIL/REPAIR terminates with
"%SYSTEM-F-IVLOGNAM, invalid logical name" message
frequently.
2. Mail directories which are specified with "<",">"
instead of "[","]" (for example dka0:) are not
being handled correctly, resulting in an access
violation.
3. Usernames of 12 characters in length were not being
handled correctly resulting in the following error
message in ANALYZE MAIL/REPAIR : %UCX-W-ANA_QUEACC, queue
access failure -JBC-F-INVPARLEN, invalid parameter length
.....
Solution:
Fixed.
Problem:
See control file error when mail is sent from a user
whose mail directory is obtained from a concealed logical
name.
Solution:
Fixed.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 LPD Facility
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A VAX/AXP
Images:
UCX$LPD_SHR.EXE UCX V3.2-9A
UCX$LPD_SMB.EXE UCX V3.2-9A
UCX$LPD_RCV.EXE UCX V3.2-9A
UCX$LPQ.EXE UCX V3.2-9A
UCX$LPRM.EXE UCX V3.2-9A
UCX$LPRSETUP.EXE UCX V3.2-9A
UCX$TELNETSYM.EXE UCX V3.2-9A
Problem:
The LPD receiver signals a protocol error if it receives
the "Print any waiting jobs" command. (This command is
indicated by a control byte equal to 1.)
Solution:
The LPD receiver now ignores this command by
acknowledging it and continuing. No protocol error
occurs.
Problem:
If SYS$SCRATCH is not defined in the system table and an
inbound print request with a mail notification request
comes in, the UCX$LPD_QUEUE symbiont dies with
%MAIL-E-OPENOUT, -RMS-F-DEV errors.
A previous problem fix for SMTP stopped the SMTP symbiont
from defining SYS$SCRATCH in the system table. Defining
SYS$SCRATCH in the system table was not correct behavior
for SMTP, however it had the positive side-effect of
covering up this problem in LPD because SYS$SCRATCH was
always defined.
Solution:
Check for SYS$SCRATCH logical being defined in LPD
symbiont process. If it is not defined then define it to
UCX$LPD_SPOOL in the LPD symbiont process's process
logical table.
Problem:
Inbound job completion OPCOM message is no longer
generated even if LPD service log option LOGOUT is set.
Solution:
Fix it.
Problem:
LPD_RCV and LPD_DEBUG diagnostics logicals provide no
diagnostics to track what the LPD client sends over link
and what the receiver receives.
Solution:
The LPD_RCV and LPD_DEBUG diagnostics logicals have been
enhanced to provide some information more useful to
customers in diagnosing problems. For those customers who
have used the old LPD diagnostics by defining the system
logicals LPD_RCV and LPD_DEBUG to 65535, the new value to
get the same effect is 7. So, replace:
$ DEFINE/SYSTEM LPD_DEBUG 65535
$ DEFINE/SYSTEM LPD_RCV 65535
with
$ DEFINE/SYSTEM LPD_DEBUG 7
$ DEFINE/SYSTEM LPD_RCV 7
LPD_DEBUG and LPD_RCV are bit-mapped values. The low
order three bits are used (hence a value of 7) to give
the effect previously produced by all the bits being set
(old value of 65535). Additionally, a new diagnostic has
been added to LPD_DEBUG and LPD_RCV. If the fourth bit is
set (value 8) then the LPD symbiont will log each buffer
that it sends over the TCP/IP link to the log file and
the LPD receiver will log each buffer that it receives
from the TCP/IP link to the log file. This provides a way
to see exactly what the LPD is sending (for outbound
jobs) and receiving (for inbound jobs) in order to
diagnose problems. To turn on just this new diagnostic
and no other diagnostics, set the fourth bit of the
LPD_DEBUG and LPD_RCV logicals by defining them to 8. To
get the old diagnostics along with this new one, define
LPD_DEBUG and LPD_RCV to 15. Use of these is only
recommended in the diagnosis of problems. Leaving the
diagnostics on during normal use will greatly slow the
performance of LPD and will produce large log files.
Note that the LPD_DEBUG and LPD_RCV logicals are
independent. LPD_DEBUG applies to outbound jobs (the LPD
client) where LPD_RCV applies to inbound jobs (the LPD
server). LPD_DEBUG will cause diagnostics to be written
to an LPD queue's log file. LPD_RCV will cause
diagnostics to be written to the receiver's log file,
UCX$LPD_RCV_LOGFILE.LOG.
ECO 2 Updates:
--------------
ECO B 16-JAN-1994 AXP
Images:
UCX$LPD_SHR.EXE UCX V3.2-9A
UCX$LPD_SMB.EXE UCX V3.2-9A
UCX$LPD_RCV.EXE UCX V3.2-9A
UCX$LPQ.EXE UCX V3.2-9A
UCX$LPRM.EXE UCX V3.2-9A
UCX$LPRSETUP.EXE UCX V3.2-9A
UCX$TELNETSYM.EXE UCX V3.2-9A
Problem:
Outbound PRINT/PASSALL of a file with an embedded
carriage control adds extra LFs.
If PRINT/PASSALL of a non-stream LF file which contains
an embedded carriage control is done to an outbound LPD
queue and the embedded carriage control does not end text
lines in an LF, then an extra LF is inserted for each
line. This problem manifests itself as double-spaced printing.
The most common cause of this is printing a non-stream LF
file from an application that ends its text lines with
LFCR rather than CRLF.
Solution:
Fixed.
If you suddenly have a problem with /PASSALL printing you
can get the old behavior back doing:
$ DEFINE/SYSTEM UCX$LPD_STREAM_PASSALL 1
You should not need to do this though. If you have a
problem with /PASSALL printing that seems to be fixed by
doing this then please report it to Digital.
Problem:
Contention over shared LPD receiver log file
(UCX$LPD_RCV_LOGFILE.LOG) makes problem diagnosis more
difficult.
Solution:
All UCX LPD receiver diagnostics are now written to
UCX$LPD_RCV_STARTUP.LOG. UCX$LPD_RCV_LOGFILE.LOG is
obsolete.
Problem:
Receiver fix in ECO C to handle control file before data
files broke handling of multiple LPD jobs per session. If
multiple jobs are printed in quick succession from U*ix,
then some jobs are lost by the LPD receiver.
Solution:
Fix it.
Problem:
UCX LPD does not honor VMS flag page print options.
Outbound LPD jobs (client):
The only way to suppress flag pages (banner pages in U*ix
terminology) is to print with /PARAM=NOFLAG. Being that
there is no way to set a queue to a
/DEFAULT=/PARAM=NOFLAG there is no way for VMS
applications that submit jobs to print queues with
$SNDJBC to control printing of flag pages without
changing them to submit with /PARAM=NOFLAG. Also it would
be more intuitive for VMS users and system managers if
LPD supported PRINT/[NO]FLAG.
Inbound LPD jobs (server):
The presence of an 'L' control card in the incoming
control file indicates that a flag page is to be printed.
However, when the UCX LPD submits an incoming job to the
final destination queue it submits the job neither with
/FLAG nor /NOFLAG. Thus, it ignores the presence/absence
of the 'L' card and leaves the flag page generation up to
the default of the destination queue.
Solution:
There is a new logical UCX$LPD_VMS_FLAGPAGES which, if
defined tells UCX LPD to honor what VMS tells it to do
with flag pages for outbound jobs and to submit inbound
jobs explicitly with /FLAG or /NOFLAG based on the
presence of the 'L' card in the control file. To get the
new behavior add this to your UCX$LPD_STARTUP.COM:
$ DEFINE/SYSTEM UCX$LPD_VMS_FLAGPAGES 1
- For outbound jobs:
- When this logical is defined /PARAM=NOFLAG has no effect.
- If this logical is defined UCX LPD will honor the /FLAG or
/NOFLAG qualifiers from the PRINT command and from the
/DEFAULT= and the /SEPARATE= settings on the queue itself.
- Though the /[NO]FLAG qualifier is a positional
qualifier on the VMS print command we cannot honor it as
such since the LPD print protocol provides no way to
express that one file in a job should receive a banner
page and another one should not. This works:
$ PRINT/FLAG/que=outbound-LPDQ file1.txt, file2.dat
^^^^^
while this does not:
$ PRINT/que=outbound-LPDQ file1.txt,file2.dat/FLAG
^^^^^
- For inbound jobs:
- If the logical is defined then the UCX LPD symbiont
(running in the UCX$LPD_QUEUE queue) submits the inbound
job as /FLAG if the control file says to print a banner
page (i.e., includes an 'L' card) and it submits the job as
/NOFLAG if the CF says no banner page (no 'L' card).
- A problem for those depending on the old incorrect behavior
of FLAG pages for inbound jobs.
- If the destination queue is set up with the default
being NOFLAG and a job comes in indicating that a flag
page is to be printed then the job will be submitted with
a flag page. This could cause difficulties for a site
that depended on the old behavior. (People who have been
printing all along to UCX LPD without bothering to
suppress the flag/banner page.) It was working (i.e., they
were not getting a flag page which is the desired result)
because UCX LPD did nothing with respect to flag pages
and the destination queue happened to be set up with
/DEFAULT=NOFLAG. With the new LPD server they will get a
flag page which they do not want. The only way to get
around this is to force the user to print explicitly with
flag page suppression.
For both inbound and outbound jobs:
- UCX$LPD_VMS_FLAGPAGES is only translated once at symbiont
startup. This mean that you can get different
queue-by-queue behavior by defining the logical before
starting up a queue for which you want the new behavior
and deassigning it before starting a queue for which you
want the old behavior.
Corresponding UCX$LPRSETUP change for adding "remote" printer
- Regardless of whether or not the logical is defined,
UCX$LPRSETUP now asks you if you want the default for the
queue to print with a flag page when you add a remote
printer. If you answer yes then the queue is created with
/DEFAULT=FLAG and the queue startup text in the
UCX$LPD_STARTUP.COM file for the queue also contains the
/DEFAULT=FLAG. For sites that do not define the new
logical, this behavior will be harmless as the symbiont
will ignore the /DEFAULT=FLAG anyway.
If you decide to use this new feature, you need to edit
the queue startup commands in your UCX$LPD_STARTUP.COM to
have a /DEFAULT=FLAG for each outbound LPD queue that you
want to default to print flag pages.
The old behavior is preserved if the
UCX$LPD_VMS_FLAGPAGES logical is not defined! That is,
everything will work exactly as it did before. The only
way to suppress flag pages is to PRINT/PARAM=NOFLAG.
ECO 5 Updates:
--------------
ECO C 22-MAR-1995 AXP
Images:
UCX$TELNETSYM.EXE UCX V3.2-9C
Problem:
Tail end of files do not come out at printer when the link
idle timeout logical (UCX$TELNETSYM_IDLE_TIMEOUT) is not
defined.
Solution:
Fixed.
Problem:
Various problems associated with bringing down link
immediately at the end of each job (i.e., link idle timeout
logical not defined). The workaround for these was to
define the link idle timeout logical.
Solution:
Fixed.
Problem:
TELNET symbiont process names default to SYMBIONT_nnn
after first process created.
Solution:
First TELNET symbiont process calls itself UCX$TNSYM1,
second calls itself UCX$TNSYM2, etc.
Problem:
OPCOM messages sent by TELNETsym do not say which remote
printer they have occurred for making it impossible to
know which execution queue to look at for problems.
Solution:
OPCOM messages now include name of execution queue.
Problem:
If
1. there is an idle link to the printer (i.e., no print job
is in process and the idle link timeout is configured for
the printer but has not yet expired).
--- AND ---
2. the power on the printer is cycled
--- THEN ---
the TELNET symbiont does not recognize that the link has
gone away until the next job is printed and this print
job fails with NOIOCHAN.
Solution:
Because the TELNETsym did not keep an outstanding read on
the TCP link to the printer it could not discover the link
was gone until it tried to write to the link when the
next print job came in. The TELNETsym now keeps an
outstanding read on the link at all times so it detects
channel loss immediately.
Note that in the case where the printer goes dead (i.e.,
is powered off and on) this will only be recognized as a
dead link by the TELNETsym if you have configured
TELNETsym keepalive for that execution queue. To
configure TELNETsym keepalive, execute the following
command before starting the queue:
$ DEF/SYS UCX$TELNETSYM_KEEPALIVE 1
Further, the timing of when the dead link is recognized
as such is set by the drop and probe time on the link.
You can take the system defaults for these (visible if
you do a UCX SHO PROTO TCP/PARAM) or you can set either
or both of these values yourself by defining the logicals
UCX$TELNETSYM_DROPTIME and UCX$TELNETSYM_PROBETIME. For
example to set the drop time to 20 seconds and the probe
time to 15 seconds, perform the following commands before
starting the queue. (NOTE: Remember that the drop time
must be greater than the probe time.)
$ DEF/SYS UCX$TELNETSYM_KEEPALIVE 1
$ DEF/SYS UCX$TELNETSYM_DROPTIME 20
$ DEF/SYS UCX$TELNETSYM_PROBETIME 15
Problem:
TELNETsym log files not purged automatically.
Solution:
New TELNETsym logical, UCX$TELNETSYM_LOG_KEEP, sets
maximum number of logs to keep around. For example, to
tell TELNETsym to keep no more than 3 copies of a log
file around do:
$ DEF/SYS UCX$TELNETSYM_LOG_KEEP 3
Problem:
Symbiont crashes can take up to 16 execution queues down.
This is especially problematic for production
environments.
Solution:
A new TELNETsym logical, UCX$TELNETSYM_STREAMS, sets the
number of execution queues that a TELNETsym symbiont
process can serve. The legal value for this logical is
between 1 and 16 inclusive. You can use this logical to
effectively turn your TELNET symbiont into a single
threaded symbiont if you define it to 1 by using the
following command:
$DEF/SYS UCX$TELNETSYM_STREAMS 1
If you are going to do this it makes the most sense to
define the logical once and let the value stand for each
queue you start.
If you run TELNETsym as a single threaded symbiont then a
symbiont crash will only bring down the one execution
queue in which the crash occurred. This TELNETsym change
is obviously only a workaround.
For those familiar with modified print symbionts, the
value you enter for UCX$TELNETSYM_STREAMS is passed to
the PSM$PRINT system routine in the "streams" argument.
If this logical is not defined then the behavior of the
TELNETsym remains as it was before. It will run with the
VMS maximum of 16 execution queues per symbiont process.
Problem:
TELNETsym crashes with PSM-F-BADLOGIC if the following
sequence of events occurs:
1. A job is printed to a TELNETsym queue but a link
cannot be established to the printer because the
printer is not responding. (The printer may be busy
printing another job or be out of paper).
2. This queue is stopped with a STOP/QUEUE/RESET.
3. A TELNETsym queue (either another queue or the first
one) is started and the remote printer pointed to by
the queue that is started is available.
Solution:
Fixed.
Problem:
Another problem like the previous one existed too. If the
same sequence occurs but a DELETE/ENTRY is done on the
job rather than a STOP/QUEUE/RESET on the queue then the
queue would hang.
Solution:
Fixed.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 PORTMAPPER
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 16-DEC-1994 AXP and VAX
Images:
UCX$PORTMAPPER.EXE UCX 3.2-9A
Problem:
Portmapper loops writing error messages to log file when
registration fails.
Solution:
Break from loop when a matching registration is found and
cannot be replaced.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 RPC and XDR routines
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 06-JAN-1995 AXP and VAX
Images:
UCX$RPCXDR_SHR.EXE
UCX$PORTMAPPER.EXE
Problem:
Improper pointers cause the XDR object pointer to
increment in fours, instead of in elsize units in
xdr_vector().
Solution:
Make eladdr the pointer instead of a pointer-to-pointer
like addrp.
Problem:
XDR_VECTOR() addrp argument is incorrect type.
Solution:
Correct the definition and usage of the addrp argument.
Problem:
Portmapper loops writing error messages to log file when
registration fails.
Solution:
Break from loop when a matching registration is found and
cannot be replaced.
Problem:
CLNT_SPERRNO(), CLNT_SPCREATE_ERROR() and CLNT_SPERROR()
are missing VAX transfer vectors and AXP symbol vectors.
Solution:
Add the appropriate vectors to make the procedures
accessible
ECO 7 Updates:
--------------
ECO B 31-MAY-1995 AXP and VAX
Images:
UCX$RPCXDR_SHR.EXE UCX V3.2-9B
Problem:
An error in the XDR routine `xdr_float()', caused an
assignment instead of a test when decoding an IEEE float
(from the network) into a local F_Float value.
Solution:
Correct the typo.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 RSH
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 06-JAN-1995 AXP and VAX
Images:
UCX$RSH.EXE
Problem:
RSH hangs when executing on a non-terminal. Redirected
output is bogus.
Solution:
Check for the device type and do the right thing. Change
the output mechanism.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 PWIP Driver and ACP
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 11-NOV-1994 AXP and VAX
Images:
UCX$PWIPACP.EXE UCX V3.2-9A
UCX$PWIPDRIVER.EXE UCX V3.2-9A
UCX$PWIPSHUT.EXE UCX V3.2-9A
UCX$SDA.EXE UCX V3.2-9A
Problems, solutions and/or enhancements:
1. On rare occasions, Pathworks sends down a mis-typed
mblk/dblk/buffer set for transmit. The data in this set
is correct, but the type field is not (it should be type
M_DATA, but is type M_PROTO). PWIPdriver did not properly
deal with this circumstance. It actually went into a
state that effectively blocked all further transmissions
on the connection in question. This is actually a
Pathworks inspired problem, and they will be providing a fix.
They have asked, however, that we relax our type checking
for all properly identified transmission sets (which this
is), and assume that we are dealing with type M_DATA.
This ECO does just that.
2. Upgraded the UCX SDA backend to support additional
counters.
3. Support zero length transmissions as called for in the
supporting specifications.
4. Support naked M_DATA transmissions on TCP connections as
called for in the supporting specifications.
5. Check to ensure that UCX is running before allowing PWIP
to start. If UCX is not running, abort the PWIP ACP startup.
6. T_addr_req/t_addr_ack processing did not always return the
requested information:
If the connection in question was a listener, it always
returned the local IP address as zero (0); regardless of
whether the local system was multi-homed or not it only
returned one (1) local address.
Changed the logic to fix the above deficiencies.
ECO B 16-NOV-1994 VAX and AXP
Images:
UCX$PWIPACP.EXE UCX V3.2-9B
UCX$PWIPDRIVER.EXE UCX V3.2-9B
Problems, solutions and/or enhancements:
1. Premature connect reject failure. If the QIO fails for
an incoming connect reject do not return an error ack.
Rather, setup and call disconReq_ast to deassign the
associated channel. If the deassign completes
successfully return a T_DISCON_REQ ok ack else return an
error ack.
2. Change acp_ok_ack to process the T_CONN_REQ /
automatic T_BIND_REQ Pathworks kludge before grabbing
IOLOCK8, thus removing the need to release and re-acquire
the lock later.
ECO 7 Updates:
--------------
ECO C 18-MAY-1995 AXP/VAX
Images:
UCX$PWIPDRIVER.EXE
Problem:
System crash in PANIC called from SBDROP, due to
inconsistent receive socket buffer showing non-zero CC
(Character Count) with no mbufs hanging off the socket
buffer.
Solution:
Problem is due to premature clearing of the
UCB$M_BG_Defer_WinAdj flag in routine
pwip_handshake_transport in PWIPDRIVER_SUPP.C. Fix
entails eliminating clearing of this bit in this routine.
ECO D 18-MAY-1995 AXP/VAX
Problem:
System in adjTCPwindow due to doing arithmetic on fields
of a stale UCB.
This problem is triggered by an upstream mbuf being freed
after the connection has been closed. Previously, mbufs
passed upstream had a pointer to the UCB and if the mbuf
was not deallocated before the connection disappeared we
ran the risk of using a stale UCB.
Solution:
Created a new structure, the DWAB (Deferred Window
Adjustment Block) which is guaranteed to persist until
the last mbuf is returned. We now point the mbufs to
the DWAB instead of at the UCB.
Note that this fix entails changes to both PWIPDRIVER and
to the NET facility (UCX$INTERNET_SERVICES.EXE for VAX
and UCX$BGDRIVER.EXE for ALPHA).
Images:
UCX$PWIPDRIVER.EXE UCX V3.2-9D
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 CFS_SHR.EXE images
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 17-NOV-1994 AXP
Images:
UCX$CFS_SHR.EXE UCX V3.2-9A
Problem:
If a file containing any form of variable length records
is accessed with format conversion enabled, a message of
the type "thread exits while holding resources" is
written to _OPA0:. Subsequently, the content of the file
is not converted and the server may eventually enter a
hang or loop condition when an attempt to close the file
is made.
Solution:
The problem lies in the file system OPEN and READ
services. If a variable length record's length shortword
is on an 8KB boundary in the file, the conversion
scanning code will exit with an access violation. The
locked buffer will remain locked and the message is
generated. The problem is that the thread exit code does
not properly clean up the lock's context causing it to
remain in a locked state. When an attempt to close the
file is made, the locked buffer will cause the server to
enter an AST loop. If an attempt to flush the buffer
from the cache (via the LRU mechanism) is made, the
server can enter a hang condition.
Solution:
Correct the code which cleans up the locked resource.
This removes the hang and looping problems. Correct the
code in the OPEN and READ services. This removes the
corruption and the console message problems.
VAX and AXP
Images:
UCX$CFS_SHR.EXE
Problem:
If ADD EXPORT was done with /OPTIONS=PURGE_VERSIONS, the
presence of a file with null name and extension (i.e., .;1)
makes the rest of the files in the directory invisible to
the ls command.
Solution:
An additional check for file name length of 1 was added
to the decision for stripping the version number from the
file name. This prevents confusion from special casing
the .;1 file and not stripping the version even though
there are not multiple versions.
Problem:
The file system would crash if the final record of a file
crossed the EOF mark. Such a file is (technically)
invalid, and RMS-32 would ignore the record. A typical
way to recreate this problem would be to SET
FILE/END_OF_FILE when the EOF references the middle of a
disk block. Note that this (in effect) corrupts the data
at the end of the file and may result in unexpected
results when reading from or appending to the file.
Solution:
When scanning the file at access time, stop building the
RMAP structure when a record crosses EOF. In addition, do
not include the record in the converted size of the file.
ECO 3 Updates:
--------------
Back to original image UCX$CFS_SHR.EXE UCX V3.2-9
ECO 4 Updates:
--------------
ECO B 20-FEB-1995 VAX and AXP
Images:
UCX$CFS_SHR.EXE UCX V3.2-9B
Problem:
When building the RMAP, the data buffer descriptor
remains in a locked state (with PENDCNT > 0), causing a
loop when an attempt to close the file is made.
Solution:
The lack of a pair of parenthesis resulted in the
complementing of the address of the status variable.
This caused a premature exit from BUILD_RMAP, leaving the
descriptor with a non-zero pend count.
ECO 5 Updates:
--------------
ECO C 01-MAR-1995 VAX and AXP
Images:
UCX$CFS_SHR.EXE UCX V3.2-9C
Problem:
When `REAL_SIZE' determination is enabled in UCX$CFS_SHR
(via logical UCX$CFS_MODUS_OPERANDI mask 512), writes to
certain files result in corruption.
Solution:
An access check in BFS$OPEN_FH() was in error. Its
purpose was to reaccess files for write after they have
been accessed for read. When REAL_SIZE is enabled, a
request to read access a file after it is accessed for
write should result in a nop, but instead would reaccess
the file in read-only mode. The subsequent write
operations would internally result in the error
SS$_NOPRIV, which the user did not see.
---------------------------------------------------------------------------
Fixes for DEC TCP/IP Services V3.2 PCNFSD
---------------------------------------------------------------------------
ECO 1 Updates:
--------------
ECO A 8-DEC-1994 VAX and AXP
Images:
UCX$PCNFSD.EXE UCX V3.2-9A
Problem:
If the PC client sent a fully qualified host name in its
RPC request to print, the PCNFSd constructed a spool
subdirectory name on the form of
[SPOOLDIR.host.domain1/domain2]. It then failed while
attempting to create the subdirectory.
Solution:
If the client sends a fully qualified host name on
print_start, throw away the domain name before
constructing the name of the spool subdirectory.
Problem:
On renaming the print file into the spool subdirectory,
if a file by the same name is already queued up for
printing, PCNFSd attempts to avoid name collision by
appending some random digits during the rename into the
spool subdirectory. It was getting confused and
appending the digits to the host level spool directory
instead of the file name.
Solution:
Code appending the random number was moved.
INSTALLATION NOTES:
In order for the corrections in this kit to take effect, the system
must be rebooted. If the system is a member of a VMScluster, the
entire cluster should be rebooted.
REFERENCES:
IBM is a registered trademark of International Business Machines.
Macintosh is a registered trademark of Apple Computer, Inc.
PostScript is a registered trademark of Adobe Systems Incorporated.
UNIX is a registered trademark licensed exclusively by X/Open Company Ltd.
|
Files on this server are as follows:
|
»ucxeco7-032.README
»ucxeco7-032.CHKSUM
»ucxeco7-032.CVRLET_TXT
»ucxeco7-032.a-dcx_axpexe
»ucxeco7-032.a-dcx_vaxexe
|
