brad@cayman.com (11/18/89)
>> Organization: University of Utah CS Dept >> Subject: Short ddp and RTMP. >> Message-Id: <1989Nov16.185839.14721@hellgate.utah.edu> >> Sender: info-appletalk-request@andrew.cmu.edu >> To: info-appletalk@andrew.cmu.edu >> >> .... >> >> This inconsistency causes a problem in an RTMP-stub that is passively >> trying to acquire its net address. If a router has zero for a net >> number, it probably should not match with the incoming packet. Do you mean that it the route has not yet aquired the "active" network number? (i.e. the router's port does not know the port's net number?) >> Yet KIP >> sends out long ddp packets with the routing information. This problem >> caused ddp drivers from MtXinu not to find its network address. It is >> also the likely cause of why our CISCO gateways are confused by >> gateways running KIP. Why are the routers looking in the ddp header? The RTMP packet data contains the network number you need for the wire, yes? If the port aquires the network number from the RTMP packet data (and not from the ddp header) then everything should work fine. IMHO, several famous problems with appletalk routers have started with software which decided to use the ddp header instead of the data in the packet. (look at NBP - several ubiquitous devices such as laserwriter I's respond to the ddp header instead of the nbp tuple address as the spec says.) (ps: I would say the MtXinu and CISCO code is broken in this case. To save me a hail storm of hate mail, I like MtXinu s/w and Cisco routers ;-) I'm just conjecturing here) >> For the moment I am changing our ddp code to allow either short or long >> ddp packets, but the inconsistency needs to be cleared up whether or >> not the short form is required for routers. I don't understand what the inconsistency is. Please help me understand. It should not matter if the ddp transport uses a long or short header. (also, which s/w is "our ddp code" ?) -brad