9
  • Host address: 192.168.0.13
  • Network: 192.168.0.0 255.255.255.0
  • Router: Cisco DPC3825 DOCSIS 3.0 Gateway (user manual)

My home network uses the 192.168.0.0 /24 network for my (mostly wireless) devices. On many other networks I frequent, I'll ping the applicable broadcast address to show all currently live devices in my (Windows 7 x64) results of arp -a. Pinging the broadcast address of a network helps me to identify devices that are currently communicating on the same network.

In my home network, I'm losing 100% of the packets sent to 192.168.0.255. Thus arp -a does not show me all of the devices that are live on my network. All devices connect directly to my router and then out to my ISP.

Why am I unable to ping the broadcast address in this network? Logging into the router directly to check the DHCP Client Table is inconvenient.

Update: These ping attempts are made from a computer directly connected to the router via ethernet. I've attempted the same ping attempts from multiple wireless devices to no avail.

3
  • 2
    Why not use nmap?
    – Daniel B
    Feb 19, 2014 at 13:10
  • 1
    The question is mostly conceptual and for my own understanding, but it would also be convenient to have a native way to update arp without any 3rd party tools.
    – root
    Feb 19, 2014 at 13:27
  • 1
    ARP tables are maintained automatically, there should be no need to do so manually.
    – Daniel B
    Feb 19, 2014 at 13:32

3 Answers 3

13

I think that the times when operating systems responded to broadcasts pings are long gone. As far as I know every modern operating system ignores those requests as a security measure to avoid broadcast storms.

The default in Linux:

$ sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1

If you want to discover machines you'll have to resort to unicast ping (nmap, ping loop or other means), but note, there can be machines configured to always ignore ping requests.

2
  • On the current 10.2.1.0 255.255.255.0 network I'm on, pinging 10.2.1.255 yields 100% packet return and updates my arp table with previously undiscovered clients.
    – root
    Feb 19, 2014 at 13:10
  • @root if you are getting 100% return that means only one computer is replying, you should get "100 * number of computers on the network"% packets back. Besides that, the network you are currently on may just be filled with computers that had their firewall settings to allow for broadcast ping (if this is a corporate domain it could be very easily done with active directory) Feb 19, 2014 at 14:11
4

It has already been discussed that answering pings to broadcast addresses is not considered good practice anymore. You could alternativly ping the all-host multicast group which uses the IP 224.0.0.1. In theory every multicast capable host should respond to a ping to this IP, but I've heard of hosts not doing so.

For more on multicast addresses read the tldp: http://www.tldp.org/HOWTO/Multicast-HOWTO-2.html

Another option would be to just unicast all IP addresses in your network segment which can easily be achieved by using built-in tools on most systems. I only really know GNU/Linux and MS Windows, so I can only give you examples for those systems.

GNU/Linux

for lastoctet in $(seq 254); do ping -c 1 192.168.0.$lastoctet; done

MS Windows

for /l %i in (1,1,254) do ping -n 1 192.168.0.%i

Not as easy as ping 192.168.0.255 but it does work under most circumstances.

0

With reference to what #Jorge Nerin said:

Set the ignore parameter to 0. ie;

$ sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts=0

Do this with root privilege on all devices in the network. It will allow responses to broadcast pings.

PS : doing this may pose a security threat.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .