Ping works, traceroute doesn't

I have an odd problem, which is more of a nuisance than anything else,
but I'd still like to solve. I've successfully gotten my SpeedStream
1024 PCI wireless card working under Redhat 9 and I'm able to browse,
e-mail and ping, but traceroute will not work.

Here's the ping output for yahoo.com:
[user@host user]# ping yahoo.com
PING yahoo.com (66.218.71.198) 56(84) bytes of data.
64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=1
ttl=241 time=85.2 ms
64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=2
ttl=241 time=86.5 ms
64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=3
ttl=241 time=85.2 ms

--- yahoo.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2015ms
rtt min/avg/max/mdev = 85.222/85.677/86.548/0.660 ms

And here's the traceroute:
[user@host user]# traceroute yahoo.com
traceroute to yahoo.com (66.218.71.198), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *

And, finally, the routing table:
[user@host user]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0
0 wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
0 wlan0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
0 lo
0.0.0.0 192.168.254.56 0.0.0.0 UG 0 0
0 wlan0

The second entry in the routing table looks odd to me, but I haven't
the slightest idea how that is being set or even if it is correct.
Has anyone experienced this before?

On 10 Aug 2003 00:37:38 -0700, Sean Evans wrote:
> I have an odd problem, which is more of a nuisance than anything else,
> but I'd still like to solve. I've successfully gotten my SpeedStream
> 1024 PCI wireless card working under Redhat 9 and I'm able to browse,
> e-mail and ping, but traceroute will not work.
>
> Here's the ping output for yahoo.com:
> [user@host user]# ping yahoo.com
> PING yahoo.com (66.218.71.198) 56(84) bytes of data.
> 64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=1
> ttl=241 time=85.2 ms
> 64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=2
> ttl=241 time=86.5 ms
> 64 bytes from w1.rc.vip.scd.yahoo.com (66.218.71.198): icmp_seq=3
> ttl=241 time=85.2 ms
>
> --- yahoo.com ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2015ms
> rtt min/avg/max/mdev = 85.222/85.677/86.548/0.660 ms
>
> And here's the traceroute:
> [user@host user]# traceroute yahoo.com
> traceroute to yahoo.com (66.218.71.198), 30 hops max, 38 byte packets
> 1 * * *
> 2 * * *
> 3 * * *


does traceroute -I work?

Bit Twister <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> On 10 Aug 2003 00:37:38 -0700, Sean Evans wrote:

> > And here's the traceroute:
> > [user@host user]# traceroute yahoo.com
> > traceroute to yahoo.com (66.218.71.198), 30 hops max, 38 byte packets
> > 1 * * *
> > 2 * * *
> > 3 * * *
>
>
> does traceroute -I work?

Yes! I still get the *** for the first hop, but then it works
perfectly well after that. Is there a reason you can think of that
ICMP works but UDP doesn't?

> Yes! I still get the *** for the first hop, but then it works
> perfectly well after that. Is there a reason you can think of that
> ICMP works but UDP doesn't?

There are plenty of reason for which a traceroute might not display
anything for some hops.
Some routers simply drop the packets without no notification
when ttl=0.
Some others even drop packets with ttl<=n, with n>0.

Did you try to wait more that the 3 first hops ?
It would be really surprising if you get nothing for all the hops
(ie if you get 30 lines of * * *)

--
Christophe Le Gal

Christophe Le Gal wrote:
>
> > Yes! I still get the *** for the first hop, but then it works
> > perfectly well after that. Is there a reason you can think of that
> > ICMP works but UDP doesn't?
>
> There are plenty of reason for which a traceroute might not display
> anything for some hops.
> Some routers simply drop the packets without no notification
> when ttl=0.
> Some others even drop packets with ttl<=n, with n>0.
>
> Did you try to wait more that the 3 first hops ?
> It would be really surprising if you get nothing for all the hops
> (ie if you get 30 lines of * * *)

If you had a firewall blocking outbound UDP packets on ports 33434 -
33524 you would see precisely that.

I have had to have a bit of a fight with firewall admins in the past to
get traceroute permitted. They use Windows and configure the firewall so
that their traceroute (which used ICMP) works and I have to convince
them that the *nix one is different (and not all implementations have
the -I flag).

Regards, Ian

