IN10@UDESVM.BITNET (Denis Beauchemin) (08/16/90)
Hi,
I just got my hands on cap.etalk from Rutgers. I installed it without
any problems on our Suns but I couldn't get any of them to see anything
on the Mac side using atlook.
I already had cap50 installed on one of the systems and it could see the
Mac devices. I tought that cap.etalk was just an extension to the current
CAP that gave it the possibility to see EtherTalked Macs AS WELL as the
LocalTalked ones. Am I wrong?
I also couldn't find any reference to the /etc/etalk.local file. Is it
just a copy of the /etc/atalk.local or what?
FYI I am using a GatorBox as a gateway and our Suns are running SunOS 4.0.3
and 4.1. They can currently print on any laser on LocalTalk, and the Macs
can use their accounts on the suns via AppleShare-Client.
Thanks for the help,
--> Denis Beauchemin, Analyste --> IN10@UDESVM.BITNET
Departement de mathematiques (819) 821-7022
et d'informatique
Universite de Sherbrooke
PS: I don't have any EtherTalked Macs right now but I should receive 2
Asante cards within days...hedrick@athos.rutgers.edu (Charles Hedrick) (08/18/90)
The newest version of my CAP Ethertalk support has documentation,
which might help with setting up /etc/atalk.local. (There is no
/etc/etalk.local. That seems to be part of UAB.) It may be that the
code doesn't do what you expected. It will indeed support either
IPtalk or Ethertalk, but not at the same time. The basic problem is
that to do that you need a system that has two different network
addresses, one on each network, and the basic CAP software doesn't
seem to be set up to handle this case. That's what UAB is for. So
for my code you have to choose whether you want IPtalk or Ethertalk.
From your description it sounds like you've got a Unix machine on an
Ethernet and some Macs and a printer on Localtalk, with a Gatorbox
connecting Localtalk to the Ethernet. In that case, if you switch
from IPtalk to Ethertalk on your Unix machine, the Gatorbox may need
to be configured differently. Instead of connecting Localtalk to
IPtalk, it now needs to connect Localtalk to Ethertalk. And its
Ethertalk needs to be configured for phase I.
If this is true and you are still not getting anything through, I am
going to suspect a problem in my RTMP listener. During debugging I
noticed one router that produced odd-looking RTMP packets. Since they
seemed bogus according to Inside Appletalk I added a test to eliminate
them. It could be that there's something wrong. First, try running
atis with a debug level of at least 7. i.e. "atis -D 7" You should
see messages of the form
log(7, "Got RTMP pkt net %d from %d.%d", net, addr->net, addr->node);
If you don't then either there is a gross failure in the code or
configuration, or your Gatorbox isn't talking Ethertalk on that
Ethernet. If net and addr->net are not the same, the current code is
going to ignore that router. If the only router you have is that way,
then obviously we're going to have trouble with your network. If this
is the case, look at the next couple of lines, which are
if (net == addr->net)
SetMyAddr(addr);
Remove the if, so that the SetMyAddr is done unconditionally. That
should work for the moment, until I figure out what to do. Please
tell me whether this resolves your problem. My reading of Inside
Appletalk is that these two numbers had been agree, or there's
something very wierd about that RTMP packet.rapatel@khnphwzhn.njin.net ( Rakesh Patel) (08/18/90)
The ethertalk version of CAP uses UAB to "bridge" to Ethertalk, so a bridge description file needs to be set up and uab needs to be running before the Ethertalk version of CAP runs. The reason I set the distribution up to use /etc/etalk.local instead of /etc/atalk.local was so that it would be easy to test with and convert to the Ethertalk based CAP with the ability to easily go back to the IPtalk based mechanism if things failed. For your current problem, you need to create an empty /etc/etalk.local before running UAB, and provide the network and zone info in the bridge description file. When you run UAB, it will add the correct information into /etc/etalk.local for the Ethertalk based CAP library applications to run. You should make sure that the etalk.local actually contains the appropriate information after you start up uab. It should use the loopback interface for communicating with CAP applications. This distribution will be obsoleted soon. The version Charles Hedrick is working on to use the Berkeley enet packet driver instead of the NIT driver is being readied. This version will run either IPtalk or Ethertalk based upon the information format provided within /etc/atalk.local. I believe he has also made it so that it can use the NIT driver for those who need that capability. There will be a few more bug fixes added as well. I may add in the PC support for AUFS for the new release. If anyone has additional bug fixes that are not in the Rutgers distribution that they would like to see incorporated into the new version, they should send them to me soon. Rakesh Patel.
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (08/18/90)
Woops, I hadn't read your message carefully. No, the cap.etalk distribution does not talk both IPtalk and Ethertalk simultaneously. The cap.etalk distribution only uses EtherTalk by being "bridged" through UAB. If you have Ethertalk enabled on the Gatorbox, you will be able to see that network using atlook by sepcifying the appropriate zone name. The Gatorbox will be bridging the IPTalk and Ethertalk. If you have the Sun running CAP on the same ethernet as the Macintoshes and Gatorbox, you can run the cap.etalk distribution and use UAB to have it use Ethertalk. Then the Macintoshes can communicate directly with the CAP services. If you enable Ethertalk support on the Gatorbox, then it will bridge the localtalk devices/services to the Ethertalk devices/services (Macs on Ethernet and Ethertalk version of CAP). See the other followup message I sent on information about the problem you have running it. I also mentioned in the other message that the Rutgers cap/cap.etalk distributions will be replaced with on Rutgers cap distribution that will allow configuration for either Ethertalk or IPtalk (not both simultaneously). Rakesh Patel.