HDTenEightyP/NetNews huggingface dataset:
From: love@ruby.ora.com (Bill Love)
Newsgroups: comp.protocols.appletalk
Subject: Problem with CAP60-126 and aufs
Date: 16 Nov 92 19:37:11 GMT
Article-I.D.: ora.BxtqI0.L03
Organization: O'Reilly & Associates, Inc.

hi all-
	i've got a problem with cap and aufs that i'm sure is being
caused by some small mistake.  i've installed cap on a sun sparc
under sunos 4.1.2, and it connects to the net fine.  (something
which seems to not happen for many people after reading this 
group :-)   i was able to setup our appletalk printers as remote
printers under unix, this works well.  much better than going through
a G-box.  so i think the general library stuff is correct.

next i tried to setup aufs, this seemed to work but we quickly found
a minor problem.  any files copied to a unix "volume" could not
be removed by draging them in to the trash.  we get the following
error: You cannot move "somefile" to the "Trash", because it
cannot be moved into itself.  we have created both the .resource
and the .finderinfo files and all permissions seem to be correct.
this happens for both "unix" type files and mac files.

ok, so what have i done wrong?  sorry if this has been asked
before, i didn't see anything in the current set of articles
we have.
Newsgroups: comp.protocols.appletalk
From: yoko@research.nj.nec.com (Yoko Ozawa)
Subject: CAP6.0 pl126 with Sys7 and Sys6? (printer list problem)
Originator: yoko@research.nj.nec.com
Organization: NEC Research Institute
Date: Mon, 16 Nov 92 23:32:22 GMT

Hello, all you CAP experts out there !!!   :-)

After much debate, we decided to do the right thing and install CAP
for our Mac users.  The CAP is running on a Sun and everything seemed 
fine --                                                        ^^^^^^

	o Auf volumes can be mounted from the Chooser
	o With Sharing turned on, users can make his/her HD accessible
	  to the LAN from the Chooser
	o All the network printers we wanted to make available to Mac
          users are accessible from the Chooser and print without 
	  problems

Just what CAP is supposed to do!  We were elated and our System
Manager was ecstatic !  ... until we looked at the Chooser printer
list from a System 6.0.7 + System 7 printing.  (is this, by
definition, System 6.0.8?  I wish to differentiate because I didn't
use an official "System 6.0.8 Installer" but simply installed with
System 7 Printing Disk)

Instead of giving us a beautifully sorted printer list, the System 6
Chooser only provides a partial list (only 10 instead of ~20 printers)
in random order.

While I am responsible for Macintosh support here, this is my first
venture into the "Wonderful World of Networked Macs" at this scale.
Unix-side support is provided by someone-else ... although I'm
learning ;-)

Can someone tell me what is wrong here?  I'll provide some more
details on the Mac configuration  --

	o Each Macintosh OS and AppleShare is installed using the
	  6.0.7 installer disks
	o EtherTalk is installed using Network Products Installer v1.4
	  and EtherTalk Installer v2.0.1 (EtherTalk Phase 2)
	o MacTCP 1.1

If Unix-side information is needed, I'll get them.  Please (!!!) ask me.
	
Although the few System 7.0.1 users are happy as a clam with CAP, most
of our conservative users are running the above configuration.
General concensus is that they are willing to upgrade to System 7.0.1
if need be, but are concerned about compatibility and stability.  Many
are running experiments and (regardless of what they say) will NOT be
happy if things suddenly stop working.  :-<

I would appreciate any scrap of wisdom.

Thanks in advance!

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Yoko Ozawa             : NEC Research Institute, Inc.: yoko@research.nj.nec.com
Technical Administrator: 4 Independence Way          : 609 951-2511 (voice)
.......................:.Princeton, NJ 08540.........:.609 951-2480 (fax ).....

