dk1z+@ANDREW.CMU.EDU.UUCP (06/04/87)
We've experienced two different problems at CMU with Kinetics gateways
running the latest KIP software.
1) An uninitialized gateway will tend to answer ARPs for a large number of
machines on the network. (We do not do subnetting as of yet.) By
uninitialized, I mean a gateway that has the code left in memory but has not
received a configuration packet from the administrative host and is powered
on.
2) After properly loading the gateway and instructing the gateway to start,
the "bootme" packet is never transmitted on the ethernet side to the
administrative host. Atalkad on the host must be told to boot the gateway to
get it to start up. Various other oddities occured, but for the most part
were unrepeatable and thus I'll leave it at that.
The problem appears to lie in the iematch and abmatch routines. Both
routines fail to check to see if conf.ready is set. Upon powering up the
gateway, the values for conf.ipstatic and conf.ipdynamic (and a few other
values, certainly) are suspect. Contrary to expected behaviour, this occurs
even if you reset the gateway. [At times, Prompt could find the gateway after
a reset. At other times, you had to power it off and on again. The values for
conf were trashed in both cases.] We've observed values of 30,000+ for
ipdynamic, for example. When you instruct the gateway to start up, it
attempts to send a packet to the admin host. iematch is called to determine
which interface to send the packet out on. If the gateway has an address of
128.2.223.1 and the admin host is 128.2.232.12, then the difference between
them is 2315, which is the value for i in iematch. If conf.ipstatic +
conf.ipdynamic is around 30,000, then 0 < i < conf.ipstatic + conf.ipdynamic,
resulting in TRUE being returned from iematch. This causes the Kinetics
gateway to place the packet on the AppleTalk interface when, in fact, it
should be on the Ethernet side. Obviously, some values for the IP addresses
will cause the this behavior while other values such as gateway = 128.2.223.1
and admin = 128.2.35.1 will work.
The same sort of thing happens when an ARP packet comes in. iematch is
called and many IP addresses will fall within the range of the gateway's IP
address and (static + dynamic) causing the gateway to answer the ARP for
them.
To fix this, just check to see if conf.ready == conf.Ready before you check
to see if the addresses are in the range. The corrected code is at the end of
this post. abmatch is never called while the gateway is in the unconfigured
state but for completeness we added the check to it as well. We've tested
this code and found no problems with it. Previous installation problems have
vanished. I've heard no complaints from anyone else about this, so maybe,
somehow, it is just a local problem.
Many thanks to Rob Chandhok for first suspecting iematch and to Steve
Waldbusser for fixing the code and testing most of it.
-David C. Kovar
/* This is from gw.c */
/*
* Match an AppleTalk ARP. If the target is not in my own
* range, return true (match). This has the effect of forwarding all
* traffic for 'unknown' nets, to the backbone ethernet.
*/
abmatch(target)
iaddr_t target;
{
register i;
if (target == conf.ipaddr)
return (1);
if (ipnetpart(target) == 0x7F000000)
return (0);
+ if (conf.ready == confReady) {
i = target - conf.ipaddr;
if (i < 0)
return (1);
if (i >= conf.ipstatic + conf.ipdynamic + 1)
return (1);
+ }
return (0);
}
/*
* Match an ethernet ARP.
*/
iematch(target)
iaddr_t target;
{
register i;
+ if (conf.ready == confReady){
i = target - conf.ipaddr;
if (i >= 0 && i <= conf.ipstatic + conf.ipdynamic)
return 1;
+ }
return 0;
}