Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!JOLT.COLUMBIA.EDU!cck
From: cck@JOLT.COLUMBIA.EDU (Charlie C. Kim)
Newsgroups: comp.protocols.appletalk
Subject: Having problems with KFPS/Kip/Cap
Message-ID: <8707271439.AA22567@columbia.edu>
Date: Mon, 27-Jul-87 10:36:55 EDT
Article-I.D.: columbia.8707271439.AA22567
Posted: Mon Jul 27 10:36:55 1987
Date-Received: Tue, 28-Jul-87 02:46:04 EDT
References: <2818@phri.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 61

The FastPath(tm) Manager is the new release of the Prompt program from
Kinetics.  It still doesn't "know" about the KIP code.  If there is
bogus info in the dialog boxes, ignore it.

You only need to put the ip addrs etc, in your hosts file if you plan
to reference the ip addresses by name.  In general, it is a good idea.

papif is poorly documented.  The problem was that in some version of
lpd that we had, -p  was passed (for once I wasn't guilty
of making this change).  To get around this problem, you can do:
	(a) papif takes the program name (argv[0]) as the "-p" argument now
	if it isn't "papif".  Thus, if you make a symbolic or hard
	link (or copy it), then you can "pass" the "-p" argument that
	way.  For example, if you have a unix printer ps8, then
	"ln -s papif ps8" and make ":if" in /etc/printcap point to "ps8".
	Unfortunately, you have to do this for every unix printer (each
	entry in /etc/printcap).
	(b) create a shell script (for each printer), that does:
		"exec papif -p xxxx"
	where xxxx is the unix printer name.

Debugging: it's not uncommon for people running KIP to find out that
the IP code works while the appletalk code doesn't.  The reason is
that the configuration required for the IP side is much simpler
(almost nil).  Most of the configuration in /etc/atalkatab is for
AppleTalk.  When something goes wrong, I've usually found it to be one
of the following:
	(a) incorrect mappings in /etc/atalk.local.  For hosts on an
ethernet, you should be careful to map the last byte of the ethernet
address to the appletalk node number.  For instance, here the vax is
at ip address 192.9.200.150.  192.9.200.* maps to the appletalk
network 55.1, so the vax's atalk addr should be: net: 55.1 node: 100
(while there is no absolute reason why this should be as it is, the
reason it has to be is: some of the KIP code assumes that it so).
The bridge node is 192.9.200.150, so its ethernet appletalk address
should be: net: 55.1, node: 150.  The appletalk cable has been
assigned net 56.1, so the bridge's appletalk address should be net:
56.1, node: 220 (note: you really shouldn't use the appletalk side
appletalk address since the node numbers on the appletalk side cannot
be considered to be static).  Thus Phri's atalk.local really should
have been:
	55.1 100 PHRI-AT
	55.1 150 192.9.200.150
The reason that you must specify the bridge IP address is that the CAP
code no longer does any routing on its own (releases previous to 4.00
did)--instead it depends on the kfps to do all the work.  The IP
address allows it to route the first pkts properly.
	(b) The second reason things usually fail is because the
broadcast addresses cause problems.  Generally, you can get around
this problem by using "atalkrd" from the KIP code.
	(c) what you should see.  If you have ethernet monitoring,
then run look (assuming vax is the CAP host) and you should see:
	(1) udp pkts from vax to kbox (nbp br lookup).
	(2) udp broadcast pkts from kbox: (nbp lookup)
	(3) udp pkts from ? to vax (nbp replys) 
Assuming the KIP code is up and running, if you don't see (2), then
your atalk.local or atalkatab is probably incorrect.  If you don't see
(3), then your atalkatab is wrong or you don't have any names
registered on your network.

Charlie2