Problems running on Ubuntu 22.04, routing information is displayed incompletely, only part of it is displayed, can't get to the final destination

[zhiduopc]

Problems running on Ubuntu 22.04, routing information is displayed incomplete, only part of it is displayed, can't get to the final destination, only mtr v0.95 seems to be available, no more updates? Is there any way to fix this, any IP/domain name only shows part of the routing node, not the full one, traceroute classic version as well, I updated it to show the full routing node path information normally, mtr has no update information available!

                                                               My traceroute  [v0.95]

node (10.10.10.10) -> google.com (142.250.207.110) 2023-12-21T18:37:43+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev

1. _gateway 0.0% 51 0.5 0.3 0.2 0.7 0.1
2. 156.234.95.65 48.0% 51 5269. 5377. 5090. 5597. 111.5
3. 10.10.10.17 0.0% 51 10.5 2.4 0.5 13.7 3.1
4. 192.145.251.168 0.0% 51 33.6 33.8 33.1 42.3 1.5
5. 142.251.67.203 0.0% 50 31.8 32.6 31.7 46.2 2.8
6. 108.170.242.179 0.0% 50 86.3 50.7 31.6 102.2 21.5
7. 142.251.254.81 0.0% 50 34.2 35.1 33.9 61.8 4.2
8. 142.250.229.250 0.0% 50 38.5 39.7 38.2 58.2 3.7
9. 108.170.243.65 0.0% 50 39.2 40.3 39.2 59.2 3.7

traceroute to google.com (142.250.207.110), 64 hops max
1 10.10.10.1 0.283ms 0.139ms 0.113ms
2 * 156.234.95.65 2453.154ms *
3 10.10.10.17 0.486ms 0.435ms 0.387ms
4 192.145.251.168 37.894ms 38.534ms 37.987ms
5 * * *
6 108.170.242.193 30.302ms 34.026ms 27.912ms
7 108.170.242.134 28.137ms 27.647ms 27.723ms
8 142.250.212.151 36.754ms 36.477ms 36.438ms
9 142.250.58.92 38.500ms 38.531ms 38.401ms
10 108.170.243.65 38.476ms 38.481ms 38.531ms
11 142.251.69.231 43.682ms 43.724ms 43.542ms
12 142.250.207.110 43.830ms 43.916ms 43.793ms

[rewolff]