-- 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Yoko Ozawa             : NEC Research Institute, Inc.: yoko@research.nj.nec.com
Technical Administrator: 4 Independence Way          : 609 951-2511 (voice)
......................:.Princeton, NJ 08540.........:.609 951-2480 (fax ).....
Newsgroups: comp.protocols.appletalk
From: ycrdi@world.std.com (Young Chang RD Inc)
Subject: NetBridge/GatorBox:  Who dunnit?
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 19 Nov 1992 19:27:45 GMT

Hi, y'all.

Our network has a LocalTalk side and an Ethernet side, connected by a
Cayman Systems GatorBox CS.  The LocalTalk is divided into two nets by
a Shiva NetBridge.  Both LocalTalk nets are in "AppleTalk Zone."  The
default zone on the Ethernet side is "Ethernet Zone," but there's also
an "AppleTalk Zone" on the Ethernet wire.  Okay, here's the problem.

Nodes on the far side of the NetBridge can't see in their Chooser devices
that are hooked up to Ethernet wire but are in "AppleTalk Zone."  This is
because of the following phenomenon:  Whenever an NBPLkUp (xxx:yyy@*) is
sent to the NetBridge, the NetBridge sends an NBPFwdReq (xxx:yyy@*) to the
GatorBox as expected.  The GatorBox, however, ignores it with a "bad packet"
diagnostic message.  The GatorBox should instead be transmitting an NBPLkUp
(xxx:yyy@AppleTalk Zone) on the Ethernet side, right?

Now, whose fault is it?  Are the packets really bad or is the GatorBox
broken?

Is there any product or tool anyone can recommend to determine which
is true?  Currently, my network arsenal is limited, but it has been
sufficient in the past.  I can see packets on LocalTalk, but not on
Ethernet.  The only way I know what's happening on Ethernet is by
looking at LocalTalk data.

Has anyone had any similar experiences with either product?

Any help would be greatly appreciated.

Thanx,
-TimK
-- 
Tim King / Network Manager
Young Chang R&D Institute
ycrdi@world.std.com
timk@world.std.com
-- 
Young Chang R&D Institute                       Makers  of         <>
ycrdi@world.std.com                   |\   Kurzweil Music Systems  | >
Voice: (617) 890-2929                 | >        Technology        |/
  Fax: (617) 890-2014                <>
Newsgroups: comp.protocols.appletalk
From: skl@wimsey.bc.ca (Samuel Lam)
Subject: Re: Can UAB perform functions of AIR?
Reply-To: skl@wimsey.bc.ca (Samuel Lam)
Date: Thu, 19 Nov 1992 00:17:43 GMT

In article <9211171822.AA09139@hawaii.dcs.gla.ac.uk>, inei@dcs.gla.ac.uk
 (inei) wrote:
>Can UAB perform the functions of AIR in the following network setup?

The answer is yes if your network is still running EtherTalk Phase 1.

If you have upgraded to EtherTalk Phase 2, then the answer is not yet.

...Sam
-- 
<skl@wimsey.bc.ca> -- Connectivity Technology Inc.
Newsgroups: comp.protocols.appletalk
Subject: Re: papif+fastpath5+postscript2 printer problem
From: tom@wcc.oz.au (Tom Evans)
Date: 22 Nov 92 12:24:55 GMT
Organization: Webster Computer Corp, Melbourne, Australia

In article <1992Nov17.154822.4182@cuug.ab.ca>, adachir@cuug.ab.ca (Rob Adachi 297-3607) writes:
> >
> >I've had problems with two QMS printers connected to our LocalTalk
> >network (a QMS 1700 we had on trial, I believe, and a QMS 860).  The

> 	We had the exact same problem with the QMS 860 and 1700. 
> 
> 	Tom Evans, (thanks Tom) suggested that I try turning the DDP checksums
> off on the CAP 60 software to get the QMS 860 printing to work.

Something ELSE to look out for. Two sites here in Australia have had
problems with another third-party "Apple-compatible" Laser printer.
It seems that it doesn't like to be on large AppleTalk Internets -
it fails if the SIZE of the RTMP packets on the network contain "too
many" network tuples. Anybody else seen this one?

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179  A.C.N. 004 818 455
From: rich@pencil.cs.missouri.edu (Rich Winkel)
Subject: Need help configuring atalkad
Organization: University of Missouri
Date: 16 Nov 92 22:42:57 GMT

