Subject: Re: abnormal disconnects
From: Mark Guertin (mark@artshouse.com)
Date: Tue Sep 25 2001 - 17:43:09 EDT
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 <matthew@arts.usyd.edu.au>
> Organization: Arts IT Unit, Sydney University
> Date: Wed, 26 Sep 2001 07:27:55 +1000
> To: "Flint Million (netatalk)" <netatalk@millions.linux-site.net>,
> netatalk-admins@umich.edu
> Subject: Re: abnormal disconnects
> Resent-From: netatalk-admins@umich.edu
> Resent-Date: Tue, 25 Sep 2001 17:32:18 -0400 (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