On my 22.04 system and with the stock system mtr (I don't even use it enough to upgrade it to the latest version on my OWN system... )...

17. 142.251.235.80                    0.0%    57  259.8 260.2 255.0 277.3   3.7
18. 108.170.243.65                    0.0%    57  260.1 262.8 254.8 270.6   3.0
19. 142.251.70.23                     0.0%    57  255.4 258.9 254.0 268.5   2.8
20. kix06s11-in-f14.1e100.net         0.0%    57  257.5 257.1 252.9 269.0   2.8

which does terminate on the same host/network as you, just even in the last few hops a different route than what you're getting. (using the hostname, instead of the IP gives me a route that's 11 hops... The DNS servers resolve the hostname to an IP that's close... )

Anyway, I suspect that mtr uses a slightly different packet type than what traceroute uses. There are commandline options to try to change the packet type. Please report if that helps. If so, That's your solution: If you don't reach the final hop, try a different packet type. If it doesn't help it seems unlikely that this leads to a change in mtr, but I'm interested to see a packet trace of when MTR does its thing to compare it to when traceroute does its thing. use mtr -r -c 3 google.com
as the commandline for mtr.

[zhiduopc]

Is it possible that the hyper-v virtual machine caused? But I have tried both independent IP and NAT-shared IP，This is also the case with centos 7.9. The last hop route is displayed as *, which is the case with any IP/domain name. In some cases, the hop count node of the middle route is not realistic, and only the beginning and the end are displayed. Do you know why?

…

---Original--- From: "Roger ***@***.***> Date: Fri, Dec 22, 2023 22:00 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [traviscross/mtr] Problems running on Ubuntu 22.04, routing information is displayed incompletely, only part of it is displayed, can't get to the final destination (Issue #498) On my 22.04 system and with the stock system mtr (I don't even use it enough to upgrade it to the latest version on my OWN system... )... 17. 142.251.235.80 0.0% 57 259.8 260.2 255.0 277.3 3.7 18. 108.170.243.65 0.0% 57 260.1 262.8 254.8 270.6 3.0 19. 142.251.70.23 0.0% 57 255.4 258.9 254.0 268.5 2.8 20. kix06s11-in-f14.1e100.net 0.0% 57 257.5 257.1 252.9 269.0 2.8 which does terminate on the same host/network as you, just even in the last few hops a different route than what you're getting. (using the hostname, instead of the IP gives me a route that's 11 hops... The DNS servers resolve the hostname to an IP that's close... ) Anyway, I suspect that mtr uses a slightly different packet type than what traceroute uses. There are commandline options to try to change the packet type. Please report if that helps. If so, That's your solution: If you don't reach the final hop, try a different packet type. If it doesn't help it seems unlikely that this leads to a change in mtr, but I'm interested to see a packet trace of when MTR does its thing to compare it to when traceroute does its thing. use mtr -r -c 3 google.com as the commandline for mtr. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[zhiduopc]

mtr -r -c 3 baidu.com
Start: 2023-12-24T23:20:11+0800
HOST: Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 3 8.6 10.4 8.6 13.2 2.5
2.|-- 10.254.41.1 0.0% 3 7.8 5.6 2.0 7.8 3.1
3.|-- 10.254.11.1 0.0% 3 7.3 3.3 1.3 7.3 3.4
4.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
5.|-- 192.168.22.10 66.7% 3 12.9 12.9 12.9 12.9 0.0
6.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
9.|-- 58.217.46.77 66.7% 3 4.3 4.3 4.3 4.3 0.0
10.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
13.|-- 221.183.128.141 33.3% 3 25.7 27.8 25.7 29.9 3.0
14.|-- 221.183.94.21 66.7% 3 26.7 26.7 26.7 26.7 0.0
15.|-- 221.183.49.130 0.0% 3 28.5 28.1 25.7 30.0 2.2
16.|-- 111.13.0.174 0.0% 3 24.8 25.8 24.7 28.0 1.9
17.|-- 39.156.27.5 0.0% 3 27.8 28.1 27.6 28.9 0.7
18.|-- 39.156.67.17 0.0% 3 24.2 24.6 23.7 25.9 1.1
19.|-- 10.166.51.65 0.0% 3 29.9 27.8 25.5 29.9 2.2
20.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
21.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
22.|-- 10.166.3.10 0.0% 3 32.0 32.5 29.1 36.5 3.7
23.|-- 39.156.66.10 0.0% 3 23.4 23.3 23.2 23.4 0.1
My traceroute [v0.95]
localhost -> baidu.com (110.242.68.66) 2023-12-24T23:21:09+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev

1. _gateway 4.2% 24 6.3 3.8 2.5 7.9 1.6
2. 10.254.41.1 0.0% 24 2.1 4.4 2.0 12.7 3.1
3. 10.254.11.1 reply) 0.0% 24 2.5 3.1 1.1 22.0 4.4
4. (waiting for reply)
5. 192.168.22.54 41.7% 24 1.2 1.7 0.7 7.7 1.9
6. (waiting for reply)
7. (waiting for reply)
8. (waiting for reply)
9. 222.186.2.189 0.0% 23 27.8 28.5 27.8 32.8 1.3
   The -r parameter is displayed normally, why is this?

[yvs2014]

Paraphrasing the question it's "Why paths to two or three different networks (142., 39., 110.) using two different protocols (udp and icmp) are different". The answer is in the Q itself.

[rewolff]

On Fri, Dec 22, 2023 at 06:07:33AM -0800, zhiduopc wrote: Is it possible that the hyper-v virtual machine caused?

Not really! It seems that on the first few hops we can see correct packets being sent out and the replies being delivered to the application.

…

-- ** ***@***.*** ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.

[zhiduopc]

2023 年 12 月 22 日星期五 06:07:33AM -0800，zhiduopc 写道： 有没有可能是hyper-v虚拟机引起的？
并不真地！ 看来在前几跳我们可以看到正确的 数据包被发送出去并且回复被传送到 应用。
…
-- ** @.*** ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ 代尔夫特，荷兰。 KVK：27239233 ** f 等于 m 乘以 a。 当你的 f 稳定，而你的 m 下降时 你的 a 正在上升。 ——克里斯·哈德菲尔德（Chris Hadfield）关于飞上航天飞机的事。

The weird thing is that the front is normal and the back doesn't show up if it's a real time MTR