Path: utzoo!attcan!uunet!steinmetz!control!dixon
From: dixon@control.steinmetz (walt dixon)
Newsgroups: comp.unix.aux
Subject: Re: problems with ethernet interface
Message-ID: <12275@steinmetz.ge.com>
Date: 30 Sep 88 12:29:56 GMT
References: <1959@spdcc.COM>
Sender: news@steinmetz.ge.com
Reply-To: dixon@control.steinmetz.ge.com (walt dixon)
Organization: General Electric CRD, Schenectady, NY
Lines: 28

We too have experienced this problem.  I've talked to several people at
Apple including A/UX support who could not believe that things like this
really happen. (Welcome to the real world).  This problem has cost Apple
sales at our site.  Loss of sales has finially got their attention (at
least on a local level).  I've promised to send a real time trace of
network activity off to the developers so they can try to duplicate the
problem.  Will it be fixed in 1.1?  I don't know.

I suspect that the problem originates with either busts of broadcast traffic
or bad packets.  Hopefully the trace will isolate the problem.  A/UX should
definitely recover from this condition;  no other devices on this ethernet
segment have shown similar behavior.

You can recover from this condition using ifconfig. "ifconfig ae0 up" will
bring the network back up; one can also write a program to turn the network
back on.  The problem gets more interesting when you have a NFS hard mount.
I tried to write a program which would run in the background,  catch a signal
that the network was done,  and turn the network on again.  This approach
seems reasonable,  but time constraints and a lack of Unix knowledge have
prevented completion.  I'm willing to give out the code I've got to anyone
who wants to get it working.  The only condition would be that, if you get
it to work,  you post it so others can use it.

Walt Dixon			{arpa:		dixon@ge-crd.arpa	}
				{us mail:	ge corp r&d		}
				{		po box 8		}
				{		schenectady,  ny 12345	}
				{phone:		518-387-5798		}