Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!njin!dpz From: dpz@pilot.njin.net (David Zimmerman) Newsgroups: comp.protocols.tcp-ip Subject: Re: route tracing through gateways Keywords: compiles ok, but dumps core Message-ID: Date: 19 Feb 89 06:39:07 GMT References: <110@dftsrv.gsfc.nasa.gov> Organization: Rutgers University Lines: 48 To: tomc@dftsrv.gsfc.nasa.gov Tom, I've gotten route recording working at Rutgers. You need four conditions to exist to get back the information you want: 1- you have to be able to set up IP options to go out in an IP packet 2- your gateways have to do "the right thing"; that is, each has to look at the IP options, note the IPOPT_RR field, and append its Internet address to that field (if there is room) 3- if your destination machine has to turn the packet around, it must do so correctly (see below) 4- you have to be able to read the IP options out of a packet 4.3BSD-derived systems do the right thing for #1 and #4. cisco gateways do the right thing with #2. I'm not sure whether 4.2BSD-derived systems do the right thing with #1, #2, or #4, since our single link to the outside world is a 4.3BSD VAX here -> 4.2BSD VAX at JVNC, and we're more or less out of that manner of beast around here. However, my experience has been rather negative with 4.2BSD-derived systems in that respect. I wanted to set the IP options for route recording in a ICMP echo packet, so that the echo reply back to me would have the path, or as much of the path as possible, that the packet took. Due to the maximum length of the IP option area, you get a maximum of 9 Internet addresses. My problem was that a target Unix box using 4.xBSD-derived networking would do the wrong thing. 4.3BSD-derived systems (including SunOS 4.x) would send me back an echo reply without any IP options, so I would see that the machine is up, but not be able to tell what path the packet took to get there and back. 4.2BSD-derived systems (including SunOS 3.x) would get confused and not send me back anything, so not only would I not get the route back, I couldn't even tell if the machine was up. I'm not sure if your problem is related to any of this, but... I have fixes to sys/netinet/ip_input.c and sys/netinet/ip_icmp.c to take care of that. I also have a modified ping to send out and parse back these route recording creatures (although the code is a one night hack, and looks it). All our SunOS 4.x Suns and 4.3BSD VAX 11/750 now reflect the ICMP echo back correctly, and we get to see how our routing isn't working. Drop me a line if you are interested. David -- David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc dpz@dorm.rutgers.edu rutgers!dpz dpzimmerman@zodiac.bitnet