Building the Presence tool at IMG
Software development is an intricate task. More often than not, it involves processes, ideals, and software which although do not affect the end-user program in a truly quantifiable way, make the software development cycle much more efficient and sustainable. Internal tools are pieces of software which, in the very crude sense, help in the day-to-day operations of any good organisation. At IMG as well, we use a lot of internal tools. Some of which are developed and maintained by us while others are open source or freely available software. Be it Slack for communication, Sentry for error tracking, Stream for collaboratively setting the lab vibe, GitLab as our Git-repository manager or Amon as our server monitoring application, all of these have become essential for the smooth maintenance of Channel i and the IIT Roorkee website.
This blog is about the technical aspects of a similar internal tool named Presence. Presence is a tool that we use to see the names of the people that are currently present in the lab. Built with the help of many folks at IMG, the main idea behind Presence was that, at many times we needed to know the members that are currently present in the lab so that a query can be redirected to them. Because of this, our Slack channel was filled with the queries like “Who is there in the lab?”, “Lab anyone?”, etc. Something had to be done to rectify that. So, one day we sat down to search for a solution.
It is a commonly known fact that you can scan for the IPs that are currently being used inside a network using nmap. However, it is a lesser known fact that if you run nmap with the superuser permissions, you can expect a lot of extra information and in many cases, different results. For the people who don’t know what nmap is, nmap is an open-source and the most widely used network scanner. It is one of the best network-mappers around there owing to its large developer community. The difference in the results when you run nmap with superuser privileges is that it gives nmap the ability to create raw sockets. So, what are raw sockets and how do they help nmap to extract extra information?
Before explaining what raw sockets are, let me introduce the concept of sockets in terms of network programming. Sockets are an abstraction that sits over the networking layer implementation of the OS and helps the network programmers code their applications without any deeper knowledge of the internals of TCP/IP, UDP or ICMP for that matter. Sockets are implemented at the OS level and provide easy to use endpoints to construct various types of packets. Some of the types of packets such as a TCP or a UDP packet can be created easily without any superuser permissions, but for packets like ARP or ICMP, you need to create raw sockets. These raw sockets can only be created by the superuser. These packets allow nmap to gather extra information about the hosts that you are currently scanning.
By utilizing ARP packets, nmap gathers the information about the MAC address (or the Network Address) of a system corresponding to its IP. ARP is a network layer protocol that is used to find the corresponding MAC address for a particular IP. Generally, this protocol is used for routing packets as MAC addresses are the only thing that differentiates one device on a network from other. IPs are mostly dynamically allocated and so are not a reliable way of distinguishing among different devices on a network. The router also maintains a cache of IP addresses corresponding to the MAC addresses and refreshes it periodically. So, nmap uses these ARP packets to find out the corresponding MAC address to the IP that is currently connected to the network. As MAC addresses are mostly unique, we get conclusive information about the devices connected to the network.
Now, all that remained was writing a script that did all this. That was the easy part, you just needed to make a system call that ran nmap for you and stored the results in a file. The file then could be parsed for the MAC addresses. Now, that we had the MAC addresses of every active user connected to WiFi at that point, we now had to somehow map that MAC address to the corresponding user and show it somewhere where it is publicly accessible. I was a lot into Slackbots at that time, so I thought of making a similar bot for this. Generally building a Slackbot is a very easy job. You just need an activation phrase set and slack will make a request to a predefined URL with the message as the context and fetch the results. So, we needed an API.
I was learning Django REST Framework at that time, so went ahead with that. Although a much lighter framework such as Flask, or Tornado would have been much more suited for the task. But I wanted to learn something new, so I went ahead with Django. I built the API which first listens to POST requests on a certain URL on which my computer which is doing the ARP scanning and will report the name of the members present. On the other URL, it will respond to incoming Slack requests. This way the member table was updated and whenever a member of IMG wanted to know the members that were currently present in the lab, they just had to type presence into the slack channel and voila, you get the names of the people currently in the lab.
An idea that looked to solve a trivial problem being faced by the members of IMG and which involved only a night’s coding, Presence has become an essential part of the bandwagon of internal tools at IMG. Almost two years into running, Presence has been understood, developed and improved upon by a lot of IMG members while still continuing to be one of the most widely used tool by every IMGian.
