Subject: [netatalk-admins] Oy! Is this what you guys have been talking all about?

From: PayPC System Mail Subscriber <[email-masked]>
Date: Mon, 30 Nov 1998 13:05:40 +1000

The following is what I got by dragging a Metrowerks directory (80MB of 
stuff, including the IDE 2.0, plugins, MSL, and the includes & libs) from a 
local hard drive TO a netatalk volume:

Nov 29 21:27:47 quanta afpd[22871]: session from 41201.173:250 on 
65280.180:129
Nov 29 21:27:47 quanta afpd[22871]: randnum/rand2num login: nfsadmin
Nov 29 21:27:47 quanta afpd[22871]: login nfsadmin (uid 1011, gid 102)
Nov 29 21:38:28 quanta afpd[128]: asp_alrm: 22871 timed out
Nov 29 21:38:48 quanta afpd[22871]: 576.34KB read, 44337.20KB written
Nov 29 21:38:48 quanta afpd[128]: server_child[0] 22871 done

Quickie background: Intel Linux 2.0.33+ (security patches and MM fixes, 
mostly), netatalk preasun 2.1.0a was running at the time.  The area being 
written to was owned exclusively by the account used to login.  OS 8.5, ASIP 
3.8.1, yadayada, PowerMac 8500/120, normal 10BT.

As you can see, it got about 1/2 way thru the copy.  At a *ROUGH* guess, 
about 1.5-2 minutes.  The server "abruptly terminated service", killing the 
copy, and upon clicking STOP, the client machine with it.  OW.

So.  Is this the offending "crasher" I've been hearing about?  Also, judging 
by the log entry, this implies a tickle wasn't received or responded to.  But 
I'm 99.9% sure the xfer was proceeding fine.  Is the need for "tickling" 
obviated by the reception of data from the host?  (If not in "theory", then 
in practice?  I suppose I *could* install ASIP Server 6.x and ethernet sniff 
the wire and see how it deals with this... but it seems like the alarm has 
genuinely gone off, SIGTERMing the client's afpd.  This 1-2 minutes of time 
into the copy is also suspicious, since I know many ASIP timeouts default to 
this region...  For what it's worth, I posit the possibilities as follows:

1) the asp tickle (server->client) isn't sent properly during heavy i/os by 
netatalk
2) the asp tickle isn't received by the ASIP 3.8.1 client properly (or 
acknowledge timely enough).
3) the tickle isn't necessary during "demonstrated" i/o within the past 
tickle interval, because asip 3.8.x clients may not be able to respond to it 
properly during such times.

I'm sure I've DRAMATICALLY oversimplified many aspects of this complicated 
problem... however, in sniffing through the asp code, the only way that log 
entry fires is if a tickle's not responded to.

=Rob=