> If you had a firewall blocking outbound UDP packets on ports 33434 -
> 33524 you would see precisely that.
>
> I have had to have a bit of a fight with firewall admins in the past to
> get traceroute permitted. They use Windows and configure the firewall so
> that their traceroute (which used ICMP) works and I have to convince
> them that the *nix one is different (and not all implementations have
> the -I flag).

What are you talking about ?
My traceroute is using ICMP and I thought that it was the same for all
linux traceroute. Do you mean that some traceroute (and yours)
use UDP by default ?

--
Christophe Le Gal

Christophe Le Gal wrote:

> What are you talking about ?
> My traceroute is using ICMP and I thought that it was the same for all
> linux traceroute. Do you mean that some traceroute (and yours)
> use UDP by default ?

I might ask you the same question. All *nix traceroute implementations
that I have seen use UDP by default. Some implementations support
sending ICMP packets instead as an extension. Some, for instance the one
SuSE ship, do not.

What traceroute is this that you have?

I am talking about the outgoing packets of course. The response are
always ICMP.

Regards, Ian

Ian Northeast wrote:

> I might ask you the same question. All *nix traceroute implementations
> that I have seen use UDP by default. Some implementations support
> sending ICMP packets instead as an extension. Some, for instance the one
> SuSE ship, do not.
>
> What traceroute is this that you have?
>
> I am talking about the outgoing packets of course. The response are
> always ICMP.
>

How does this work, given that traceroute relies on icmp messages for the
ttl timeout on udp messages. Icmp messages aren't supposed to be sent,
when an icmp message fails.

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

Christophe Le Gal wrote:
>
> > I might ask you the same question. All *nix traceroute implementations
> > that I have seen use UDP by default. Some implementations support
> > sending ICMP packets instead as an extension. Some, for instance the one
> > SuSE ship, do not.
> > What traceroute is this that you have?
>
> It's becoming more and more mysterious : I have a SusE 8.2, and thus the
> SuSE shipped traceroute. And indeed my manpage says nothing about
> a -I option to use ICMP (which is one of the reason why I was thinking
> my traceroute used icmp)
> I will investigate this.

The SuSE man page isn't particularly detailed. It doesn't explicitly
state that it uses UDP (it doesn't say it uses ICMP either). However, if
you look at the description of the "-p" option you will see it refers to
the destination UDP port number.

What gave you the idea that it was using ICMP?

Regards, Ian

James Knott wrote:
>
> Ian Northeast wrote:
>
> > I might ask you the same question. All *nix traceroute implementations
> > that I have seen use UDP by default. Some implementations support
> > sending ICMP packets instead as an extension. Some, for instance the one
> > SuSE ship, do not.
> >
> > What traceroute is this that you have?
> >
> > I am talking about the outgoing packets of course. The response are
> > always ICMP.
> >
>
> How does this work, given that traceroute relies on icmp messages for the
> ttl timeout on udp messages. Icmp messages aren't supposed to be sent,
> when an icmp message fails.

From the "TCP/IP Applications FAQ" -
http://www.private.org.il/mini-tcpip.faq.html and also posted to
comp.protocols.tcp-ip:

The catch is that the original ICMP specifications dictated that ICMP
errors should not be sent as replies to ICMP packets, so old routers
would not respond
correctly to Microsoft's TRACERT. The spec has since been revised so
that ICMP errors are not sent as replies to ICMP error packets only,
which better solves the problem of errors bouncing back and forth across
the net.

Sorry, I don't know the RFC number.

I find ICMP traceroute to be a bit more useful than the traditional
variety. It gets through more firewalls. Even more useful is a program
called tcptraceroute which, as the name suggests, uses TCP. If you're
tracing the path to a machine which you are attempting to connect to
using TCP, it is reasonable to assume that any firewall in the way will
permit TCP packets to the port in question - or at least if it does not
then this is probably the problem you are chasing. Whereas if, for
instance, I run a UDP or ICMP traceroute from my mail exchange to a
remote mail exchange I am having trouble contacting, I may run across a
firewall which prevents the traceroute from working but would not
prevent the actual SMTP connection. If I use tcptraceroute on port 25 I
know that this is not so, and if I hit a firewall it is probably the
problem.

As our mail exchanges run SuSE, I have got three traceroutes installed -
the SuSE one, a BSD based one which has -I for ICMP, and tcptraceroute.

Regards, Ian