Subject: Re: abnormal disconnects

From: "Flint Million (netatalk)" <[email-masked]>
Date: Tue, 25 Sep 2001 09:48:21 -0500 (CDT)

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.

-Flint Million

---

From: Matthew Geier <[email-masked]>
Date: Wed, 26 Sep 2001 07:27:55 +1000

> 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.

---

From: Mark Guertin <[email-masked]>
Date: Tue, 25 Sep 2001 17:43:09 -0400

No need to have other programs request an IP first, the OS can do it for
you...

Go into the TCP/IP control panel on the mac, then into the options button
(make sure you are in advanced or administration mode), and make sure the
"load only when needed" in NOT checked and it should do a DHCP request at
startup when it initializes TCP/IP.

Mark

> From: Matthew Geier <[email-masked]>
> Organization: Arts IT Unit, Sydney University
> Date: Wed, 26 Sep 2001 07:27:55 +1000
> To: "Flint Million (netatalk)" <[email-masked]>,
> [email-masked]
> Subject: Re: abnormal disconnects
> Resent-From: [email-masked]
> Resent-Date: Tue, 25 Sep 2001 17:32:18 -0400 (EDT)
>

---

From: Matthew Geier <[email-masked]>
Date: Wed, 26 Sep 2001 09:03:39 +1000

> startup when it initializes TCP/IP.

 Doesn't help in this case, as AppleShare is the first 'application'
that needs TCP/IP. That option doen't force OpenTransport to load, it
just stops it unloading when it thinks its unneeded. We unset 'load only
when needed' as a matter of course when setting up machines.

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University