Packet Sniffing

The assignment this week is to capture and analyze network traffic while going about our usual network activities. Before buying my first MacBook in 2016, I was still using a hunky 8 lbs Sony Vaio that was stretched past the end of its life. It was a present from my parents for college and in its early years, it worked like a dream. About four years in, it started showing its first signs of decline when the battery charger suddenly blew out while I was living in Tokyo. I had to replace the charger for it three more times, and my encounters with the blue screen of death were so frequent that I found it unusual if my laptop didn’t crash at least once a day. I thought it might be interesting to run the same applications I typically run on my Mac vs PC and see if I find something interesting on Herbivore and Wireshark.

Something I didn’t expect to find out through Herbivore when I got back to my apartment today is that my roommate is not home. She is typically home before I am, but when I ran Herbivore, I saw that only my devices are connected to our router.  It’s probably best this way so there are no…temptations.

I started by clearing all my applications on both laptops so I could see the packets as they come in on both Herbivore and Wireshark. I opened up a couple websites that I apparently frequented in 2016 on my PC, then gave myself five minutes to just surf mindlessly on my MacBook. In Herbivore, I noticed that the packets I was seeing between my Mac and PC were the same. At first, I was a little confused because I was under the impression I would only see activity filtered by the IP addresses but it turns out that it picks up on all activity communicating with my router. I like that I’m able to see all the devices on my network, but it would be helpful if I could filter the data the way Wireshark allows.

The funny thing is, after I moved on to Wireshark, I tried filtering for the activity of my PC and got nothing. I didn’t understand because they were all there on Herbivore??

Then I remembered reading Ellen’s blog post this morning (best documentation/investigative journalism I’ve ever read) about a similar experience she had while doing this assignment. Apparently, Apple changed their network card configurations to only see what packets are sent to them. Ellen then ran ARP to see the communication between her Macbook and other Apple devices and sure enough, she saw them. In my case however, since Apple doesn’t pick up on non-Apple devices, I only see the communication between my MacBook and router:

I went to download Wireshark on my PC and got a prompt saying that the new release doesn’t support Windows Vista and to download WireShark 2.2 instead. Unsurprisingly, after I tried to run it, my PC crashed. I attempted again and it crashed again so I decided to give it a rest. Poor thing.

Something interesting I noticed is that the majority of my packets use TCP protocol. This surprised me because I purposely opened up an insecure HTTP movie streaming website to see some UDP protocols. Considering how poor the video quality often are on these websites, I assumed UDP protocol might have something to do with pixelated and missing frames. When I filtered for HTTP, I came across some bad TCPs for putlockers.cm:

From Tom and Shawn, I learned that TCP protocols are reliable, so it surprised me to learn that there are “bad” TCPs. I did some research and it turns out this packet [TCP Spurious Retransmission] just means that the sender thought they were lost and sent them again, even though the receiver sent an acknowledge packet for it.

References:

Ellen Nickles

Spurious Retransmission

TraceRoute from Coffee Shops

Blog post updated 10/05/2018.

The websites I most frequent are Youtube and Facebook. I decided to collect my data from the work spaces I frequent – coffee shops La Colombe, Starbucks, and The Bean. When typing traceroute into command line, it spits back a lot of information. I’m only interested in the IP address of each hop, so I referenced ITP alum Patrick Presto’s documentation and made the same modification to the command line to print only the IP addresses each hop:

After collecting my data, I looked up all the IP addresses on ipinfo.io and converted them to JSON files. I later learned from Vidia that you can literally make csv files in a matter of seconds and I felt silly for spending so much time formatting and validating each JSON.

I then used p5.js to plot all the hops to better visualize the path. I later noticed that the results don’t really vary by changing my location since all the coffee shops I frequent are in close proximity to each other.

Facebook from La Colombe and Starbucks:

Time Warner (New York City) > Time Warner (Englewood, Colorado) > Cheney, Kansas > Facebook (Upper Peirce Reservoir, Singapore) > Facebook (Dublin, Ireland) > Cheney, Kansas > Facebook (Dublin, Ireland)

