How do I use Linux to find unused IP addresses on my network?

Question

I've got access to two computers (A and B) on a network. Both have got a static IP address with a subnet mask of 255.255.255.128 (I checked that a DHCP server was not being used). I want to configure multiple IP addresses to the same machine and hence I want to know what all IP addresses are already being used in the subnet.

From an earlier question, I tried nmap -sP -PR 172.16.128.* command, but, I'm skeptical about its result as the same command gives different results on my two computers (A and B). On A, the result shows, a list of 8 IP addresses which are (supposedly) already being used, including that of A and B.

Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds

But on B, the result is different i.e.,

Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds

The result on B is not even showing its own IP address as well as the IP address of A!

What exactly am I doing wrong here? Is there any foolproof way in Red Hat Linux (RHEL) of discovering all IP addresses being used in the subnet of which my computer is a part of?

RHEL: 6.5
Nmap version: 5.51

Solution 1

Any well-behaved device on an Ethernet LAN is free to ignore nearly any traffic, so PINGs, port scans, and the like are all unreliable. Devices are not, however, free to ignore ARP requests, afaik. Given that you specify you're scanning a local network, I find the least-fragile method of doing what you want is to try to connect to a remote address, then look in my ARP cache.

Here's a simple, non-filtering device (ie, one which isn't configured to ignore some classes of IP traffic):

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.351 ms
[...]
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.1
? (192.168.3.1) at b8:27:eb:05:f5:71 [ether] on p1p1

Here's a filtering device (one configured with a single line of iptables to ignore all traffic):

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.31
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.31
? (192.168.3.31) at b8:27:eb:02:e4:46 [ether] on p1p1

Here's a device that's just down; note the lack of a MAC address:

[me@risby tmp]$ ping -c 1 -W 1 192.168.3.241
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.241
? (192.168.3.241) at <incomplete> on p1p1

This method's not infallible - it misses devices that are turned off, for one thing - but it's the least-dreadful method I've yet tried.

Edit: Eric Duminil, yes, it only works on a local network; see paragraph one.

Vishal, the methods are functionally identical. Note the text quoted in Leo's answer about nmap:

When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified.

His method involves less typing. Mine can be done without privilege, and may give you a better understanding of what's actually happening. But the same thing is done on the wire in both cases.

Solution 2

Since a device cannot ignore ARP requests, I like to use a tool named arp-scan. It is available in most repositories.

When you run the command with the --localnet switch it will give you an overview of your entire internal network.

sudo arp-scan --localnet

Gives me a list of all IP -and MAC addresses on my network. It is also possible to specify a network range to scan.

sudo arp-scan 172.16.128.0/25

If you have multiple network interfaces configured you can specify the one you want to use with the switch -I.

sudo arp-scan -I eth0 172.16.128.0/25

More information about possible switches can be found at https://linux.die.net/man/1/arp-scan or by running man arp-scan.

Solution 3

Part 1 -- fping

This tool pings everything in the network range specified, and shows those that answer via ICMP.

root@thionite:~# fping -a -g 10.28.1.0/24
10.28.1.1
10.28.1.2
10.28.1.3
10.28.1.4
10.28.1.5
10.28.1.12.....

Part 2 -- arp

Since fping talked with everything on the LAN, that will have caused an entry to be added to the system's ARP table. Read it out within a couple of minutes, because the arp table flushes old entries.

root@thionite:~# arp -a | grep -v incomplete
? (10.28.1.1) at 00:0d:b9:35:29:c4 [ether] on eth0
? (10.28.1.2) at 68:05:ca:10:53:5f [ether] on eth0
? (10.28.1.3) at d2:f1:6e:54:05:22 [ether] on eth0
? (10.28.1.4) at 00:1a:4d:26:85:ee [ether] on eth0
? (10.28.1.5) at 6e:a6:e5:78:da:ca [ether] on eth0
? (10.28.1.12) at 3c:4a:92:76:85:d8 [ether] on eth0

Also note that the ARP table has a maximum size and the kernel will evict old and low usage entries.

Put it all together with

 fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt

then browse arp.txt at your leisure.

Solution 4

IPv6

Don't assume that IPv4 is your only option. Many modern operating systems handle IPv6 just fine, even if your ISP doesn't provide V6 connectivity.

There may even be devices which are only reachable by IPv6, or even other protocols.

There's a bunch of handy multicast addresses documented in https://en.wikipedia.org/wiki/Multicast_address#IPv6 But the interesting one for you is ff02::1

