traceroute显示星号,但是wireshark抓包显示返回了icmp type 11

发布于 2022-08-31 20:58:41 字数 494 浏览 15 评论 0

$ traceroute -q1 -m5 -n www.163.com                                         
traceroute to www.163.com (218.213.235.236), 5 hops max, 60 byte packets
 1  192.168.1.1  24.030 ms
 2  192.168.137.1  23.946 ms
 3  *
 4  *
 5  *

wireshark抓包

traceroute命令后三跳都显示为星号,但是wireshark抓包显示都返回了icmp type 11。
请教这种情况是什么原因,为什么没有显示10.18.107.1,10.16.0.1和10.16.0.10?
多谢!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

时间海 2022-09-07 20:58:41

traceroute 的原理是通过发送几个 TTL 不同的 UDP 包,然后期待收到 ICMP type 11 的回应,借此来探测中间节点 IP。

traceroute 2.0.21 源码来看,有几点可以确认:

  • 仅当超时这一种情况下 traceroute 才会打印 *
  • 使用 SOCK_DGRAM 创建 socket,并且启用了 IP_RECVERR
  • 每个 UDP 报文都是一个单独的 socket;
  • 使用阻塞的 poll 来轮询,仅当 POLLERR 事件发生的时候才尝试接受 ICMP;
  • 如果 socket 在预定的等待时间里没有收到 ICMP,主动关闭 socket。

所以,traceroute 显示 * 但 ICMP 却又实际已收到,有几种可能性:

  • ICMP 超时;
  • 收到 ICMP 但是 poll 没能获得 POLLERR 事件;
  • 底层对应出错,ICMP 没有放入 socket 的错误队列中,或许这个包被别的 socket 给收走了。

从题主的几次抓包来看,不是 ICMP 超时,但无法确认后两点,可以考虑下载 traceroute 源码调试一下,加几个 printf 输出额外信息,看看究竟是哪个环节出问题。源码本身不是很复杂,只要在 traceroute/mod-udp.c 里面加些调试信息就可以很清楚的定位问题了。

由于我这里始终找不到一个能重现问题的 IP,所以无法定位根本原因,抱歉。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文