Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) (06/21/89)
I've tested Apple's Internet Router, and I agree, it is nice. I acutally set it up across the same network as my KFPS-4 (running KIP) so I had a parallel route between my Ethertalk and localtalk nets. That worked fine. This was on my mac II running AppleShare. And if I ran the print server, it crashed alot. But I had a beta copy, remember! 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. We shouldn't have to change the router, and the resulting "Encapsulated AppleTalk" (IPTalk?) driver could also be used on standalone Macs. The IPTalk driver might have to still talk to the KIP demon via IP directly, to fully simulate KIP. I might be wrong in terms of the work involved, but am I technically off the wall? Would be fun... Rob
falken@apple.com (Dave Falkenburg) (06/22/89)
In article <7162.614439407@GNOME.CS.CMU.EDU> Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) writes: > 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. We shouldn't have to change the router, and the > resulting "Encapsulated AppleTalk" (IPTalk?) driver could also be used on > standalone Macs. The IPTalk driver might have to still talk to the KIP > demon via IP directly, to fully simulate KIP. > > I might be wrong in terms of the work involved, but am I technically off the > wall? Would be fun... The only problem with building a UDP LAP would be that the LAP manager would try to install the IPTalk LAP BEFORE MacTCP had been loaded. (I think, but am not sure) -dave falkenburg falken@apple.com disclaimer: I'm not in Networking & Communications at Apple, just System Software. Regardless of this fact, these opinions are my own!
minshall@kinetics.UUCP (Greg Minshall) (06/26/89)
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
tappan@bbn.com (Dan Tappan) (06/27/89)
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