7
  • 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.

|improve this question
  • 1
    Why not use nmap? – Daniel B Feb 19 '14 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 '14 at 13:27
  • 1
    ARP tables are maintained automatically, there should be no need to do so manually. – Daniel B Feb 19 '14 at 13:32
9

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.

|improve this answer
  • 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 '14 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) – Scott Chamberlain Feb 19 '14 at 14:11
3

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.

|improve this answer
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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.