I was getting free wifi from Blink when I was at La Colombe and Starbucks’ free wifi. Both are on Time Warner so the hops went to the same places. It makes sense that Dublin and Singpore are on the map because FB has offices in both countries, but to be honest, I initially assumed it would be a more straightforward and domestic route from New York City and Menlo Park, California.

Facebook from The Bean

New York University (New York City) > Cheney, Kansas > Facebook (Dublin, Ireland)

This path was more straightforward as it bounced around the NYU network, made its way to Cheney, Kansas and Facebook’s Dublin office before appearing before my screen. I was wondering why I kept seeing Cheney Reservoir in my results, and thanks to Lucas’s investigation and explanation, it makes total sense.

Youtube from La Colombe & Starbucks:

Time Warner (New York City) > Time Warner (Cheney, Kansas) >Time Warner (Englewood, Colorado) > Time Warner (Cheney, Kansas) > Time Warner (Englewood, Colorado) > AS6453 TATA Communications (New York City) > Google LLC (Cheney, Kansas)

Again, both were on Time Warner so the paths are the same.

The Bean

New York University (New York City) > New York University (Cheney, Kansas) > AS6453 TATA COMMUNICATIONS (Jersey City, New Jersey) >AS6453 TATA COMMUNICATIONS (Cheney, Kansas) > AS15169 Google LLC (Herriman, Utah)

Ball Drop Socket Game

Our assignment this week was to build a game controller that can connect to a Wifi network and server using a TCP socket  connection to play a multiplayer game that resembles pong. Once the player is connected, his/her IP address will appear within a bar that acts as a paddle to keep the ball from hitting the ground. The objective of the game is to score points by bouncing the ball back and forth between players.

This assignment reminded me of the first assignment from Tangible Interactions last semester — Lunar Lander Game Controller. Since I had a lot of fun building that game controller, I was comfortable with starting on the project and thinking about the UI/UX pretty early on. After Tom set up the server in the hallway, I was able to successfully connect and play the game after changing the IP address in Tom’s Joystick Client code and uploading to a MKR1000.

Next up is designing the user interaction and interface. This is always my favorite part of doing physical computing. I want to always challenge myself against using more conventional sensors/switches so I can learn something new. I originally liked the idea of using a hand-controlled potentiometer for LEFT/RIGHT and a foot pedal potentiometer for UP/DOWN. It’s an interface I’m very comfortable with given my experience with sewing machines. Unfortunately, when I tried wiring it up on a breadboard with a 3.5mm TRS Audio Jack Connector, I kept getting erratic readings in the serial monitor that sometimes not only printed ‘u’ or ‘d’, but random ASCII. This really concerned me and I couldn’t find related documentation online so I decided to set the foot pedal aside for a future project. In retrospect, there’s a chance I didn’t ground it properly (although I followed Adafruit’s instructions to connect one side to ground and the other side to a 10K resistor pull-up to 5V). I’m certain of it now that had I switched from jumper wires to 22-AWG hook-up wires at this prototyping stage, it would have saved me a lot of headache later on.

I ended up going with an ultrasonic sensor (HC-SR04). The clear distinction between the twisting motion mapped to left/right and hovering motion to up/down makes for an intuitive interface:

The problem was, it didn’t work together. I can’t recall how many times I rewired, altered the code, and tested the sensors individually. Koji was very patient and helped me try every combination to debug this controller. Nothing seemed to work until he suggested that we use different wires (providing his own anecdote of dealing with flimsy, unreliable wires in the past). Haley stopped by to also suggest connecting the power rails because apparently, they are not always connected in the long breadboards!

 We replaced some of the wires but it still didn’t resolve this issue. It was midnight at this point, so I told Koji I was giving up and he should go home. Half asleep, I looked at my breadboard thinking I can’t let Tom see this hot mess of wires tomorrow morning, I cut and stripped new wires, trimming them all down so everything lay flat. As a last attempt, I connected the controller to the server and motherf***** it worked.

Thank you Koji and Haley for your help!