Subject: Re:[netatalk-admins] Netatalk on an Ultra10
From: Sak Wathanasin (sw@nan.co.uk)
Date: Tue Aug 11 1998 - 18:55:53 EDT
In reply to Robert J. Marinchick's message of the 11/08/98 at 11:43 -0400,
> Specifically, any Mac OS that doesn't have IP addressing capability
> can select the server from the "chooser". However, If IP capability
> is available, we can connect using the IP address, but we cannot
> select the server from the "chooser". In this case, we get an
> immediate message saying "Server not responding, please try later."
I've had this problem for months; various people on this list have suggested
disabling tcpwrappers and PAM, both of which I tried to no avail. I've come to
the conclusion that this is a problem on the MacOS side rather than netatalk
because
1) I've seen a couple of messages complaining about this behaviour with a
AppleShare IP server (an Apple ASIP server, I mean)
2) It works just fine with netatlk-asun18 on a client's Solaris box, but not
wth the same ver of netatlk on my Linux box (same Mac used in both tests)
3) When I installed AppleShare client 3.8
http://swupdates.info.apple.com/cgi-bin/lister.pl?Apple_Support_Area/Apple_Softw
are_Updates/US/Macintosh/Networking-Communications/AppleShare_Client/
the "no response from server" message goes away. However, it still doesn't use
IP to connect to netatalk - after mounting when I check (with "Get info") it
says it's connected via AppleTalk. If I manually click on "server address" and
type in the name of the Linux box (NB I don't even have to use a dotted IP addr
- DNS works fine), I can mount the netatalk volumes with ASIP just fine.
Oh, and I did throw away the AppleShare Prep file & other bits of voodoo - no
good. I'd sacrifice a chicken only I'm veggie; maybe a burnt offering of a
green salad?
Also I don't know if anyone's seen the following message in
comp.protocols.appletalk from the CAP developers. Does anyone know if netatalk
has this problem?
> From: djh@cs.mu.OZ.AU (David Hornsby)
> Newsgroups: comp.protocols.appletalk
> Subject: CAP asip.patch and AppleShare Client 3.8
> Date: 9 Aug 1998 22:44:58 +1000
> Organization: Computer Science, The University of Melbourne
> Lines: 29
> Message-ID: <6qk5ka$bfq$1@mulga.cs.mu.OZ.AU>
>
> Please be aware that if you are using CAP interim patches (asip.patch and
> extnd.patch), downloaded BEFORE August 7, WITH AppleShare Client 3.8 then
> you may experience a Finder crash with a divide-by-zero error. This will
> happen for volumes mounted via either AppleTalk or AppleShareIP.
>
> AppleShare Client 3.8 uses a bit recently added to the AFP 2.2 specification,
> this bit allows the Finder to find out the server allocation block size. CAP
> does not return a BitMapError for this bit (this has not been a problem in
> the past since the protocol version number was always incremented for new
> bit definitions). I believe that AppleShare Client version 3.8.1 may also
> contain a fix (not yet available).
>
> The asip.patch and extnd.patch files now available from munnari.OZ.AU
> and mirrors contain code to return BitMap errors when appropriate and to
> otherwise return the block size. See also the CAP AppleShareIP page at
>
> http://www.cs.mu.OZ.AU/appletalk/atalk.html
>
> for information on updating your current CAP sources. You can check for
> updated source files using
>
> grep VP_ALLOC cap60/netat/afp.h
>
> - David.
>
> David Hornsby
> Professional Officer
> Department of Computer Science "Home of MultiPort GW"
> The University of Melbourne, Parkville, 3052, Victoria, Australia.
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK
Internet: sw@nan.co.uk
Phone: (+44) 1203 419996 Fax: (+44) 1203 690690
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:04 EST