[understanding networks week 5] packets and mysteries

This week, we were to analyze traffic on our networks at home using Wireshark. So to begin, I had Wireshark capture one minute of packet activity on my wifi network at home.

In just 60 seconds, it captured 6894 packets! Seems like a lot, given that I probably browsed one or two sites in that minute, but I guess that reveals how much is going on in the background when I think I’m not even doing much. The total protocol counts were:

DNS: 65
IGMPv2: 2
QUIC: 113
SSDP: 41
STP: 33
TCP: 4809
TLSv1.2: 1805
UDP: 21

As you can see, most of it was TCP. I am not entirely sure what was causing these – I did a whois lookup on some of the IPs, and saw some familiar names: Amazon, Verizon, Facebook (which I don’t actually have, must have been Instagram…). Still, I was wondering if maybe Tweetdeck (a desktop Twitter client) was a source of such a high number of packets, but I wasn’t sure how to confirm it.

Another experiment I did was to check on the packets coming to and from my Raspberry Pi sitting in my living room.

My pi takes a picture of one of my house plants every morning and tweets it out from @grow_slow at 10:17 am. The only other thing it does it reboot itself at 10:00 am. So I turned on Wireshark and filtered it for the pi’s IP…


And just as I suspected, it didn’t do much just sitting there. So I tried ssh-ing in from my laptop to see what would come up.screenshot-2016-10-10-16-25-01

It still surprises me how many packets are required just for one ssh login. I also then tried logging in via FTP:


Something I didn’t expect was that Wireshark revealed my username and password when I used FTP. (As you can see I haven’t changed them from the defaults, oops. But to any potential hackers reading: I’m changing it!!).

Because my python program on my pi is set to tweet at 10:17 am, I waited until the time, expecting to see some packets, but…nothing showed up, even though the tweet successfully posted. In fact the only thing that would show up was these, which occurred every few minutes:

screenshot-2016-10-10-16-32-01  I also found that my laptop also sent a packet to the same IP with the same protocol. From reading a bit about the Internet Group Management Protocol, it sounds like it’s a way to forward the same IP packets to a number of hosts within a network. My guess is that both my pi and my laptop are telling the router that they’re available for multicast?

One last random curious thing I found: when I was ssh-ing in to my pi from my laptop, I noticed that it was sending packets while I was typing on the command line, not just when I submitted a command, which is not what I expected.

My understanding still feels very fuzzy, and I don’t know why I didn’t see any packets coming to or from my pi when I run the program that tweets. I think it’ll take me a little more time and research to feel like I’m starting to really understand this.

[understanding networks week 2] Traceroute Commute


(See the project here.)

For me, the most fascinating part of learning the traceroute command this week was the idea that each IP address the packets move through is tied to a physical place in the world. It was interesting to see the common network providers in the sites I regularly visit, but I became mostly curious about the locations they were associated with.

I decided to trace three websites of places that I have regularly commuted to in real life, including ITP (Greenwich Village), and my two most recent jobs at The New York Times (Times Square) and Kickstarter (Greenpoint). All three of these places are located in New York City, but running a traceroute shows that the packets bounced around to more far-reaching places in order to get to their respective websites.

I started by running the traceroute command in my command line:


I then used Maxmind to find the associated coordinates and other info based on IP addresses:


I then put all that data in a CSV file, which I changed into JSONs to make the data easy to work with.

From there, I used the Google Maps API to build a little page that would find a streetview location for every IP address passed through during the traceroute for itp.nyu.edu, kickstarter.com and nytimes.com.

The result is a sort of internet “commute” for the places that I have physically commuted to.


Of course these places aren’t exactly “accurate,” but it’s interesting, for example, that the last stops for both nytimes.com and kickstarter.com are in Seattle, probably because Amazon is there.

One note: I think it’s kind of funny how much more time my real world commute takes than this cyber commute, in spite of ostensibly shorter distances.

Anyway, this was a fun exercise in making the internet feel a little more physical.

The project is here, and the code is below.