Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!nelson From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: Packet Driver / Novell Message-ID: Date: 27 Apr 89 21:53:45 GMT References: <8904242103.aa26327@louie.udel.edu> <8904251438.AA00802@vax.ftp.com> Sender: news@sun.soe.clarkson.edu Reply-To: nelson@clutx.clarkson.edu Organization: Clarkson University, Postdam NY Lines: 20 In-reply-to: jbvb@VAX.FTP.COM's message of 25 Apr 89 14:38:56 GMT In article <8904251438.AA00802@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes: ... (modulo the MTU problem in the NI5210 as it was first released). Which will be fixed with the next release thanks to Brad Clements. 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't happen -- interrupts are held off. Can it stand being asked to send a packet while it is in the receiver upcall? I just examined the code and the packet interrupt servicer seems to be re-entrant. Can it handle the case where the protocol stack has no buffer for an incoming packet? I'm pretty sure of this. Karn's code lets you specify how many buffers are to be used, and shelling to DOS will hold off packet processing so that they pile up, and sooner rather than later it will refuse packets. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) S&Ls get bailouts and that's okay, but poor people get welfare and that's not.