Dear JDisc friends,

we have nearly finished a new feature. We will be able to get MAC addresses from devices in remote networks.

That doesn’t sound too spectacular, does it? However, this is a pretty important feature and I am going to explain why. Furthermore, it is not that easy to obtain mac addresses for each and every device.

There are two important reasons to get the mac addresses for as many devices as possible:

1. Derive the manufacturer from the mac address
   Usually, the first three octets of a mac address identify the vendor. There are a lot of web pages to identify the manufacturer based on the mac address. One example of such a service is
   https://www.macvendorlookup.com/.
   You can also download the mac address to manufacturer database from various web pages. We have integrated the mapping in our product. This enables us to identify the manufacturer. Whenever JDisc Discovery has no access credentials or the device does not expose any standard protocol, then the device appeared as an unidentified device. However, with the mac address, we can at least resolve the manufacturer.
2. Create a proper network topology
   Mac addresses are essential for creating a proper network switch topology. Switches are network layer 2 devices and thus work with mac addresses. Each switch maintains an internal mapping table that maps mac addresses to switch ports. This mapping table (e.g. downloadable from
   https://macaddress.io/database-download/csv) can be used to determine what device is connected to which switch port. The prerequisite is that you also have the corresponding mac address for a device. So it is essential to determine for as many devices the corresponding mac address! Without the mac address, the switch port assignment for devices cannot be done!

However, it is not always trivial to determine the mac address for a given IP address. When the device’s IP address resides within the same network segment as the discovery computer, then it is not difficult to obtain the device’s mac address. Simply ping the IP address and then run an ARP command to read the current ARP cache.

The example above illustrates how it works. First, you ping the desired IP address (in this case 192.168.178.1). That will populate the local ARP cache with the corresponding mac address (here: cc:ce:1e:b4:40:01). Now you can use this mac address and use any page to lookup the vendor.

We can determine based on the mac address that the vendor for this device is a Germany based company named “AVM”.

But what happens when you try to look up the mac address for an IP address that resides in a different network. If you are familiar with basic IP networking, then you know that the approach described above does not work for remote networks that are connected via routers. The ARP request will not return the mac address for remote IP addresses.

As I mentioned before, you need to be on the same subnetwork in order to obtain the mac address. Therefore, we have implemented a kind of jump host solution to obtain mac addresses. Let’s assume, we have discovered a Windows or Linux server in the remote network. What we could do is logon to the Linux server in the remote network using SSH. Then you can ping the target IP address from the Linux server and use the Linux server’s ARP command to obtain the mac address for the desired IP address. The Linux server is used in this scenario as a kind of jump host to obtain the mac address.

The image above illustrates how the discovery gets the mac address. First, it chooses a suitable Linux or Windows server within the remote network. Then it connects via SSH or Remote Login Agent to the remote computer. Once it is connected to the jump host, it pings the target IP address and then runs the ARP command on the jump host to determine the mac address.

The above dialog illustrates where to configure the remote ARP jump host usage. When enabled, you can also configure the number of worker threads for each network. Each worker thread is able to perform one ARP request at a time. We can have multiple worker threads to speed up the discovery when multiple devices are being scanned in parallel.

This feature will be released with build 5017 pretty soon and hopefully, this feature improves the network topology and provides some more information on so far unknown devices.

Cheers,
Thomas