ruffwork@orstcs.CS.ORST.EDU (09/19/87)
[Warning - this is about 180 lines long...so much away lineeater...]
In the spirit of helpful debugging on this group, I will put my problem
before you - any help in what is going on will be appreciated !!!
The data first -
The main host running all the Unix stuff is "orstcs": a vax
11/750 running 4.3 BSD.
The Kinetics box is a KFPS-2 running the 3/87 gw.srec code.
The kip/cap code is all the latest from SUMEX-AIM (cap
is 4.0 with patches 5, 6, and 7 installed).
Our AppleTalk cable is to be 128.193.36.*, while "orstcs"
is 128.193.32.1 (i.e. we are treating the AppleTalk as a
sub-net). We only have a single ethernet cable, so "orstcs"
and the KFPS2 are connected to the same physical ethercable.
We mainly want to run aufs and telnets from Macs on the
AppleTalk to "orstcs".
Here are the configuration files for kip/cap -
["Sagens" of comments removed ;-]
55.32 N2 128.193.32.0 O #OSU CS Ethernet
55.36 N2 128.193.36.0 O #osu cs appletalk
56.36 KC 128.193.36.1 O # Kinetics box
I128.193.255.255 I128.193.32.1 # ipbroad ipname
I128.193.32.1 L0 # ipdebug ipfile
L0 L0 L0 L0 S0 S0 # ipother unused unused
LX0 S6 S6 # flgs ipstat ipdynam
S56.36 S55.36 "O" # atneta atnete zonea
Here is the KFPS configuration file -
* 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") now "OSU Appletalk gate"
4F5355204170706C6575616C6B2067617465203200
* 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'
* OSU (KFPS2 = 128.193.36.1)
80c12401
* IP addr of admin host
* OSU (orstcs = 128.193.32.1)
80c12001
* IP addr of default route (nearest 'real' gateway)
* OSU is 128.193.32.1 (Cisco gw = 128.193.35.211)
80c123d3
* ethernet hardware addr of KFPS;
* 080089 is the Kinetics manufacturer code,
* remaining bytes are the serial number of your box.
* 080089 F00777
* OSU (KFPS2 = #01011)
080089 F01011
* 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
The atalk.local file on orstcs is -
# mynet mynode myzone - orstcs at osu cs dept.
55.32 1 O
# bridgenet bridgenode bridgeIP
55.36 1 128.193.36.1
Now (finally) for the problem. If I start atalkad on orstcs, then
load and boot the KFPS2, then start atis and aufs - I can telnet
anywhere (even out to the internet), I can ping the KFPS2, but look
and pinger give me this -
orstcs# /usr/local/bin/cap/look
abInit: [ddp: net 55.32, node 1] starting
Looking for =:=@* ...
01 - 128.193.36.1:IPGATEWAY@* [Net: 56.36 Node:220 Skt: 72]
orstcs# /usr/local/bin/cap/pinger
abInit: [ddp: net 55.32, node 1] starting
Looking for =:=@* ...
01 - 128.193.36.1:IPGATEWAY@* [Net: 56.36 Node:220 Skt: 72]
Ping...no response
Notice there are no entry for AUFS in here (and is the KFPS2
suppose to ping to pinger?) !!! When I open chooser from a Mac on the
AppleTalk and click on the AppleShare icon AUFS does not show
up (nothing does).
Now here is where the fun starts !!! First I told the atis damon
to dump its table and - wow - aufs is there, but not the KFSP2
as an IPGATEWAY.
# Dump of NIS name table at Sat Sep 19 07:27:01 1987
# Zone is fixed as O (This is '*' - my zone)
# Format: ddp net, node, skt, and nbp enumerator followed by
# obj, type, zone length enclosed in !'s and then the name
# 1 entries
net=14112, node=1, skt=134, enum=0, !6!9!1! ? orstcs:AFPServer@*
The net (14112) is 55.32, which is right (right?) because this is
on orstcs. If I ask my telnet to show me the network numbers it
says it is on AppleTalk network number 14372, which is 56.36, so
that aok (right?).
So I said to myself - maybe aufs is not starting out right - so
here is what the aufs "orstcs.log" looks like -
28458* 07:35:41 08/19/87 ****************************************
28458* 07:35:41 08/19/87 Apple Unix File Server (orstcs:AFPServer@*) starting
28458* 07:35:41 08/19/87 Aufs version: 2(0) as of August 25, 1987
28458* 07:35:42 08/19/87 10 sessions allowed
28458* 07:35:48 08/19/87 FLOCK configured
28458* 07:35:49 08/19/87 Aufs Starting (orstcs)
28458* 07:35:49 08/19/87 System vols in '/users/ruffwork/afpvols'
28458* 07:35:49 08/19/87 SPInit Completed. Waiting for connection...
28458* 07:35:49 08/19/87 Waiting for session 0 to activate
Well, looks AOK...hmmm... So I started to mess up (er, mess around with)
the atalk.local on orstcs. If I change it to the following on orstcs -
# mynet mynode myzone - orstcs at osu cs dept.
55.32 1 O
# bridgenet bridgenode bridgeIP
55.32 1 128.193.36.1
^^
This is what I get from look and pinger -
orstcs# /usr/local/bin/cap/look
abInit: [ddp: net 55.32, node 1] starting
Looking for =:=@* ...
01 - orstcs:AFPServer@* [Net: 55.32 Node: 1 Skt:134]
orstcs# /usr/local/bin/cap/pinger
abInit: [ddp: net 55.32, node 1] starting
Looking for =:=@* ...
01 - orstcs:AFPServer@* [Net: 55.32 Node: 1 Skt:134]
Ping...Okay
Notice that the IPGATEWAY is no longer there, but the AUFS server is !!??!!
Another thing is that if the KFPS2 box is not running then the aufs
server dies like so -
28630* 08:37:15 08/19/87 ****************************************
28630* 08:37:15 08/19/87 Apple Unix File Server (orstcs:AFPServer@*) starting
28630* 08:37:15 08/19/87 Aufs version: 2(0) as of August 25, 1987
28630* 08:37:16 08/19/87 10 sessions allowed
28630* 08:37:28 08/19/87 SrvrRegister for orstcs failed...
Now, my question is - WHATS GOING ON ??? I can't see where I messed
up the configuration files (but obvously I have), and I am more confused
by the fact that if I change the atalk.local file to the wrong one
I see one thing while the right one gives another. Don't I want to
see the IPGATEWAY and the AUFS server with the right atalk.local ???
Boy, am I confused...
ANY help in pointing out where I've screwed up would be
appreciated.
Thanks for actually reading this long note, and for any help you give,
--Ritchey Ruff
"I haven't lost my mind...it's backed up on tape somewhere around here..."
Internet - ruffwork@cs.orst.edu
UUCP - { hp-pcd | tektronix }!orstcs!ruffworkcck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (09/20/87)
Some explanation. Most of the problems I've seen are problems with
setting up the KIP code. In particular, the usual problem is that
people have not setup things so that all the "routing" is done
correctly.
CAP lets KIP do all the routing. We've tried other methods in the
past and they are a pain. However, the KIP method is not fool proof
by any means.
When CAP needs to send a packet, it sends the packet to the gateway
listed in atalk.local under the assumption that it will forward it to
the correct gateway (e.g. appletalk personal network) or host.
Basically, it treats the KIP box as a AppleTalk bridge and assumes
that it has the functionality of an AppleTalk bridge (and when
properly configured it does have all the necessary functionality - it
is a combination AppleTalk bridge and IP router). By putting your
host (net 55.32, node 1) in atalk.local as the gateway, you are
telling host how to reach that host, but it will not be able to reach
any other host via "AppleTalk" protocols.
Routing of most packets is done by looking up the network (as listed
in atalkatab and sent by atalkad) and replacing the last byte of the
IP address with the node number (e.g. in 128.193.y.x - x gets replaced
with node #). Thus, a path for registration, etc. can be found. Important
point: you can only reach the ethernet "subnets" that are specified in
atalkatab. For instance, if you have entries for 128.193.32 and
128.193.36, but not 128.193.35, then you will not be able to reach
anything on 128.193.35 via the Appletalk protocols. (Telnet, etc.
works because IP routing is done differently).
NBP lookups are done differently though. CAP sends a NBP packet type
of "BrLk" ("Bridge Lookup") to the closest "AppleTalk Bridge" (e.g.
the KIP gateway). The KIP gateway/AppleTalk bridge in turn goes
through it routing tables, as sent by atalkad, and sends a NBP "LkUp"
packet to each valid network/host/kip-box. It does this in the
following way based up the "flags" field in the atalkatab:
o if 'K' send a NBP LkUp on the NBP port (wildcarded on
AppleTalk net) to the specified AppleTalk bridge (KFPS
running KIP). Since it is a lkup and not brRq pkt, it will
be sent to the correct network. In all present cases, this
LkUp pkt should be a broadcast directed to the AppleTalk
Personal Network attached to the Kinetics box.
o if 'N' send a NBP LkUp as a broadcast on the NBP port.
- the broadcast address used depends upon the selection of
(0,1,2,3). (wildcard'ed on Appletalk net). This will be a
broadcast on an ethernet network. Make sure the broadcast
address is acceptable for all hosts on the ethernet
network. FAILURE TO DO SO MAY RESULT IN MASSIVE DISRUPTION
OF YOUR ETHERNET NETWORK!!! For instance sending a
broadcast of 128.x.255.255 or 128.x.x.255 on a network with
BSD 4.2 hosts (that expect broadcasts on 128.59.0.0) may
result in a storm of ARP requests from the various BSD 4.2
hosts.
o if 'H' send a NBP LkUp to the specfied host on the KIP
redirector socket. The specfied host should be running
atalkrd. atalkrd listens to the redirector socket and
when it receives a packet, it will send it to the list of
specified hosts on the NBP port.
If you think carefully about this, you'll see the problem resolves
into how to reach the hosts that have atis running or Macintoshes with
registered names. Adding support for a direct NBP Lookup route that
would allow people specify which hosts were running atis (e.g have
servers) would simply things, but there are unacceptable penalties in
doing this for larger setups (you are limited to 64 entries in this
atalkatab - this is an implementation problem).
So you see there are two things that get specfied in the atalkatab.
The first is a mapping from the IP address domain to the AppleTalk
address domain. This part most people get right. The second is a
specfication for how NBP should be done. This is something that is
easy to mess up. YOU MUST GET THE SECOND PART RIGHT TO USE CAP. All
CAP clients and servers are highly dependent upon being able to do NBP
lookups by their very nature. It could be alleviated in part by making
the Unix hosts into "AppleTalk bridges" as well. (If zones ever get
implemented, then there will be a greater need for this since you must
have an AppleTalk bridge to reach from one zone to the another).
(By the way, in this particular case, the problem is probably that the
host 128.193.32.1 is subnetted or is a BSD 4.2 based system. In the
first case, it would expect broadcasts on 128.193.32.255 and in the
second, on 128.193.0.0).
If the answer if the first, you are running with subnets on all your
machines, then the answer is simple - redo things with the flags as
"n1" and be careful about specifying the broadcast address for the
kbox (which really should be for its subnet).
If the answer is the second, then you will have to use the redirector
to do things properly. You can try playing games with the kbox
broadcast address, but don't count on it working. There are other
minor problems here too (mostly dealing with the exchange of KBOX
routing data).
If you run hybrid - e.g. partially subnetted and partially not, then
you will have problems. I speak from experience here - we run most of
our network with LANBridge-100s with a couple of subnetted IP
gateways. This really makes life interesting. The only way to
properly deal with this environment is to have zones. This allows NBP
LkUps to be a bit more directed. (Actually any environment will gain
from using zones).
Well, enough.
Charlie C. Kim
User Services
Columbia Universitycck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (09/21/87)
By the way, pinger sends an AppleTalk echo request. The only Macintosh software that installs a AppleTalk echo request listener is the AppleShare server. KIP does not respond to AppleTalk echo requests. KIP does respond to ICMP echo requests. Charlie C. Kim User Services Columbia University