Unexpected disconnects

Finding the source of an unexpected disconnect is very difficult since so many things can cause it to happen. DHCP time-outs, bad cables, bad routers, bugs in the server, bugs in the client, bad network cards, corrupted data, etc. So one person's problem with unexpected disconnects may be completely different from another persons problem. Also, there is the sheer randomness of the disconnects. That is why you do not see postings from Apple with a single magic answer. That said, here are some ideas to try...

DHCP - in OS 8.5.x
DHCP - in OS 8.5.x, Open Transport changed their DHCP implementation to be closer to the published standards. Apparently this has caused some disconnects to occur when getting close to the renewal times. To determine if this is your problem, try assigning a static IP address to those clients having problems. If the problem only occurs on those Macs with 8.5.x, then this is probably a good place to start.

AppleShare Client 3.8.1    
In AppleShare Client 3.8.1 (from OS 8.5.X), I did fix one hanging/disconnecting bug. It is always a good thing to try the latest AppleShare client on those Mac's having problems. As far as I know (no guarantee's here), the AppleShare client should work on most versions of the OS 7.5.x - 8.5.x, without having to upgrade the OS. Some versions of the clients have a gestalt checking for certain versions of Open Transport that we need. Just copy the AppleShare extension to the client CPU and reboot and see if it works. It should.

Software Conflicts
There seem to be conflicts with some virus checkers (don't remember which ones), and some versions of At Ease (donÕt remember which ones). Try disabling them and see if the problems go away. This is pretty standard isolations. Start with a "clean" system folder and start adding things in until the bug shows up.

EtherPeek Traces
Imagine trying to tell someone over the telephone (or by e-mail) how to assemble a bike while you are reading the instruction manual inside of a dark closet. Trace files of the network packets tell us exactly what is going on and exactly who is disconnecting who. The server can initiate or the client can initiate the disconnect and there is no way to tell the difference without a trace. Etherpeek is very cheap and a MUST HAVE for debugging network problems. You can download a free demo copy from their web site. No, I don't get any endorsement money from AG Group. I don't even get free copies of their software! ;-)

Network cards/hubs - full/half duplex
Full duplex is kind of like the early 33-56K modem implementations. If you had a modem from company A and another modem from company B, they typically did not work well together even though they both say they support standard XXX. Full duplex is still pretty much hit and miss if you mix and match components from different companies. Half duplex Ethernet seems pretty stable and reliable. Give it a try and see what happens. Trying different Ethernet cards/cables also can help you isolate where the disconnects may be occurring. I also have a small utility called Duplexer that allows you to "force" the Ethernet Duplex on many of Apple's built in Ethernet.

Duplexer – HQX-File, 231.7 KB

Slow Links
Special note ONLY for ISDN, DSL, modem, and WAN users (i.e. slow links). We have found that in many cases, older routers can not handle more than 8K of data sent all at once. In AppleShare client 3.8.3, there is a resource in the DATB #1413 called the "Max. Quantum Size". If you are experiencing slow performance of disconnects or hanging, then use ResEdit to set the "Max. Quantum Size" to 0x1ff0. By setting this value, you will be DECREASING your potential maximum performance if used on "fast" links, but increasing (or at least not changing much) your current performance over the "slow" links. Hopefully over the slow links, this will make things much better. In AppleShare client 3.8.4 and later, this will auto-magically be done for you. Again, only use resource change if you are on ISDN, DSL, modems, WANs, or other "slow" links.