Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!rutgers!apple!bionet!ig!ames!pacbell!varian!zehntel!kinetics!minshall
From: minshall@kinetics.UUCP (Greg Minshall)
Newsgroups: comp.protocols.appletalk
Subject: Re: KIP and Apples Router...
Message-ID: <771@kinetics.UUCP>
Date: 26 Jun 89 00:48:44 GMT
References: <7162.614439407@GNOME.CS.CMU.EDU>
Organization: Kinetics, Inc., Walnut Creek, CA
Lines: 26

From article <7162.614439407@GNOME.CS.CMU.EDU>, by Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok):
> Anyway, It seems that with MacTCP + a little work, we could have the Apple
> Router replace the KIP box, by making an AppleTalk driver that routed
> packets via MacTCP.
...
> I might be wrong in terms of the work involved, but am I technically off the
> wall? Would be fun...

This is an interesting idea.  However, you won't be able to use MacTCP (nor
TCPort, for that matter).  The two problems are that you won't be able to
send packets with the correct (client) address, and you won't be able to
receive packets sent to your clients.  When you ask MacTCP to send a
packet, it (quite reasonably) plops its own IP address in the source
field of the datagram.  So, you lose the original source address.
When someone tries to send to your client, it may decide to ARP for the
address.  MacTCP won't answer this ARP.  Now, it could be that the client
appears to be in a separate IP (sub)network from the ethernet cable on which
MacTCP is running; in this case, client code on the Mac could generate RIP
packets saying "send here" (as the newest K-Star will do), or you could
manually configure your hosts to send packets to MacTCP.  However, when
MacTCP gets the packet, it will say "not for me" and drop it (I assume -
at least that is what TCPort will do; MacTCP *could* try to forward the
packet somewhere).

Greg Minshall				Kinetics/Excelan/Novell
minshall@kinetics.com			1-947-0998