Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!panix!alexis
From: alexis@panix.UUCP (Alexis Rosen)
Newsgroups: comp.protocols.appletalk
Subject: Re: Does AppleTalk checksum packets?
Message-ID: <898@panix.UUCP>
Date: 14 Feb 90 10:42:11 GMT
References: <1990Jan27.015510.6906@phri.nyu.edu>
Reply-To: alexis@panix.UUCP (Alexis Rosen)
Organization: PANIX - Public Access Computer Systems of NY
Lines: 32


I haven't seen any resonses to Roy's posting yet, so here's mine...

From my once-broad and now hazy knowledge of AppleTalk protocols, I would asy
that this is impossible.  Except-

I seem to be seeing this myself. In particular, on a dedicated AppleShare
server servicing AFP calls from multiuser databases, I've seen database records
get trashed, so that they look like full 8-bit ASCII garbage. I've seen this on
two separate networks, one LocalTalk, and one mixed LocalTalk/EtherTalk. It
seems to occur more on the mixed network (dozens of bad records instead of
three, across a three-week period). I can't believe that the database is
responsible for this.  If it were writing stuff out of a bad pointer in
memory (the only way the DBMS could be responsible, I think), I wouldn't
occasionally see a dozen or so bytes or good data mixed in with the bad. It is
possible (though not confirmed) that the damaged records were the subject of
AFP locking contention.

While this doesn't match Roy's experience directly, the nature of the garbage
seems the same.

Can there actually be a bug in the AppleTalk drivers (which occurs rarely)
which fails to assemble packets correctly? I know this is _really_ farfetched,
but what else could it be??? I don't see how it could bit a bit-shift error,
since I think the SCC handles that in hardware (and certainly EtherNet does),
but that's what it seems to look like.

Mystified,
Alexis Rosen
sysadmin, Panix
alexis@panix.uucp
{apple,cmcl2}!panix!alexis