#8 Problem with --mtu on kernels >= 3.13

[Graham Inggs]

I'm seeing strange output when using the --mtu option with traceroute 2.0.20 on recent Debian/Ubuntu distributions. I have compiled traceroute 2.0.20 on Trusty, Utopic and Sid and see output similar to the following:

$ traceroute --mtu 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 65000 byte packets
1 * 0.015 ms * 0.007 ms * 0.006 ms
2 * 0.006 ms * 0.007 ms * 0.006 ms
3 * 0.006 ms * 0.006 ms * 0.006 ms
4 * 0.006 ms * 0.008 ms * 0.007 ms
5 * 0.007 ms * 0.006 ms * 0.006 ms

I see similar numbers up to hop 30 and they appear almost instantly.

I compiled traceroute 2.0.20 on Ubuntu Precise and get the expected output.

[Dmitry Butskoy]

Looks like impossible... Any numbers cannot be printed accompanied to `*' ...
Probably some compiler or system library bug.

Could you try the same tests with traceroute-2.0.19 etc.?
What happen without --mtu' option? With another traceroute methods (-I', `-T') ?

[Graham Inggs]

Without --mtu or with -I or -T are all fine.

2.0.19 on Trusty, Utopic and Sid all segfault with the --mtu option.
See Debian bug #750759 ( https://bugs.debian.org/750759 ).

[Graham Inggs]

There's also a bug report for 2.0.19 segfaulting with the --mtu switch in Arch Linux: https://bugs.archlinux.org/task/40026

[Craig Tong]

I can confirm this behavior on Gentoo:

traceroute 2.0.18 works on 3.12.21 kernel with or without flags

traceroute 2.0.18 segfaults on kernel 3.14.14 with --mtu, and works without --mtu

traceroute 2.0.20 works on 3.12.21 kernel with or without flags

traceroute 2.0.20 outputs as described above by Graham on kernel 3.14.14 with --mtu, and works without --mtu

[Graham Inggs]

So on newer kernels I see one packet arriving with ee->ee_origin = SO_EE_ORIGIN_LOCAL followed by the rest with ee->ee_origin = SO_EE_ORIGIN_ICMP.

With the following patch in place, I am seeing reasonable results with traceroute 2.0.20 on Ubuntu Trusty (kernel 3.13).

--- a/traceroute/traceroute.c
+++ b/traceroute/traceroute.c
@@ -1345,7 +1345,7 @@

            ee = (struct sock_extended_err *) ptr;

-           if (ee->ee_origin != SO_EE_ORIGIN_ICMP)
+           if ((ee->ee_origin != SO_EE_ORIGIN_ICMP) && (ee->ee_origin != SO_EE_ORIGIN_LOCAL))
                ee = NULL;
            /*  dgram icmp sockets might return extra things...  */
            else if (ee->ee_type == ICMP_SOURCE_QUENCH ||

[jdg]

I'd like to confirm that this bug is still present in 2.0.20, as I've just run into it (on Arch Linux).

Ubuntu appears to have applied the patch posted by Graham; while I cannot vouch for its correctness (as I don't fully understand the logic involved), it does appear to work.

Do note that Graham's patch is incomplete, as it only fixes the issue for IPv4. V6 needs to be patched in a similar fashion.

[Dmitry Butskoy]

Fixed in 2.0.21

The problem seems to be inspired as a side effect from some changes in the 3.13 Linux kernel (see commit daba287b299ec7a2c61ae3a714920e90e8396ad5 at git.kernel.org).

Please, test --mtu' and-F' work with the new version 2.0.21 in your environment etc.

[Graham Inggs]

I'm getting expected results from traceroute 2.0.21 on Ubuntu Utopic (kernel 3.16). Thanks!