Traceroute response endless?

[Bevan C. Bennett]

Alexander Dalloz wrote:

> If above you ment last hop as your station, then do you have defined any
> iptables rules for icmp handling?
>  
> 
> On my Fedora Core 1 installations I can not agree such traceroute
> behaviour.

Unexpectedly, I -can- reproduce the behavior he describes.

to a RH8.0 system:
[bevan]> traceroute saladin
traceroute to saladin.internal.avlsi.com (10.0.0.45), 30 hops max, 38 
byte packets
  1  saladin.internal.avlsi.com (10.0.0.45)  0.216 ms  0.253 ms  0.227 ms

to a FC1.3 system:
[bevan]> traceroute wallace
traceroute to wallace.internal.avlsi.com (10.0.0.28), 30 hops max, 38 
byte packets
  1  wallace.internal.avlsi.com (10.0.0.28)  0.914 ms !<10>  0.169 ms 
!<10>  0.158 ms !<10>

The traceroute data appears to be returning correctly, although the 
aforementioned disturbing !<10> entries have been added.

This is using the -stock- iptables configuration, and iptables does 
indeed appear to be the cause.

to the FC1.3 system with iptables turned off:
[bevan]> traceroute wallace
traceroute to wallace.internal.avlsi.com (10.0.0.28), 30 hops max, 38 
byte packets
  1  wallace.internal.avlsi.com (10.0.0.28)  0.202 ms  0.182 ms  0.154 ms

/etc/sysconfig/iptables contains (should be stock):
# Firewall configuration written by redhat-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j 
ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

I'd have thought that '-p icmp' line would cover this, but apparantly 
there's something else at work. I'll try watching both cases with 
tcpdump to see if I can isolate the difference.