Dear Maintainer,

When I'm trying to use mtr to an 'subnet router anycast address' which terminates on a linux router, the router answers with the IPv6 address configured on it's interface and not the anycast address, so the mtr does not stop.

(For the example I use the IPv6 documentation address space)
Let's say my linux router has the IPv6 2001:db8:0:1::1/64 and I want to make a traceroute to 2001:db8:0:1::
Example: mtr 2001:db8:0:1::
Host                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. XXXX:XXXX::X:XX                                        0.0%     3    0.7   1.4   0.7   2.6   1.1
2. XXXX:XXXX::X:XX                                        0.0%     3    2.4   1.3   0.7   2.4   1.0
3. XXXX:XXXX::X:XX   	                                  0.0%     3    3.4   4.5   3.4   5.5   1.1
4. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
5. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
6. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
7. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
8. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
9. 2001:db8:0:1::1                                        0.0%     3    3.7   3.6   3.5   3.7   0.1
10.   .......

In my opinion the mtr does not stop, because it does not get an answer from the requested address, but because it's an 'subnet router anycast address' the router answers anyway, which is correct.

Maybe I'm wrong, but I would expect a result like this:
Example: mtr 2001:db8:0:1::
Host                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. XXXX:XXXX::X:XX                                        0.0%     3    0.7   1.4   0.7   2.6   1.1
2. XXXX:XXXX::X:XX                                        0.0%     3    2.4   1.3   0.7   2.4   1.0
3. XXXX:XXXX::X:XX   	                                  0.0%     3    3.4   4.5   3.4   5.5   1.1
4. 2001:db8:0:1::                                         0.0%     3    3.7   3.6   3.5   3.7   0.1

As far as I found out, it seems to only appear on linux routers, so I'm not 100% sure if it's a bug in mtr-tiny or a misconfiguration on the linux routers.

Hi,

I'd say this is an unwanted side-effect rather than a bug.

I'd say the "end-detection" might also consider three times the same
host responding to be considerd as "the end".

Originally the TTL, that is now "hop counter" was the "number of
seconds in the network".

Thus if there was a queue of 5 seconds before a packet could take
the next link, the TTL would be decreased by five for that hop. And
that router should return a TTL EXCEEDED for packets arriving with
a TTL of 1-5.

This would, after the suggested change trigger the end-detection. I'm
thinking that this would be rare enough nowadays to be acceptable.

The question is: What response are you getting. If it is a "ping
reply" and not a "time exceeded" we should definitively detct that as
"target reached". So can you trace the network?

Can you submit an upstream bugreport on github?
https://github.com/traviscross/mtr/issues

	Roger.

Hi,

I aggree with you that it's not really a bug, anyways I thougt it could be handled different by the program. Your proposal with the additional "end-detection" would seem to work fine for this problem, below I presented you the exact behavior in my test setup and attached some network traces and a diagram of the setup.

I prepared a test setup and captured two traces of the network. The test consists of three linux routers which are connected as follows: R1 <-> R2 <-> R3 (see test_setup.png)
1st trace(intended_behavior.pcap) works as expected:
From R1 to R3:
mtr -c 1 2001:db8:0:3::1
Host                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:db8:0:1::2                                                          0.0%     1    1.0   1.0   1.0   1.0   0.0
 2. 2001:db8:0:3::1                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0

2nd trace(unintended_behavior.pcap) does not stop, because I try to reach the anycast address:
mtr -c 1 2001:db8:0:3::
Host                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:db8:0:1::2                                                          0.0%     1    1.0   1.0   1.0   1.0   0.0
 2. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
 3. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
 4. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
 5. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
 6. 2001:db8:0:2::2                                                          0.0%     1    1.0   1.0   1.0   1.0   0.0
 7. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
 8. 2001:db8:0:2::2                                                          0.0%     1    1.2   1.2   1.2   1.2   0.0
 9. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0
10. 2001:db8:0:2::2                                                          0.0%     1    1.2   1.2   1.2   1.2   0.0
11. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
12. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0
13. 2001:db8:0:2::2                                                          0.0%     1    1.2   1.2   1.2   1.2   0.0
14. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
15. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
16. 2001:db8:0:2::2                                                          0.0%     1    1.1   1.1   1.1   1.1   0.0
17. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
18. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
19. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
20. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
21. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
22. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
23. 2001:db8:0:2::2                                                          0.0%     1    1.3   1.3   1.3   1.3   0.0
24. 2001:db8:0:2::2                                                          0.0%     1    1.5   1.5   1.5   1.5   0.0
25. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0
26. 2001:db8:0:2::2                                                          0.0%     1    1.2   1.2   1.2   1.2   0.0
27. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0
28. 2001:db8:0:2::2                                                          0.0%     1    1.2   1.2   1.2   1.2   0.0
29. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0
30. 2001:db8:0:2::2                                                          0.0%     1    1.4   1.4   1.4   1.4   0.0


On Wednesday, November 15, 2023 11:15 CET, Rogier Wolff <R.E.Wolff@BitWizard.nl> wrote:
 Hi,

I'd say this is an unwanted side-effect rather than a bug.

I'd say the "end-detection" might also consider three times the same
host responding to be considerd as "the end".

Originally the TTL, that is now "hop counter" was the "number of
seconds in the network".

Thus if there was a queue of 5 seconds before a packet could take
the next link, the TTL would be decreased by five for that hop. And
that router should return a TTL EXCEEDED for packets arriving with
a TTL of 1-5.

This would, after the suggested change trigger the end-detection. I'm
thinking that this would be rare enough nowadays to be acceptable.

The question is: What response are you getting. If it is a "ping
reply" and not a "time exceeded" we should definitively detct that as
"target reached". So can you trace the network?

Can you submit an upstream bugreport on github?
https://github.com/traviscross/mtr/issues

Roger.

Hi,

What I meant with "trace" is a network dump. Like tcpdump or wireshark.
What packet is coming back ?

	Roger.