Listen to TCP Handshake

10 Oct 2019

For this project I wanted to push myself in thinking about data in non traditional ways while thinking about data capture and real-time data visualization. In addition I wanted to challenge myself in making non-screen based data art. While selecting a source of data I thought about the means of data collection particularly deep packet inspection in countries hostile to internet freedoms. To pursue this I wanted to analyze my own network traffick.

While performing network analysis on myself I was stumped on how to find any meaning with something as low level as a packet. I found that with the world (thankfully) moving towards a more secure future with SSL the packet data themselves did not reveal too much. With more analysis I was intrigued with the TCP protocol itself, particularly the TCP handshake.

When computers connect via TCP they must perform a three-way handshake in order to communicate. The first computer will send a SYNC packet to the other to initialize then the second computer will reply with a SYNC-ACK packet and finally the first computer will acknowledge the reply with a ACK packet completing the handshake. I think there is something quite human about this connnection and decided that this was something I wanted to visualize.

I haven’t been doing physical computing or much fabrication in a while, so I decided that would be my medium. I wanted to work with sound because that felt detached from the internet, but also not quite because the internet can trace its history to telegraph and morse code.

I chose solenoids as my tool because of their binary nature, as well as their speed. Internet traffick moves at tremendous speeds so I had to choose a medium that could support those speeds. Originally I wanted to make something more musical but I didn’t have time to find affordable instruments so I fabricated my own woodblock and tin drum. I wanted to use different materials to create different sounds to highlight the differences between the request and response packets.

From a technical level I am using and Open-WRT router and iptables to forward traffick from my laptop to a Raspberry Pi. On the Raspberry Pi I am using tshark to sniff the traffick coming through my computer and filtering for TCP packets. Finally I parse through the captured packets and trigger the solenoids depending on the type of data packet.

What is interesting about the project is that it sonifies in real time the data being sent. Computers can be quite chatty when left idling. I have heard that Amazon Echoes speak to their servers every 15 seconds or so. So it would be interesting to analyze that traffick.

I also think that it could be an interesting teaching tool to visualize computer networking concepts. In an ideal world the sounds would be quite predictible in a 1-2-1 kind of pattern. However because of packet loss and latency this is not the case.

Right click to play:

Sample of raw packcet capture:

16 10.818188414 192.168.8.128 → 192.168.8.1  TCP 74 38962 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1127760429 TSecr=0 WS=128
   17 10.818588411  192.168.8.1 → 192.168.8.128 TCP 74 80 → 38962 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=371693 TSecr=1127760429 WS=16
   88 20.016977905 192.168.8.128 → 192.30.253.124 TCP 74 49312 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=3762051014 TSecr=0 WS=128
   89 20.075393439 192.30.253.124 → 192.168.8.128 TCP 74 443 → 49312 [SYN, ACK] Seq=0 Ack=1 Win=28480 Len=0 MSS=1300 SACK_PERM=1 TSval=1738838657 TSecr=3762051014 WS=1024
  157 29.283388963 192.168.8.128 → 23.217.149.114 TCP 74 43922 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=364092857 TSecr=0 WS=128
  158 29.287442930 23.217.149.114 → 192.168.8.128 TCP 74 443 → 43922 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1300 SACK_PERM=1 TSval=4160262549 TSecr=364092857 WS=128
  280 41.055712175 192.168.8.128 → 192.168.8.1  TCP 74 38968 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1127790667 TSecr=0 WS=128
  281 41.056057172  192.168.8.1 → 192.168.8.128 TCP 74 80 → 38968 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=374717 TSecr=1127790667 WS=16
  548 71.180007926 192.168.8.128 → 192.168.8.1  TCP 74 38970 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1127820790 TSecr=0 WS=128

Sample of pased data (time of packet, ip address, packet type):

SYN Pack
['24.595858259', '172.217.10.46', 'SYN']

SYN Pack
['24.961442733', '172.217.10.141', 'SYN']

SYN Pack
['24.964269644', '172.217.11.42', 'SYN']

SYN ACK Pack
['24.966016589', '192.168.8.128', 'SYN ACK']

SYN ACK Pack
['24.968836500', '192.168.8.128', 'SYN ACK']

Sample of running output:

SYNC request sent to 172.217.12.206.
ACK by by 192.168.8.128.
SYNC request sent to 192.168.8.128.
SYNC request sent to 151.139.128.14.
ACK by by 192.168.8.128.
SYNC request sent to 172.217.9.234.
ACK by by 192.168.8.128.
SYNC request sent to 104.19.199.151.

Github