I recently downloaded version 1.25.  It looks like just what I need,
but the documentation makes no sense to me!  There's no atalkatab.5
file either.
Could one of you net gurus help me out?

Pretty pleeeeeeze?

Rich
Newsgroups: comp.protocols.appletalk
From: Steve Bollinger <buzz@apple.com.>
Subject: Re: RTMP question
X-Useragent: Nuntius v1.1.1d12
Date: Mon, 16 Nov 1992 22:40:57 GMT
X-Xxdate: Mon, 16 Nov 92 22:42:09 GMT
X-Xxmessage-Id: <A72D63C17B013847@pyd.apple.com>
Organization: Apple Computer, Inc.

In article <1e605dINN44o@roche.csl.sri.com> David Stine, dstine@cisco.com
writes:
>It is also possible that collisions can take out RTMP update packets
after
>they have been sent by the router. This is somewhat less likely.

AppleTalk was designed to run on LocalTalk, which has no collision
detection. Losing RTMP packets on LocalTalk is not a terribly rare
occurance. So any good implementation should have no problems with
lost RTMP packets.

>
>>My question comes up because if I sit at the console of the Novell print
>>server and watch the RTMP table, the next hop route to any given IP
site is
>>doing a 'musical chair routine' among the 30 some FastPaths.  Every 10
>>seconds or some the next hop changes nodes on the ethertalk segment!

You probably don't mean IP here. Or maybe you don't mean RTMP. What do you
mean?

>Well, this is something of an open area in the AppleTalk end-node design.
>Implementors who follow "Inside AppleTalk" to the letter will have their
>designated router possibly switch with every incoming RTMP packet. Please
>refer to pp. 5-18 and 5-19 in "Inside AppleTalk", 2nd. Ed.
>
>Some would say that this is a nuisance in AppleTalk, that it confuses the
>issue of trying to figure out where your traffic is going and why. These
folks
>tend to come from the IP world, where you either tell a Unix host to
>(statically) designate a default route to a router for all traffic or
you are
>running a routing protocol which tends to "lock on" to a path.
>
>So there are some AppleTalk end-node implementations which tend to stick
with
>the first router they hear as the value for A-ROUTER until they quit
hearing
>said router, at which time they pick another router on the cable.
>
>Then there is the flip side of the coin: by switching the value for
A-ROUTER
>with every update, you effect a sort of "load sharing" between the
routers
>present on a cable.
>
>Which is better? I'm sure we can find arguments in favor of both.

Actually, it doesn't really matter much which you do, as long as you
implement
the "Optional best-router cache" described on Inside AppleTalk (V2) p
4-20.
All but the most rudimentary of network devices should be able to
implement
this cache. If you do this, then the only thing A-Router does for you is
tell you where to send your NBP requests.

-Steve
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Newsgroups: comp.protocols.appletalk
Subject: Re: looking for CHEAP Mac ethernet cards
Date: 17 Nov 1992 03:34:07 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: decel.ecel.uwa.edu.au

jeffc@comb1.comb.umd.edu (Jeff Clowser; IRG) writes:

>Our price at U of MD for an Asante card is as low as $125, I believe.  I've
>never had a problem with one.

I installed some Asante LC ethernet cards with the 4.0 driver that shipped
with them.  I had several occasions where they just locked the machine up
and flooded the ethernet with traffic.  I verified this by looking at the
activity light on another machine.  I ftp'd the 4.1 drivers and installed
them and have had a lot less problems since and haven't flooded the network
with traffic once :-).  They seem to be working fine now.  I've only had a
couple of lockups since and I'm not sure that the cards are at fault for
those.

Craig

--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au Dvorak Keyboards RULE!  "Messes are only acceptable
if users make them.  Applications aren't allowed this freedom" I.M.VI 2-4
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.protocols.appletalk
Subject: Re: CLAIM: Seed Routers are not Nodes
Date: 21 Nov 92 01:17:30 GMT
Reply-To: andrew@frip.wv.tek.com
Organization: Tektronix Color Printers, Wilsonville, Oregon

