david@thor.INS.CWRU.Edu (David Nerenberg) (12/14/90)
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 <ISSKCM%BYUVM.BITNET@cunyvm.cuny.edu>
Organization: Brigham Young University, Provo, Utah, USA
Subject: Info on the lost connection problem.
To: pcip list <pcip@udel.edu>
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