tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti) (02/18/89)
Hi!
I recently found source for Van J's traceroute program. It is a really
neat program for finding out what gateways your packets are travelling
through, and for seeing how long it takes to get there. Unfortunately,
I can't get it to work on my Sun 3/260 running Sun OS 3.5. I went and
installed all the new TCP/IP from Berkeley, which includes new "slow
start" algorithms, and also made the patch to raw_output that was in
the README for traceroute. I reconfigured my kernel with all this
new tcp/ip stuff. The kernel works fine. All existing networking
functions still function. Traceroute compiled without serious errors.
But, when I run it, it dumps core. Has anyone out there gotten this
program to work on a Sun running OS 3.5 ?, or for that matter, Sun OS 3.x?
I would appreciate hearing from you! Thanks in advance!
- Tom Corsetti
--
Tom Corsetti * * * * internet - tomc@dftsrv.gsfc.nasa.gov
NASA/Goddard Space Flt Ctr * * * decnet - dftnic::tomc
Greenbelt Maryland * * * * bitnet - tomc at dftbitdpz@pilot.njin.net (David Zimmerman) (02/19/89)
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