As part of our Understanding Networks class, we looked into packet sniffing over WiFi networks. I downloaded Wireshark and Herbivore for this exercise. For the entire duration of this experiment, which took place over a couple of days (non-continuously), I was the only one at home, and only my devices were connected to the network.
One minor thing to note about Herbivore was that the release build didn’t work on my machine (Mac OS 10.12.5). I had to build it manually (which wasn’t hard).
I first connected the macbook I borrowed from ITP and my Android phone to my home network. Here’s the network view from Herbivore.
Before I continued, I wanted to check how Herbivore reacted when new devices connected. So I connected an old iPad to the network. Herbivore didn’t refresh automatically, so I restarted it and it showed up.
I then looked at the packets going in and out of my laptop (same device on which Herbivore was running). At this point, I was installing some npm packages, had github open on a browser. I also noticed atom (the text editor) sending/receiving packets, possibly checking for an update. One note on Herbivore’s interface – the ‘current target’ section in the image below shows that I’m connected to my phone, despite actually showing my old packet records from the previous target (the laptop).
Packets from other devices on the same network
Next, I wanted to check how it worked with a device that’s not running the sniffing program. I opened up the browser on my iPad. It picked up pretty much what I expected. The iPad opened up tabs that I hadn’t closed from my previous session: google search and an article from opennews.org.
use.typekit.net was probably used to load fonts on the opennews.org page.
I then opened up a few apps on the iPad (NYTimes, app store, a sudoku app). The sudoku app used hockeyapp and also tried to hit google’s servers (possibly to try and retrieve personal game data).
I also tried accessing my wordpress backend from my iPad for my blog which doesn’t use https. Unsurprisingly, as we saw in class, I could see my username and password as plaintext on Herbivore when the post request was sent.
Packets from LIFX bulbs
I then wanted to see how an IoT device would behave over the network. I plugged in my LIFX bulb (which I usually don’t have plugged in).
The screenshot below is how it shows up on Herbivore (the other Samsung device was my old phone with which I also ran some similar experiments).
Before I move on, here’s how LIFX bulbs currently work:
With a new LIFX bulb, you first download the app on your phone or tablet, then connect to the bulb’s WiFi. While on the bulb’s WiFi, you send information about your home WiFi (which needs to be connected to the internet). Then, the bulb and your device are connected to the internet and you control your bulb over the internet.
I’m not sure if I remember correctly, but there used to be a time when one could control the LIFX bulbs directly over the bulb’s network using UDP (I may be mistaken here for something else though).
Here are the packets that my iPad sent to LIFX’s server when I tried to set a daily timer on the bulb.
A thing to keep in mind for the next couple of pictures is that IP address associated with cloud.lifx.com (18.104.22.168).
Surprisingly, I did not see any packets associated with the bulb on Herbivore, despite the bulb reacting to my colour change commands from the iPad.
So I opened up Wireshark to see what it saw (filtered just the packets associated with the bulb’s IP address). Notice that packets are going back and forth between the bulb and that same IP address associated with cloud.lifx.com (22.214.171.124).
A quick whois lookup reveals that IP address to be google’s cloud service (in California). And these packets keep going back and forth even without any intervention from the user. I left the bulb on with no pre-timed settings, turned off the iPad, went out for a walk, came back and noticed the bulb still sending and receiving (mostly TCP) packets from that IP address.
I tried a few other things, but for this post, I’d like to show one last experiment – arp packets over the network. I tried running the arp command whilst WiFi sniffing. Here’s what showed up.
This really illustrates how the arp command works – by broadcasting questions to every possible IP address that the router allows, and waiting for responses.
I found it interesting that LIFX chose to connect all their bulbs over the cloud when it could be local. I’m not sure why anyone would want to control their lights remotely (but maybe I’m wrong).
This didn’t strike me at the time, but another thing I’d like to try would be to see the packets moving around when the LIFX bulb is being set up (with the bulb as the router).