Subject: [netatalk-admins] Netatalk on an Ultra10

From: "Robert J. Marinchick" <[email-masked]>
Date: Tue, 11 Aug 1998 11:43:57 -0400

-- 
Hi,

I'm running netatalk-1.4b2+asun2.1.0-5 on a Solaris IPC and Ultra 10
both with the 2.6OS. When using the IPC,  "afpd" executes properly for
all Mac OSs.  However,  we're running into problems on the Ultra10.

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 restarted "afpd" with the -d option to see what debug info I
could obtain, only none showed. 

We're thinking that the problem may be with the "Streams" kernel.
I am using the "Streams" kernel included with Mr. Sun's prerelease.

If you have any ideas on what the problem/solution might be we'd
greatly appreciate hearing from you.

Thanks,

Bob

R. J. Marinchick			[email-masked]

When in doubt, ask yourself - W W J D?  "What Would Jesus Do?"

---

From: Michael M Han <[email-masked]>
Date: Tue, 11 Aug 1998 12:57:25 -0700

This appears to be something of an FAQ. Look at the AppleShare Client
Readme file for the version you installed. To summarize some ideas
offered in Readmes from various releases:

1) Upgrade to latest AS Client, v. 3.8
2) Toss your Macintosh HD:System Folder:AppleShare Prep
3) Zap your PRAM
4) Fiddle with your TCP Connect Timeout (managed using the AppleShare
Client Setup gotten from http://www.apple.com/appleshareip/)

There may have been other things suggested in the Readmes of other
versions of AppleShare Client. I'm assuming that you *can* connect via
an explicit IP request in the form "F.Q.D.N:port". If that's not the
case, there's something wrong with the TCP/IP support in your afpd,
probably misconfiguration. The AS Client uses ATalk to list known
hosts in the Chooser, but then tries to get an IP connection if the
server offers it. You can hold down Option while selecting the host to
force an ATalk connection to the server.

Previously...
>[snip]
>[snip]
_________
mike ([email-masked])
I will not sell school property
 - The collected wisdom of Bart Simpson

---

From: Sak Wathanasin <[email-masked]>
Date: Tue, 11 Aug 1998 23:55:53 +0100

In reply to Robert J. Marinchick's message of the 11/08/98 at 11:43 -0400,

> 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: [email-masked] (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: <[email-masked]>
>
> 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: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690