System: Fedora 21

Problem: actually already very well described here but unfortunately without any explanation WHY traceroute with TCP is not displaying the ICMP responses and with the (for me unsatisfying) solution of using another tool instead of traceroute.

Sending out traceroutes with ICMP or UDP works fine:

traceroute -I www.here.com

traceroute to www.here.com (, 30 hops max, 60 byte packets
 1 (  6.565 ms  8.483 ms  21.137 ms
 2  ppp-default.m-online.net (  34.677 ms  37.296 ms  37.495 ms
 3  ae2.rt-decix-2.m-online.net (  44.127 ms  45.428 ms  46.566 

traceroute -U -p 53 www.here.com

traceroute to www.here.com (, 30 hops max, 60 byte packets
 1 (  2.275 ms  7.949 ms  8.842 ms
 2  ppp-default.m-online.net (  36.303 ms  37.817 ms  38.685 ms
 3  ae2.rt-decix-2.m-online.net (  46.860 ms  47.964 ms  48.778 ms

however, TCP traceroute does not show any results:

traceroute -T -p 443 www.here.com

traceroute to www.here.com (, 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *

The peculiar thing is that in a (wireshark) trace the ICMP DU responses can be seen:


I was checking iptables DROP and REJECT rule counters,they don't change, so I guess iptables can be excluded...

[EDIT] also flushing iptables did not show any improvement, nor adding INPUT rules for the replying IPs. Counters show that these ACCEPT rules are used so iptables can be excluded as source of this problem

> Chain INPUT (policy ACCEPT 180 packets, 39653 bytes)
>  pkts bytes target     prot opt in     out     source               destination
>     3   168 ACCEPT     all  --  *      *
>     3   264 ACCEPT     all  --  *      *

Can someone give me a hint on how to debug this issue or even know from the top of the head what the issue is?

  • Look harder. You're probably blocking the relevant ICMPs from iptables. If your counters claim otherwise you're probably looking at the wrong counters.
    – lcd047
    Jul 10 '15 at 20:22
  • So you are very confident that it's iptables. But if I'd be blocking the ICMPs then it should block all of them, not only the ICMPs with a (fragment of a) TCP payload. After all, ICMPs without payload or with UDP payload are accepted (traceroute -I and traceroute -U -p)
    – Klemens
    Jul 11 '15 at 11:59
  • You're thoroughly confused. ICMP is a standalone protocol over IP. An ICMP datagram can never be "a (fragment of a) dropped TCP packet".
    – lcd047
    Jul 11 '15 at 12:03
  • cheers for the quick response, but i worry you misunderstood my comment. Yes the ICMP DU is on top of the IP header, however, inside the ICMP DU packet is the original packet (e.g. the original TCP packet in case of a TCP traceroute, or ICMP in case of a classic ICMP traceroute). Either way, concern regarding iptables as the culprit remains the same: if ICMP is dropped/rejected by an iptable rule, then traceroute wouldn't work at all. But as per above, ICMP and UDP traceroute is working.
    – Klemens
    Jul 11 '15 at 12:16
  • UDP traceroute working is not evidence of your iptables allowing ICMPs in. If you're doing stateful filtering, the time exceeded ICMPs would be accepted as related to the initial datagrams. But I suppose it doesn't make sense to speculate about what your iptables might or might not do, so I'll go away now.
    – lcd047
    Jul 11 '15 at 12:31

Unsatisfying solution: reboot

My last reboot was a good while ago and as I'm updating my system regularly I guess this caused the misbehaviour. I have a vague memory of a recommendation to reboot the system after updates because they might modify libraries which could lead to misbehaviours on binaries still running in ram on the old version.

Would have been still interesting and educational to debug this and understand what happened.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.