roy@phri.UUCP (Roy Smith) (07/26/87)
I'm trying to set up a Kinetics KFPS-2 using kip/cap. I have:
Vax-11/750, MtXinu 4.3/NFS, Micom/InterLan NI-1010A ethernet card
KFPS-2 on a DEC DELNI
CAP version 4.00 with pat5.shar patches installed
KIP version 0287 (actually not sure; the HIST file says 0287
but I got a new gw.srec from sumex-aim a few days ago).
Macintosh Plus (with new, ugly, case coloring :-))
Here's my various config files:
atalk.local:
----------------
# mynet mynode myzone
55.1 100 PHRI-AT
# bridgenet bridgenode bridgeIP
55.1 220 192.9.200.150
----------------
atalkatab:
----------------
# Appletalk administration database table (atalkatab),
[lot's more comment lines]
55.1 N1 192.9.200.0 PHRI-AT # PHRI AppleTalk
56.1 KC 192.9.200.150 PHRI-AT # K-Box #1
I192.9.200.255 I192.9.200.100 # ipbroad ipname
I192.9.200.100 L0 # ipdebug ipfile
L0 L0 L0 L0 S0 S0 # ipother unused unused
LX0 S2 S6 # flags ipstatic ipdynamic
S56.1 S55.1 "PHRI-AT" # atneta atnete zonea
----------------
cap.printers:
----------------
[comments deleted]
atl=LaserWriter Plus:LaserWriter@*
#laser10=Laser10:LaserWriter@*
#laser=Laser10:LaserWriter@*
#postscript=Laser10:LaserWriter@*
#PostScript=Laser10:LaserWriter@*
----------------
PHRI.CONFIG (for "FastPath(tm) Manager")"
----------------
* Config file for KFPS, KIP version, 10/86.
*
* A future version of the 'prompt' program will recognize
* a line containing a 'dot format' address and convert those
* four decimal byte values to four hex bytes(?)
*
* These bytes are ignored but must be left as placeholders:
0000 0000 FF FF FF 00 000000 000000
* Gateway name (in this example, "gw")
677700000000000000000000000000000000000000
* File name (in this example, "gw.srec"):
67772E737265630000000000000000000000000000
* reserved (this field should be 00FF):
00FF
*
* Start of 'mandatory' parameters, the minimum information that
* must be supplied for the gateway to begin operation.
*
* IP address of myself, 'ipaddr'
* 192.9.200.150
C009C896
* IP addr of admin host
* 192.9.200.100
C009C864
* IP addr of default route (nearest 'real' gateway)
* 192.9.200.100
C009C864
* ethernet hardware addr of KFPS;
* 080089 is the Kinetics manufacturer code,
* remaining bytes are the serial number of your box.
080089 D00695
* next value is a flag, if it is '1234' the remainder
* of this file is considered valid; any other value means
* that the remaining parameters will be obtained from atalkad.
0000
----------------
Some things work fine. Using the NCSA telnet program that came with the
kbox, I can telnet to various Unix machines on our ethernet and can ftp
back to the Mac with no trouble. If I try to do an "lpr -Patl", atis hangs
with the following in the spooler errs file:
----------------
PAPIF: Starting job for root@phri at Sun Jul 26 13:55:23 1987 on printer LaserWriter Plus:LaserWriter@*
Problems finding LaserWriter Plus:LaserWriter@*
Aborted job at Sun Jul 26 13:59:14 1987
----------------
If I run The Namer on the Macintosh, it shows "LaserWriter Plus" as a valid
printer name.
Doing /etc/ping shows that the kbox is alive:
% /etc/ping 192.9.200.150
PING 192.9.200.150: 56 data bytes
64 bytes from 192.9.200.150: icmp_seq=0. time=15. ms
64 bytes from 192.9.200.150: icmp_seq=1. time=13. ms
64 bytes from 192.9.200.150: icmp_seq=2. time=14. ms
64 bytes fro
----192.9.200.150 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 13/14/15
%
but running /etc/cap/look (or looks or pinger) give me back nothing:
% cd /etc/cap
% look
abInit: [ddp: net 55.01, node 100] starting
Looking for =:=@* ...
% looks
abInit: [ddp: net 55.01, node 100] starting
Looking for =:LaserWriter@* ...
% pinger
abInit: [ddp: net 55.01, node 100] starting
Looking for =:=@* ...
%
Enough data (I hope); time for specific questions. Am I right in assuming
that the "FastPath(tm) Manager" application that came with the kbox is the
same as the "prompt" program referred to in the kip etc/install document?
Should I worry that when I run it and point it at my config file, it shows
garbage for the AppleTalk zone names, etc?
Do I need to put the IP address for the kbox (192.9.200.150) in my
/etc/hosts file? What about the other static and dynamic IP address
generated by the gateway?
Where do I start to look to debug something like this? We've got etherfind
on our suns (which shows occasional udp packets immediately answered by arp
packets to/from the kbox) but I'm not much of a networking guru so I don't
really know what I'm doing with that.
Looking through the papif code, I see it looking for a "-p printername" to
get the name of the printer it is supposed to use, defaulting to
"LaserWriter Plus" if there is none. However, papif doesn't get called
with a "-p" from lpr:
% ps lww#28839
F UID PID PPID CP PRI NI ADDR SZ RSS WCHAN STAT TT TIME COMMAND
1008001 0 28839 28838 3 1 0 9e0 42 24 selwait S ? 0:00 papif -w0 -l72 -i0 -n roy -h phri /usr/spool/at-laser10/acct
Is there something wrong with my lpr?
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016cck@JOLT.COLUMBIA.EDU (Charlie C. Kim) (07/27/87)
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 <printername> 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