Bill Dodd wrote:
>
> I'm not sure what's going on here, but my first guess would be that
> perhaps your gateway has a firewall rule that is blocking the incoming
> icmp "time exceeded" packets (type 11).
>
> Are you doing the tcpdump on the machine and interface that is directly
> connected to the cable modem? If not, it might be useful to try that and
> see if perhaps the icmp packets are making to the cable modem but not
> through the gateway.
>
> That's the only thing I can think of.
Well, the tcpdump was running on the same machine attempting the traceroute.
My firewall/route is a 4-port LinkSys cable router, so I'm not sure what
"rules" it's using. I'll give LinkSys a call later if I can't figure this
out. Thanks for responding.
JimW
> On Fri, 9 Feb 2001, Jim Westbrook wrote:
>
> > I do sort of recall reading that somewhere else -- a while back, though. At
> > the command line, I only enabled the debug mode switch when I failed to get a
> > "normal" response. By running tcpdump in another term I trapped the following
> > at the end of the 30 hops:
> >
> > 22:21:41.588121 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33512: udp 12
> > 22:21:41.888570 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33513: udp 12
> > 22:21:42.187983 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33514: udp 12
> > 22:21:42.488072 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33515: udp 12
> > 22:21:42.788569 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33516: udp 12
> > 22:21:43.087985 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33517: udp 12
> > 22:21:43.387992 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33518: udp 12
> > 22:21:43.688530 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33519: udp 12
> > 22:21:43.987984 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33520: udp 12
> > 22:21:44.287991 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33521: udp 12
> > 22:21:44.588688 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33522: udp 12
> > 22:21:44.887989 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33523: udp 12
> > 22:21:45.187992 den2.jimnet.lo.53342 > web3.cc.utexas.edu.33524: udp 12
> >
> >
> > Here's a clip from the output of the trace itself:
> >
> > jim@den2:~ > /usr/sbin/traceroute -vw .3 www.utexas.edu
> > traceroute to www.utexas.edu (128.83.40.17), 30 hops max, 40 byte packets
> > 1 * * *
> > 2 * * *
> > 3 * * *
> > 4 * * *
> > 5 * * *
> > [ same thing ]
> > 30 * * *
> >
> > I can watch the led's on my switch and cable modem flashing in synch with the
> > packets recorded by tcpdump, there's just nothing being received in reply. Any
> > suggestions on tos or some other switch that may get a response?
> >
> > JimW
> >
> >
> > Bill Dodd wrote:
> > >
> > > I believe the failures you are seeing with -d are from a bug in
> > > traceroute. For the debug (-d) and "don't route" (-r) options, traceroute
> > > is saving those options during argument processing by doing:
> > >
> > > options |= SO_DEBUG;
> > >
> > > and
> > >
> > > options |= SO_DONTROUTE;
> > >
> > > respectively.
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
