Newsgroups: bit.listserv.novell
Date:         Thu, 19 Nov 1992 15:57:52 EST
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Brett Warthen <BRETT@INFINITE.MHS.COMPUSERVE.COM>
Subject:      RE: GET LOCAL TARGET STACKS

FORWARDED MESSAGE from "A.G. Lowe-Norris" (MAIL @ CSERVE
AL> {INTERNET:agl1@LEICESTER.AC.UK}) at 11/18/92 5:02 PM
AL>
AL> Hi all,
AL>         I have recently had a program which hangs when it attempts to
AL> send messages to multiple stations. As we are running ODI, the
AL> suggestion was made
AL> to put GET LOCAL TARGET STACKS = 5 in my NET.CFG and this would cure
AL> it.
AL>         Well, it has. Only thing is I'm unsure WHY it works. Can anyone
AL> out there explain what the problem was & why this fix works please.
AL>
AL>         Thanks to all in advance.
AL>                                 Alistair.
AL>
***** NOTES from Brett Warthen (BRETT @ INFINITE) at 11/19/92 1:48 PM
Alistair,

Since I started this whole GET LOCAL TARGET STACKS business out on
CompuServe a number of months ago, let me tell you what I know.

Basically, there is a bug in NETX, particularly when working with the ODI
drivers.

I saw this problem on a couple of machines with NETX v3.22 and IPXODI, and
one machine with regular old IPX v3.10 and NETX v3.26...but the combination
of NETX v3.26 and IPXODI seems to be the worst.

When I saw the mention of the GET LOCAL TARGET STACKS configuration
statement in the documentation for the new DOS/Windows Workstation Kit, I
discovered that it took care of the problem (at least it did for most
people, there are still some folks where it doesn't do anything).

Jimmy Wright, one of the Windows driver engineers at Novell, did some
investigation into the problem, and as it turns out, its just coincidental
that GET LOCAL TARGET STACKS fixes the problem.  So, there is no magic to
this statement, or anything that you need to really understand about it.

As he explained to me...essentially, something is going wrong in NETX with
the broadcast message handling code, which results in a bad pointer.  This
pointer corrupts memory immediately after IPXODI.  GET LOCAL TARGET STACKS
works around this problem for most folks because, because it allocates
additional memory for IPXODI, and this is the memory that ends up getting
corrupted.  By loading a dummy TSR after IPXODI, he was able to also work
around the problem.

The bottom line is that this is a bug that needs to be fixed, and Novell is
aware of it.

There also appears to be another problem with the broadcast message
handling which was alluded to in the other response that went out to the
list regarding this question.  The part pertaining to putting in a small
delay after sending the broadcast message before terminating the program.

Apparently, what is happening here is that when a program is terminating
and returning control to COMMAND.COM, there is a small window where DOS is
running with an extremely small stack being allocated.  When a broadcast
message is received at this point, the stack ends up getting corrupted.

I believe Jimmy Wright was also the one who explained this problem to me.

Since Novell has known about these problems for quite some time, it will be
interesting to see if the new NETX v3.31 included in the "security updates"
actually fixes the problem.

------------------------+-------------------------------------------------
 Brett Warthen          |        MHS:  Brett @ Infinite (via NHUB/CSERVE)
 Infinite Technologies  | CompuServe:  >MHS:Brett@Infinite
 11433 Cronridge Drive  |   Internet:  Brett@Infinite.mhs.compuserve.com
 Suite H                |       Phax:  +1-410-363-3779
 Owings Mills, MD 21117 |      Phone:  +1-410-363-1097
------------------------+-------------------------------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU