dplatt@ntg.uucp (Dave Platt) (03/28/91)
I spent most of yesterday afternoon installing CAP 6.0 on a
SparcStation-1 running SunOS 4.1.1. Our network environment is thin
EtherNet, with an updated FastPath-4 (K*Star) as a gateway to our
LocalTalk network. We had been running the Rutgers University version
of CAP 5.0 with great success.
My primary desire in this installation was to support Asynchronous
AppleTalk. I succeeded in doing so, but only after a fair bit of
frustration and knee-skinning took place. I hope that some of my
experiences will be of use to others (lest they have the same problems).
---
We had been running CAP 5.0 in an IPTalk configuration, as we've had no
need for EtherTalk (all of our Macs are on LocalTalk). However, with
the advent of CAP 6.0, I decided to switch our CAP libraries over to an
EtherTalk configuration, using UAB to support Async AppleTalk. [I could
have installed an EtherTalk UAB, and left the main CAP applications
running IPTalk... but this would have required Async AppleTalk users to
"bounce" their packets off of the K-box before they could talk to
IPTalk'ed CAP applications]. Our K-Star configuration file already
contained a network number and zone for the EtherTalk-1 network, so I
figured that everything would go smoothly.
Not so. I built the CAP libraries, UAB, and the application-suite using
the enet-filter configuration (I'd already installed the enetfilter
stuff in the kernel). UAB would start up, and would have no problem in
supporting CAP programs on the Sun... but I was absolutely unable to
contact the LocalTalk net from the EtherTalk net, or vice versa.
Figuring that the enetfilter code (4.0.3c) might be incompatible with
4.1.1, I rebuilt everything using the SNIT interface, reinstalled, and
tried again. Same results.
Running UAB in debug mode showed that it was never receiving any RTMP
packets (or anything else) from the FastPath. I checked the
configuration files, and everything appeared to be OK. I reset the
K-box and re-loaded K*Star 8.0.1; it still didn't work.
Finally, in a moment of disgust, I reset the Fastpath and then waited
until it auto-started the PROM packet-router ("be a bridge" mode). Lo
and behold, it started to talk to UAB... UAB seeded it with the
EtherTalk network numbers, ZIP'ed it, and I was able to talk between the
two nets.
I then reset the gateway again, loaded my old K*Star 7.0 configuration
file (apparently identical to the 8.0.1 config I'd been using),
downloaded K*Star 7.0, and started the gateway. Once again, it ZIP'ed
and RTMP'ed, and everything worked fine (including IP access). I
concluded that K*Star 8.0.1 was the guilty party, and went home for
dinner.
I phoned Shiva Tech Support today, and learned that K*Star 8.0.1 has an
interesting, poorly-documented quirk. If you want it to do EtherTalk-1,
then not only must you select AppleTalk-1 and fill in the network number
and zone... you must _also_ turn on Option 17. This is apparently
mentioned somewhere in the documentation, I guess... I wasn't able to
find it in the Readme file which came with K*Star 8.0.1 or in any of the
printed matter at hand. This will apparently be corrected in K*Star 8.1
or thereafter... the code will detect that you've specified an
EtherTalk-1 network and will Do The Right Thing.
I haven't reloaded K*Star 8.0.1 or updated my config file yet, and in
fact I may not bother to do so... we don't need EtherTalk-2 here.
To wrap up this phase of the excitement, I rebuilt the CAP libraries
using the enetfilter interface in place of SNIT, and reinstalled
everything. It works fine.
----
I found that it was necessary to start up both UAB and /etc/atis
_before_ the Sun portmapper starts up... otherwise, some of the
(not-officially-registered) ports used by these programs can be stolen
by the portmapper, and EtherTalk won't work correctly. I'll probably
split my /etc/start-cap-servers file into two files... one to start UAB
and atis at the beginning of /etc/rc.local, and another to start the
servers themselves somewhat later.
----
I was able to get the new Async AppleTalk capability to work, but I did
run into a few glitches. I've posted them off to the folks at munnari
(along with sincere thanks for such a useful contrib!) and reproduce
them here for your reading pleasure...
----
The installation instructions don't mention explicitly that AppleTalk
must be turned on from the Chooser before the "async" command is issued on
the Unix end. If this isn't done, the Async AppleTalk adev apparently
starts trying to shovel packets into a dead network environment on the
Mac... the symptom I saw was a jump-to-location-zero.
The login-window terminal emulator seems to swallow "%" characters (there's
one at the end of my normal shell prompt). A prompt of "dplatt% " was
displayed as "dplatt".
When running ASAT under System 7.0b5, it appears that the zone-list isn't
being handled correctly. The Chooser window never indicates the presence
of any zones at all. I infer that the Chooser in 7.0 may be using an
AppleTalk Level 2 service to acquire the zone list, rather than sending
ZIP packets to the nearest router (there was some mention of this technique
in the recent d e v e l o p magazine issue). Perhaps a LLAP driver has
to do some additional things in an AppleTalk Level 2 environment, such as
acquire the zone list itself and call back to the upper levels of the
stack to store this information?
The zone list appears to be handled quite correctly on the same Mac when
running System 6.0.7.
I had called up the AsyncTerm desk accessory [a REALLY neat idea]. I
noticed that the delete key sends a backspace (^H) character rather than
a DEL. I hit the "del" key on the separate keypad (ADB Extended keyboard)
to see if that would send a DEL... poof. The AsyncTerm window vanished
and the link became seriously confused... I was unable to establish a
replacement AsyncTerm session (the window would appear but was not
responsive to typing) and the AppleTalk link itself appeared to shut
down... the AppleShare session I had been using refused to respond,
and the AppleShare client eventually reported that the server had
disconnected.
Mac IIfx users must use the "Mac IIfx Serial Switch" cdev to place their
serial ports into "compatible" mode prior to starting up the connection
process. Otherwise, when the "async" command is issued, the AALAP
driver attempts to access the modem-port SCC registers directly, and
crashes due to a bus error.
----
That's about it. All of our standard services (lwsrv, papif, Aufs,
etc.) are up and running with no problems. I've also installed Timelord
on our Sparc (which recalibrates itself to NIST once per week) and have
seeded tardis onto most of our Macs). Now, when the Unix-based driver
for Broadcast arrives from Germany, we'll really be having fun...
--
Dave Platt VOICE: (415) 813-8917
UUCP: ...apple!ntg!dplatt
USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303