ping 广播地址时出现问题

发布于 2024-10-15 04:21:32 字数 1624 浏览 2 评论 0原文

当我尝试对 LAN 上的广播地址执行 ping 操作时,每次都仅显示来自 3 个主机的 ICMP 回复,即使有许多主机连接到 LAN。

对于广播地址,我

$ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1b:38:09:0b:26  
          inet addr:172.30.120.152  Bcast:172.30.127.255  Mask:255.255.248.0
          inet6 addr: fe80::21b:38ff:fe09:b26/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:831096 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:66620362 (66.6 MB)  TX bytes:3099025 (3.0 MB)
          Interrupt:21 Base address:0x2000 

使用了 Bcast addr 172.30.127.255 来 ping 所有人...

$ping -b 172.30.127.255
WARNING: pinging broadcast address
PING 172.30.127.255 (172.30.127.255) 56(84) bytes of data.
64 bytes from 172.30.120.1: icmp_seq=1 ttl=255 time=0.809 ms
64 bytes from 172.30.120.62: icmp_seq=1 ttl=64 time=1.06 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=1 ttl=255 time=3.97 ms (DUP!)
64 bytes from 172.30.120.1: icmp_seq=2 ttl=255 time=0.364 ms
64 bytes from 172.30.120.62: icmp_seq=2 ttl=64 time=0.412 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=2 ttl=255 time=1.48 ms (DUP!)
64 bytes from 172.30.120.1: icmp_seq=3 ttl=255 time=0.452 ms
64 bytes from 172.30.120.62: icmp_seq=3 ttl=64 time=0.506 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=3 ttl=255 time=1.64 ms (DUP!)

为什么只有 3 个主机响应我的 ping。 ifconfig 给出的这个广播地址不是要使用的吗? 我认为这可能是我无法对 LAN 上的系统进行放大攻击的原因。我用朋友主机的欺骗源地址注入了 ICMP-echo 数据包 并将其发送到这个广播地址,很失望地看到他的带宽没有受到影响...

请解释一下...

When I try to ping the broadcast address on my LAN, it shows ICMP replies from only 3 hosts, everytime, even though there many hosts connected to the LAN.

For the broadcast address, I did

$ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1b:38:09:0b:26  
          inet addr:172.30.120.152  Bcast:172.30.127.255  Mask:255.255.248.0
          inet6 addr: fe80::21b:38ff:fe09:b26/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:831096 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:66620362 (66.6 MB)  TX bytes:3099025 (3.0 MB)
          Interrupt:21 Base address:0x2000 

I used the Bcast addr 172.30.127.255 to ping everyone...

$ping -b 172.30.127.255
WARNING: pinging broadcast address
PING 172.30.127.255 (172.30.127.255) 56(84) bytes of data.
64 bytes from 172.30.120.1: icmp_seq=1 ttl=255 time=0.809 ms
64 bytes from 172.30.120.62: icmp_seq=1 ttl=64 time=1.06 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=1 ttl=255 time=3.97 ms (DUP!)
64 bytes from 172.30.120.1: icmp_seq=2 ttl=255 time=0.364 ms
64 bytes from 172.30.120.62: icmp_seq=2 ttl=64 time=0.412 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=2 ttl=255 time=1.48 ms (DUP!)
64 bytes from 172.30.120.1: icmp_seq=3 ttl=255 time=0.452 ms
64 bytes from 172.30.120.62: icmp_seq=3 ttl=64 time=0.506 ms (DUP!)
64 bytes from 172.30.120.50: icmp_seq=3 ttl=255 time=1.64 ms (DUP!)

Why is that only 3 hosts respond to my ping. Is this bcast address given by ifconfig not the one to be used?
I think this might be the reason why I am not able to carry out an amplification attack on a system on my LAN. I injected ICMP-echo packets with spoofed source address of my friend's host
and sent it to this broadcast address, and was disappointed to see that his bandwidth was not affected...

Kindly explain...

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

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

发布评论

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

评论(2

反目相谮 2024-10-22 04:21:32

有些主机根本不响应广播 ping(例如,Windows 默认情况下就是这样配置的)。

Some hosts simply don't respond to broadcast pings (for example, Windows is configured by default this way).

忆伤 2024-10-22 04:21:32

因为在示例中,某些实现通过将广播发送到首选接口来工作,而不是全部。您需要一个中继来发送到所有接口。您可以考虑阅读 RFC 919

Because in example some implementations work by sending the broadcast to the preferred interface, not all of them. You need a relay to send to all interfaces. You may consider reading the RFC 919

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