Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!bbn!bbn.com!tappan
From: tappan@bbn.com (Dan Tappan)
Newsgroups: comp.protocols.appletalk
Subject: Re: KIP and Apples Router...
Message-ID: <42015@bbn.COM>
Date: 27 Jun 89 11:23:28 GMT
References: <7162.614439407@GNOME.CS.CMU.EDU> <771@kinetics.UUCP>
Sender: news@bbn.COM
Reply-To: tappan@BBN.COM (Dan Tappan)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 44

In article <771@kinetics.UUCP> minshall@kinetics.UUCP (Greg Minshall) writes:
>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.  
> ...
>
>Greg Minshall				Kinetics/Excelan/Novell
>minshall@kinetics.com			1-947-0998

But... The way the Appletalk/UDP encapsulation works is that the
clients have no IP address. The bridge (or CAP host) puts its own
address in the header as the IP source and the address of other bridge
as the IP dest.

The biggest problems that I can see with implementing a UDP
encapsulation Appletalk driver are:

1) You have to be able to tell the UDP driver to forward the full
range of Appletalk ports to your bridge process (and conversely, the
bridge process has to be able to arbitrarily set the
source/destination port). This would be easier to do with some
cooperation from the Apple TCP folks.


2) As someone pointed out, you have to start things in the right
order: Ethernet < TCP < Appletalk. With some clever delays in
connecting to the TCP driver this is probably workable.

Dan Tappan