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, -pwas 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