Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Packet Driver / Novell
Message-ID: <8904251438.AA00802@vax.ftp.com>
Date: 25 Apr 89 14:38:56 GMT
References: <8904242103.aa26327@louie.udel.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 23

I haven't tried to use the BYU Netware with the Clarkson drivers myself,
since we don't use Netware in-house.  We've used the Clarkson drivers with
PC/TCP quite a bit, and they seem to work fine (modulo the MTU problem in
the NI5210 as it was first released).

The notable difference between NCSA FTP and DOS COPY is probably the size
of the data blocks written: NCSA will be doing about 4K, and COPY will use
as much as it can (65K or more?).  It sounds like the problem is related
to the write size and/or the rate at which the data is presented.  Thus,
the first place I'd look is at re-entrancy in the packet driver; what happens
if it is re-entered from a hardware interrupt?  Can it stand being asked to
send a packet while it is in the receiver upcall?  Can it handle the case
where the protocol stack has no buffer for an incoming packet?

LANWatch (or NETWATCH or another protocol monitor) and a hardware debugger
would be useful here, as would some knowledge of the internal structure of
Netware.  Has NCSA been loaded before the crashes happen?  Try it without
running NCSA at all...

Has anyone else seen these problems?  Kelly?

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901