From: heys@cwis.unomaha.edu (Matthew D. Heys)
Subject: Possible Pseudoexplanation for Telnet "freezes"
Summary: Hopefully some useful information on a common problem
Keywords: MacTCP, Asante, SE
Organization: University of Nebraska at Omaha
Date: Mon, 27 Jul 1992 14:23:32 GMT


<< WARNING: this post is quite long but hopefully full of valuable,
   timely information. If not, however, I claim no responsibility for
   injuries suffered by those whose heads smash into their keyboards
   from a sudden attack of narcolepsy >>

I've noticed a great deal of posting activity lately about problems with
NCSA Telnet "hanging" or "freezing," oftentimes on Macintosh SE's with
Asante ethernet cards [the Asante MacCon Ether SE/E card to be exact].

We probably have somewhere near a dozen machines exhibiting this problem
on campus, so I'd like to pass on what I [think] I have learned so far.

What makes the problem so baffling from a support standpoint, as I am
sure many of you know, is that you always think you have it beat. We
recently purchased a site license for MacTCP, and the telnet freeze
surfaced in the course of going from office to office updating all those
Macintoshes with hard-coded IP numbers for bootp. We did not notice the NSCA
Telnet hang on-site, however. We would always,

             o Install version 4.0 of the Asante drivers for
               the MacCon Ether SE/E card

             o Add MacTCP and MacTCP DNR to the system folder

             o Test Telnet - quite successfully.

A few days later, though, we would receive telephone calls describing
the "freeze" that's been a topic here on comp.sys.mac.comm lately. We
would then dutifully gather up our disks and head back out to repeat the
whole process, and lo and behold, one could telnet again. No hangs. No
freezes. No problems.

... but then the phone call again, and another appropriately puzzled user on
the other end unable to escape the NSCA banner screen. 

This is where it gets interesting to me:

Since the software worked, [verifiably], I decided to pursue a possible
hardware problem. We picked one of the troubled SE's as a guinea pig and
removed the following SE/E card from it:

<<Old Card>>

	MacCon SEE Revision A
	PN 09-00300-61
	Memory - Sony CXK5864BP-10L


... replacing it with a fresh shrink-wrapped card left over from a
    previous purchase:

<<New Card>>

	MacCon SEE Revision C
        PN 09-00300-61
        Memory - Mosel MS62256L-10PC

The problem remained, however. Of particular interest, [and this is
something that still troubles me], was the fact that there were some SE's
that performed beautifully with Telnet and TCP in general. This seemed
to indicate some problem with older ROMs, and that may still be the root
of the trouble, but I decided to stick with explanations I could do
something about.

So we moved on to the narrow-and-duplicate phase, soon realizing that any
application needing the services of MacTCP froze at times. A word of
advice for those of you about to send mail to mactelnet@ncsa.uiuc.edu:
Try out something like XferIt 1.4 and see if it fails too first. Your
problem may lie elsewhere.

Well, that didn't particularly narrow the problem, although now MacTCP
was suspect. DUPLICATING the problem turned out to be so simple that we 
failed to see it at first. As I scurried around for inits and memory
conditions that triggered the problem, the catalyst turned out to be far
more basic: cold starts.

We found in EVERY case that the problem SE would hang on its TCP services
if the application needing those resources was executed during a user session
that started with a power-up.

We also found that in EVERY case restarting the SE "from the hang screen"
seemed to fix the problem - until the next attempted telnet after a cold
start. We tested that 56 times, and it worked everytime.

It gets worse.

XferIt will at times drop out of its hangs - "Application XferIt 1.4
has unexpectedly quit (28)" If you open XferIt up again after being
dropped back to the desktop, you'll find that it works perfectly.

Now our Macs are set to send out bootp's, and I was beginning to wonder
just what was going wrong with the bootp-IP exchange. To that end, we pulled
out a packet analyzer and put it into capture mode.

... and learned that the SE/Ether SEE card never DOES send a broadcast of its
    hardware address. Ever. At least not after a cold start.

For users of SE's without programmer's/reset switches, this is a major
problem. Since their only way out of the freeze is to power the Mac off
and on again, they unknowingly place themselves in the loop. It's the cold
starts that trigger the problem in the first place.

Those of us "in-the-know" who frequently read newsgroups like
comp.sys.mac.comm then rush in, guns blazing, and reinstall the drivers and
MacTCP. If the problem looks particularly severe, we neuter the system folder
and reinstall the System.

I'm beginning to think it's the restart at the end of the Asante driver install
that actually returns normalcy to the situation!

A temporary [and bewilderingly crude] fix is of course to ...

           [a]. use a paperclip in the side ventilation slit to
                restart the SE,

                       or,

           [b]. choose "Restart" under the Special menu after start-up
                each day.

Using the paper-clip restart method from the TCP freeze has thus far
ALWAYS worked. We have had one exception to method "b" where the SE in
question froze even after a restart from the Special menu.

    I don't think it's the card - it's quite capable of doing AppleShare
    over EtherTalk and does not freeze-up there.

    I don't think it's anything pertaining to the Network cdev - Phase
    1, Phase 2, LocalTalk, - they can all be selected and active when this
    freeze-up takes place.

    I obviously don't think it's Telnet 2.5B or 2.5.

    I don't think it's the system version - the problem takes plus under
    systems 6.0.5, 6.0.7, 6.0.8 and 7.0.1.

    I don't think it's the Asante drivers for the same reason I don't think
    it's the card.

    I don't think it's a quirk of the interface card - it happens with
    10-base T and thin Ethernet.

    I don't think it's memory - it happens on 1, 4 and 5 megabyte
    machines.

    Quite frankly, I'm beginning to think it's MacTCP, or at the very
    least some aspect of older ROMs on SE's not accounted for by MacTCP.

 
    ... but seeing as I am not a member of the MacTCP development team,
        I'm very much open to comments, advice, post-hypnotic
        suggestion, etc.

              			       m@ heys
                                       Technical Specialist
                                       UNO Computing and Data Communications
                                       Office: EAB005
                                       Telephone: [402]554-3282
                                       E-Mail: mheys@unomaha.edu
--
m@ heys
TCIC
Newsgroups: comp.sys.mac.comm