Subject: Re: abnormal disconnects
From: Matthew Geier (matthew@arts.usyd.edu.au)
Date: Tue Sep 25 2001 - 17:27:55 EDT
"Flint Million (netatalk)" wrote:
>
> On Mon, 24 Sep 2001, David J. Topper wrote:
>
> > I've had this happen too. In my case, it had to do with the DHCP lease
> > time on the given Mac. If you can change that on your DHCP server, that
> > would be one way to check. Otherwise see if a static IP solves the
> > problem.
> >
>
> I can check the DHCP settings, but I think I have it set for 2-day
> leases. The DHCP is running on the same Linux box as netatalk - problem
> there perhaps? I can give the Mac a static IP as well if it would help.
I run 24 hr leases on several hundred Macs and don't have wide spread
abnormal disconnect problems. I've actually snooped on several Mac's.
They will not disconnect on lease renewal if the server will let them
keep their existing IP. (We had 'pausing' problems on Imacs which our
support people attributed to DHCP renewals, however no network 'event'
corresponded to the system pauses, and DHCP renewals were 'unseen' by
the users).
If you are running something like ISC dhcpd, it will try its hardest
never to change the address on a client, if the address pool is big
enough so that the server didn't need to start reusing addresses, a
client machine could come back months later, and ISC DHCP will look up
its history and give the machine the same IP address it had before.
What I have found however, if a 8.6 machine connects with AppleTalk
instead of IP, it will disconnect with in five minutes, even while
trying to copy files. (Note this may still apply to 9.x and back to 8.1.
Haven't fully tested it).
If a non ASIP client connects with AppleTalk, say system 7.5.1, it can
stay connected as long as it likes with out disconnecting, so its not
AppleTalk as such.
What I suspect was happening, was the clients concerned had 'reconnect
at start-up', so early in the process, the machine would stop, connect
to the server and demand the password for the share. All well and good.
However it appears if this is the first system application to need the
IP stack, OpenTransport has to load and do a DHCP discover, acknowledge
cycle to obtain its IP address. Looks like the AppleShare client can't
be bothered waiting for this process to complete, decides IP is
unavailable and makes the server connection with AppleTalk. When the
client gets disconnected some time later and they try to reconnect to
the server, OpenTransport is loaded and already has its IP address, so
an ASIP connection is made and all works perfectly from then on.
Our solution was to make something else need IP before the AppleShare
client needed it. We run 'keyserver' to control concurrent licences. It
loads before AppleShare. Setting the keyserver control to use IP to
contact the keyserver instead of AppleTalk 'fixed' the problem. The
keyserver control is prepared to wait for OpenTransport to load and
obtain its address. We see the boot process stop briefly when the
keyserver control loads and 'grows legs' (Which indicates it 'logged in'
to the keyserver), then AppleShare loads, the user gets the password
prompt, they login with ASIP and all works perfectly.
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:53 EDT