Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!gatech!ukma!usenet.ins.cwru.edu!thor!david From: david@thor.INS.CWRU.Edu (David Nerenberg) Newsgroups: comp.sys.novell Subject: Novell Disconnections Message-ID: <1990Dec13.211006.3858@usenet.ins.cwru.edu> Date: 13 Dec 90 21:10:06 GMT Sender: news@usenet.ins.cwru.edu Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) Lines: 64 Nntp-Posting-Host: thor.ins.cwru.edu The Novell disconnection problem has been traced down to the IPX and the packet driver, we knew that. The new information is that they have found that the only time this occurs is when the PD is shifted into promiscuous mode while being used in the normal mode with IPX at the same time. This amy very well be the cause of our problem in some form. Below is a copy of the informail I received. I will look into purchasing the 3.0 IPX from Kelly McDonald and get back to you all. Dave Date: Wed, 12 Dec 90 09:36:55 MST >From: Kelly McDonald Organization: Brigham Young University, Provo, Utah, USA Subject: Info on the lost connection problem. To: pcip list Message-Id: <901212.093655.MST.ISSKCM@BYUVM> I can't understand how the different packet types could cause the problems that have been mentioned in the list. We have traced the lost connection problem with packet drivers to the following scenario: 1. A client station is using the packet driver with the Netware shell driver. 2. Another program in the same station places the packet driver into promiscuous mode so that the packet driver begins to deliver packets that have other destination addresses besides that of the workstation. 3. IPX begins to receive watchdog packets meant for other stations, that it responds to. 4. A Netware 286 server will get confused and no longer receive packets from the original station. (We haven't noticed that it is a problem with 386 servers 5. The idle station begins to transmit to the server, and the server tells the station that its connection is no longer valid. This explains why idle workstations that are not even running the packet driver can still get the error. The culprit program that we traced it to is the netwatch over packet driver implementation, because it puts the card into promiscous mode. We fixed it in version 3.0 by doing an additional address check. (Netware shell specs don't require this since it assumes that the card will only deliver valid addresses) A better place to fix the problem is in the packet driver implementation. Packet drivers should not allow changing to promiscuous mode if another protocol stack has registered with the packet driver with mode 3. This is consistent with version 1.09 of the packet driver spec (page 9) where it indicates that read modes should not be changed if any other handles are open. (as I read it again, it really doesn't say that. James, perhaps the specs should be strengthened here, as we discussed at Interop.) The ironic thing (that we suffered from) was that the more we traced this problem (using netwatch) the worse it got. There may be other reasons why a packet driver would deliver incorrect addresses to the shell driver, but I don't think that the translation of 802.3 into 8137 is one of them. (or the non-translation of 8137 etc.) ------ -- david@po.cwru.edu * Eagle * David Nerenberg 73107,177 Compuserve * Computers * Information Network Services NY: H-516-751-6344 * Electronics * Case Western Reserve University W-516-751-8111 * Sound & Stage * W-216-368-2982 H-216-754-2063