Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zhiduopc opened this issue Dec 21, 2023 · 6 comments

Comments

@zhiduopc
Copy link

zhiduopc commented Dec 21, 2023

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
Copy link
Collaborator

rewolff commented Dec 22, 2023

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
Copy link
Author

zhiduopc commented Dec 22, 2023 via email

@zhiduopc
Copy link
Author

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
Copy link

yvs2014 commented Dec 29, 2023

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
Copy link
Collaborator

rewolff commented Dec 30, 2023 via email

@zhiduopc
Copy link
Author

zhiduopc commented Jan 3, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants