perfSONAR User Q&A and Other Discussion

[Brian Candler <>]

On 04/11/2015 17:48, Brian Tierney wrote:

(2) From the time of the upgrade, I get red dots showing:

"04:57:41 10/01/2015
Error from bwctl/traceroute:
Problem parsing traceroute output: Can't find hop number in output: traceroute6 to XXXX:XXXX:0:2::254 (XXXX:XXXX:0:2::254) from XXXX:XXXX:1:64::252, 64 hops max, 12 byte packets at /usr/share/perl5/vendor_perl/Net/Traceroute.pm line 624.
04:57:41 10/01/2015"

This might also explain why there is no "traceroute" link in the "test results" section for the IPv6 addresses.

This problem still exists. There is a big solid red line for all the errors, and hovering over one of the red dots shows:

15:52:00 11/03/2015
Error from bwctl/traceroute:
Problem parsing traceroute output: Can't find hop number in output: traceroute6 to 2001:db8x:0:2::254 (2001:db8x:0:2::254) from 2001:db8x:1:64::252, 64 hops max, 12 byte packets at /usr/share/perl5/vendor_perl/Net/Traceroute.pm line 624.
15:52:00 11/03/2015

And there is still no "Traceroute" link by the IPv6 source/destination pair, only "Details"

Unfortunately this seems to be a bug in the perl Net::Traceroute package. 

Perhaps you can file a bug report with them for us?

http://search.cpan.org/dist/Net-Traceroute-PurePerl/PurePerl.pm#AUTHOR

OK, it turns out the bug is subtle :-)

My remote probe is Mac OSX running bwctld and owampd.

When running traceroute6 under *Mac OSX* then the output starts with "traceroute6":

$ traceroute6 nsrc.org
traceroute6 to nsrc.org (2607:8400:2880:4::80df:9d1c) from ...
^^^^^^^^^^^

But under Linux it starts with just "traceroute"

$ traceroute6 nsrc.org
traceroute to nsrc.org (2607:8400:2880:4::80df:9d1c), 30 hops max, 80 byte packets
^^^^^^^^^^

When perfsonar is parsing the bwtraceroute output, it is passing it to Net::Traceroute using the undocumented "_parse" function, and this is barfing when the text contains 'traceroute6'.

-------
use Net::Traceroute;

$stdout = <<EOS;
traceroute6 to 2001:db84:0:2::254 (2001:db84:0:2::254) from 2001:db84:1:64::252, 64 hops max, 12 byte packets
 1  2001:db84:1:64::1  0.930 ms  0.756 ms  0.651 ms
 2  2001:db84:0:2::254  0.345 ms  0.350 ms  0.368 ms
EOS

$tr = Net::Traceroute->new();
$tr->_parse($stdout);

if($tr->found) {
    my $hops = $tr->hops;
    if($hops > 1) {
        print "Router was " .
            $tr->hop_query_host($tr->hops - 1, 0) . "\n";
    }
}
-------

Run this program and it gives the error. But change "traceroute6" to "traceroute" and it works.

As a temporary workaround, I added the following line to function parse_traceroute_output in regular_testing/lib/perfSONAR_PS/RegularTesting/Parsers/Traceroute.pm :

$stdout =~ s/traceroute6/traceroute/;

But I will escalate the issue to the maintainers of Net::Traceroute.

This then begs the question: why the difference between the perfsonar 3.4 and perfsonar 3.5 boxes? It turns out it's because they were talking to Macs which have two different versions of traceroute, despite both running OSX 10.10.5:

(One)

$ which traceroute6
/bin/traceroute6
$ ls -l /bin/traceroute*
-rwxr-xr-x  1 root root 57480 Nov 11  2010 /bin/traceroute
lrwxrwxrwx. 1 root root    10 Mar 28  2014 /bin/traceroute6 -> traceroute

(Other)

$ which traceroute6
/usr/sbin/traceroute6
$ ls -l /usr/sbin/traceroute*
-r-sr-xr-x  1 root  wheel  33968 19 Sep  2014 /usr/sbin/traceroute
-r-sr-xr-x  1 root  wheel  29648 19 Sep  2014 /usr/sbin/traceroute6

This is weird. Both boxes are set to auto-update, but I'm going to double-check all updates are completed.

Regards,

Brian.


P.S. The box which upgraded to perfsonar toolkit 3.5 has two "3.4" packages, is this correct?

$ rpm -qa | grep -i perfsonar | grep 3\\.4
perl-perfSONAR_PS-SimpleLS-BootStrap-client-3.4-3.pSPS.noarch
perl-perfSONAR_PS-LSCacheDaemon-3.4.2-1.pSPS.noarch