>>>winders@aux.support.apple.com (Scott Winders) writes:

... but Scott didn't write what follows.  Darryl got the attribution wrong.

> Any router, once running, becomes a SEED router.

Let's please not redefine Apple's terminology?  From the "Inside
AppleTalk #2" glossary:

	"seed router: an internet router in an AppleTalk network that
	has the network number range built into its port descriptor."

By this definition, non-seed routers do not transform into seed routers
once the net comes up, because their network number ranges do not
become built-in.

  -=- Andrew Klossner  (andrew@frip.wv.tek.com)
                       (uunet!tektronix!frip.WV.TEK!andrew)
Newsgroups: comp.protocols.appletalk
From: maarten@fwi.uva.nl (Maarten Carels)
Subject: Re: CAP access from home?
Organization: FWI, University of Amsterdam
Date: Fri, 20 Nov 1992 08:45:57 GMT

puetter@pe.chalmers.se (Johan Puetter) writes:
>We have a CAP AFP-server at work. When I'm working at home I often need
>access to our university network, so I successfully use MacSLIP to login.
>The only thing I really miss is a convenient access to the CAP volume.

>As I see it there are two possible ways to do this:

>2) Some program that would let my home Mac connect to the CAP volume with
>   AppleTalk (i.e. the normal way it's done when I'm at the university). This
>   would be the prefered way I guess.

CHeck out the arns package, available from munnari.oz.au.
It will allow you to:
either connect to the appletalk network by a async serial line
or use an existing IP connection (such as SLIP)

(I've no experience with it yet, I'm installing it now)

--maarten
-- 
In real life:	Maarten Carels
		Computer Science Department
		University of Amsterdam
email:		maarten@fwi.uva.nl
Newsgroups: comp.protocols.appletalk
From: djh@cs.mu.OZ.AU (David Hornsby)
Subject: Re: MacTCP over Async Appletalk
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 17 Nov 1992 13:57:45 GMT

Anders.Liljegren@udac.uu.se (Anders Liljegren) writes:
>Is there anyone who had managed to this to work? How do you set it up?
>Should I select the Async icon in the MacTCP dialog box? Is there some
>other requirement?

It works fine here, the key is to have an external gateway such as a
FastPath, GatorBox or MultiPort Gateway that is configured to handle
static or dynamic IP addresses on the *EtherTalk* interface. This is
not usually the default setting since Macs with an Ethernet card are
usually configured to use MacTCP directly via Ethernet rather than
via EtherTalk.

 - David.
Newsgroups: comp.protocols.appletalk,comp.sys.mac.comm
From: gi@pc-labor.uni-bremen.de (Gerald Imboden)
Subject: Need Help For AIX+CAP+LWIIg+PC/NFS
Organization: University of Bremen, pc-labor
Date: Mon, 23 Nov 1992 16:29:51 GMT


Hello netfolk,