root@thionite:~# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::4261:86ff:fec4:cbaa%eth0 eth0: 56 data bytes
64 bytes from fe80::4261:86ff:fec4:cbaa%eth0: icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from fe80::21a:4dff:fe26:85ee%eth0: icmp_seq=1 ttl=64 time=0.215 ms (DUP!)
64 bytes from fe80::6a05:caff:fe10:535f%eth0: icmp_seq=1 ttl=64 time=0.233 ms (DUP!)
64 bytes from fe80::226:55ff:feda:299c%eth0: icmp_seq=1 ttl=64 time=0.334 ms (DUP!)
64 bytes from fe80::20d:b9ff:fe35:29c4%eth0: icmp_seq=1 ttl=64 time=0.501 ms (DUP!)
64 bytes from fe80::21e:c2ff:fe13:36bf%eth0: icmp_seq=1 ttl=64 time=0.512 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=0.518 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=0.757 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=0.772 ms (DUP!)
64 bytes from fe80::60cc:69ff:fe4f:7db0%eth0: icmp_seq=1 ttl=64 time=0.992 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe32:3232%eth0: icmp_seq=1 ttl=64 time=1.00 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe30:3030%eth0: icmp_seq=1 ttl=64 time=1.24 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe31:3131%eth0: icmp_seq=1 ttl=64 time=1.34 ms (DUP!)
64 bytes from fe80::6ca6:e5ff:fe78:daca%eth0: icmp_seq=1 ttl=64 time=2.35 ms (DUP!)
64 bytes from fe80::b639:d6ff:feab:1000%eth0: icmp_seq=1 ttl=64 time=7.04 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=8.02 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=8.03 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=8.06 ms (DUP!)
64 bytes from fe80::212:12ff:fef7:8044%eth0: icmp_seq=1 ttl=64 time=8.24 ms (DUP!)
64 bytes from fe80::8edc:d4ff:fef2:67e0%eth0: icmp_seq=1 ttl=64 time=18.3 ms (DUP!)
64 bytes from fe80::21e:c2ff:fea9:6d71%eth0: icmp_seq=1 ttl=64 time=295 ms (DUP!)
...repeats

Solution 5

In addition to MadHatter's answer, there is a tool does the arp lookup without trying to send a network packet first: arping.

There seem to be two implementations:

• arping (Thomas Habets version).
• arping (iputils version)

For your purpose I would just take the package from your linux distribution as the differences are probably only in the details.

View more solutions

Comments

[Eric Duminil]

This only works with devices in the same local network right? I tried it on a server of mine, ping requests are dropped somewhere inbetween and I cannot find any relevant line with arp.

[Vishal Sharma]

Thanks for the response. I just wanted to know how does your method compare to that of @Leo? Is it better than that in some way(because otherwise it's easier to use just one command).

[Vishal Sharma]

Looks like a promising tool, but, it does not come with RHEL 6.5(in my case atleast it's absent).

[MadHatter]

@VishalSharma , EricDuminil : see edit above.

[Vishal Sharma]

Just to be clear, does it mean that @Leo's method will be similar to yours only when used by a privileged user and hence when it's used by an underprivileged user, it's result will not be complete/incorrect? Also, by privileged user do you mean, a user having sudo access?

[MadHatter]

@VishalSharma the first part of your comment is correct. Privileged user includes doing something under sudo -u root (often shortened to sudo), but also simply being logged in as root, or having done /bin/su, hence the umbrella term.

[d a i s y]

Why different answer? You can edit post

[Thorchy]

@VishalSharma That's unfortunate. It's available for CentOS so I would have thought that it should also be available on RHEL.

[Criggie]

@daisy because they're different answers. One monolithic answer might be good but gets held down by one part. Separate answers allow the up/down voting mechanism to work properly. This answer was really only for completeness, its not very useful in practice.

[Rob Moir]

The only thing that ping tests is whether or not a device is configured to respond to pings.

[mattdm]

It is in EPEL, Fedora's Extra Packages for Enterprise Linux.

[Criggie]

@RobMoir true - the main point of this is that the broadcast address exists and that it was designed into IPv4.

[lsd]

To me, though, that means you really can't find unused addresses... All you can say for sure is at that moment, these are the addrthat are currently responding (counting arp responses), which is not the same thing.... Proper documentation or configuration management can't be substituted.

[MadHatter]

@lsd I agree, but this isn't a perfect world, and sometimes (read: about every other month) I walk into a new client network which has grown organically, and it's my job to write that documentation, and sort things out. I have to start somewhere.

[allo]

What about using arpping instead of sending a packet and then reading the arp table?

[MadHatter]

@allo firstly, for the avoidance of doubt for others, it's arping, not arpping. Other than that, it seems entirely equivalent, so that would work just as well. You should write that up as an answer, I'd upvote it!

[allo]

I added it as answer.

[Thorchy]

@joshudson I'm pretty sure that it's impossible for any tool/software to scan the network for unused IP addresses when LaBrea is running.

[joshudson]

@Thorchy: Try nmap.