we try to install an Apple LaserWriter IIg in our network. The network
consist of a RS6000 under AIX3.2, a few PC`s under DOS+PC/NFS and two 
Quadras. All these maschines should use the LW.
We thougth about using CAP. Is there an ENET driver for AIX or a possibility
to use native ethertalk?
Anybody out there with a solution are any hints?

Thank you,
Gerald
From: kai@pyrite.SOM.CWRU.edu (Kai Getrost)
Newsgroups: comp.protocols.appletalk
Subject: Extended- vs. nonextended-net net range aging
Date: 22 Nov 92 23:43:34
Organization: WSOM CSG, CWRU, Cleve. Ohio
Distribution: comp
NNTP-Posting-Host: pyrite.som.cwru.edu


   I'm implementing Phase II AppleTalk on a 386 using packet drivers,
and I've come across a minor but confusing inconsistency in the
protocol spec.  A little background info first (to be sure I have
things straight):

   A node determines the net number (net range for extended nets) of
the local link it is on by listening to RTMP Data/Response packets and
copying the sender's net (range) number(s), and the sender's node
(net:node) as the ID of a router to use.  Inside AppleTalk calls these
values THIS-NET and A-ROUTER, respectively.  A-ROUTER is updated every
time an RTMP Data packet is received, so its value may change
continually (since any router will do).

The problem: 

   Inside AppleTalk (2nd ed.) gives slightly different algorithms for
expiring THIS-NET on extended vs. nonextended nets.

   On nonextended nets, it says (p. 5-18/19) that the value of
A-ROUTER and THIS-NET are gleaned from every RTMP Data packet
received.  If no RTMP packets are received for 50 seconds, A-ROUTER
should be expired (set to 0), but *not* THIS-NET.
  On extended nets, however, it says that *both* A-ROUTER and THIS-NET
should be reset when the aging timer expires.

  In other words, nodes on nonextended nets will save their link's net
number if all routers go down, but nodes on extended nets are supposed
to reset theirs (and set them again once RTMP packets are received
again, possibly to a new value).  Why do these algorithms differ?
   The benefit of expiring the net range on extended nets could be
that you can reconfigure the net range by taking down just the routers
for some minimum time, and then bring them up with a new value that
all nodes will (hopefully) adopt.  But this will affect any current
connections non-router nodes have, as they change to the new net range
and adopt new net:node IDs, and Inside AppleTalk is nebulous as to
when and how these connections should be reset (since it's a rare
occurence and difficult to deal with effectively).  
   And why not have nonextended-net nodes expire their net #'s as
well, so their link's net # can be changed in the same way?  It's a
minor point, and I may be reading too much into it, but I'm curious as
to why this inconsistency exists.


-Kai
kai@pyrite.som.cwru.edu




--
"...adventures into the esoteric              |        Kai Getrost
 periphery of the C shell may reveal          |            ---
 unexpected quirks."                          | kai@pyrite.som.cwru.edu
                 -- SunOS 4.1 csh(1)          | kai@b62624.student.cwru.edu
Newsgroups: comp.protocols.appletalk
From: saile@brutus.sns.neuphilologie.uni-tuebingen.de (Jochen Saile)
Subject: Access to laserwriters
Organization: sns
Date: Thu, 19 Nov 1992 10:02:53 GMT

Hi,
 
I have the Problem, that it is unwanted, that every Mac on a ethernet
has access to a Laserwriter. To document this it would be nice, to have
the group of macs which are allowed to print, in a Appletalk zone and the
other macs in another zone.

My questions are:

1.) Is it possible to limit the access to a laserwriter to a set of Macs.

If it is possible:

2.) What hardware/software is necessary to exclude machines.

3.) Is it possible to establish more than one Appletalk zone on a single
    ethernet wire. Inside Appletalk is talking a lot about routers, so my 
    first impression was, that it is only possible between different network
    segments. 

If it is possible:

4.)  What hardware/software is necessary to establish more than one zone.

Thanks in advance 

	Jochen
From: drg@biomath.mda.uth.tmc.edu (David Gutierrez)
Newsgroups: comp.protocols.appletalk
Subject: Re: NetBridge/GatorBox:  Who dunnit?
Date: 19 Nov 1992 23:36:28 GMT
Organization: Univ. Texas M.D. Anderson Cancer Center

In article <BxzA2A.1HJ@world.std.com> ycrdi@world.std.com (Young Chang RD Inc)
writes:
>Our network has a LocalTalk side and an Ethernet side, connected by a
>Cayman Systems GatorBox CS.  The LocalTalk is divided into two nets by
>a Shiva NetBridge.  Both LocalTalk nets are in "AppleTalk Zone."  The
>default zone on the Ethernet side is "Ethernet Zone," but there's also
>an "AppleTalk Zone" on the Ethernet wire.  Okay, here's the problem.
>
>Nodes on the far side of the NetBridge can't see in their Chooser devices
>that are hooked up to Ethernet wire but are in "AppleTalk Zone." 
>
>Now, whose fault is it? 

I'd guess that it's the GatorBox.

We have a similar setup here, except that we use a FastPath instead of a
GatorBox. The only time anyone's had any trouble like you mention was when we
had IPT's uShare on a Unix box. (We've since replaced it with EtherShare.)

David Gutierrez
drg@biomath.mda.uth.tmc.edu

"Only fools are positive." - Moe Howard
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.protocols.appletalk
Subject: Re: Locks, CAP, and NFS Patches
Date: 17 Nov 1992 00:36:28 GMT
Organization: University of Oregon Network Services
Distribution: world
NNTP-Posting-Host: duff.uoregon.edu

cory@hobbes.sanders.lockheed.com (Cory Myers) asks about:

        NFS
                In some circumstances, CAP AUFS using NFS mounted
                filesystems may complain about files being locked when
                they are not obviously so.  Ensure that you have the latest
                NFS bugfixes for your UNIX platform.
        
For SunOS 4.1.1 you need at least the "rpc.lockd jumbo patch", 100075-06. 
I believe you need to install it on both the NFS server and the CAP
server/NFS client.  You may also need to apply the NFS Jumbo Patch,
100173-09. 

It is claimed that the rpc.lockd patch is incorporated in 4.1.2 and 4.1.3.
However, I still am unable to get CAP to work on NFS-mounted filesystems
under 4.1.3 with locking enabled even with the NFS Jumbo patch installed. 
If anyone has any luck in doing so, could you email me so we can compare
notes?


JQ Johnson				Office: 250E Computing Center
Director of Network Services		Internet: jqj@ns.uoregon.edu
Computing Center, Univ. of Oregon	voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.protocols.appletalk
Subject: Re: Extended- vs. nonextended-net net range aging
Date: 23 Nov 92 19:08:30 GMT
Reply-To: andrew@frip.wv.tek.com
Distribution: comp
Organization: Tektronix Color Printers, Wilsonville, Oregon

[]

	"A node determines the net number (net range for extended nets)
	of the local link it is on by listening to RTMP Data/Response
	packets ..."

Actually, the recommended way for a node on an extended net to get this
info is to broadcast a ZIP GetNetInfo.  See page 5-19, IA#2.  It's not
wrong to use RTMP, but ZIP GNI gets you the info right away and also
tells you whether your zone name is valid.

(On a non-extended net, you can start operations before you know your
network number, so waiting until the next RTMP isn't an inconvenience.
On an extended net, you can't start operations until you know your
network number range or have established that there is no router.)

	"A-ROUTER is updated every time an RTMP Data packet is received
	..."

Consider implementing the optional "best router" algorithm, page 4-20.
It's a major win on big networks.  We have a big network, and the major
cause of packet loss is router congestion.

	"nodes on nonextended nets will save their link's net number if
	all routers go down, but nodes on extended nets are supposed to
	reset theirs (and set them again once RTMP packets are received
	again, possibly to a new value).  Why do these algorithms
	differ?"

On an extended net, you cannot accept a packet from a node on your
network if the source network number falls outside THIS-NET-RANGE.
(Because you can't reply to it, because your transmit algorithm would
try to route the reply to another network.)  If the last router
disappears and then a non-router node comes up, it could choose any
network number (depending on what net it was on when it powered down).
Once you set THIS-NET-RANGE to [0..FFFE], you can accept packets from
that node.

On a non-extended net, if the last router disappears and then a
non-router node comes up, it will use network number 0.  You accept
packets from network 0 regardless of the value of THIS-NET, so it's not
necessary to reset THIS-NET.  More important is the fact that this is
how things were defined before anybody thought about extended networks,
and this is how the LaserWriter ROMs behaved.  The cardinal rule in
defining extensions to AppleTalk is:  don't invalidate the LaserWriter
ROMs.

  -=- Andrew Klossner  (andrew@frip.wv.tek.com)
                       (uunet!tektronix!frip.WV.TEK!andrew)