TCPDUMP Mystery Dinner, or, How Gitpod is an Amazing Learning Platform

Inspired by the fantastic networking zine that Julia Evans made, I decided to try and create a micromaterial to practice using tcpdump to actually do something.

for interface in $(ip link show | grep veth | awk -F ' ' '{print $2}' | awk -F '@' '{print $1}'); do
  sudo timeout 3 tcpdump -nq -i $interface "tcp port 3000" > /dev/null
  printf "\n"
  echo "this interface is $interface"
  printf "\n"
done;

While full of interesting ways to combine command line syntax for this tool, the zine deserved to be expanded on. I’ve seen this a lot of times, where tools have a lot of documentation and blog posts about HOW they work, but learners are left to find a WHY to use them.

And since repeated practice in the context of meaningful action is one of the best ways to actually learn things, I set off to create an exercise to do just that!

It’s a bit cumbersome with all the supporting setup, but the good news is that once we create a learning material (ANY learning material) defined in code, we only have to create it once, and then it’s available for anyone anywhere!

And the best part is, if we use Gitpod, we don’t even need to care about what sort of system the learner has. As long as they have access to an internet browser, they can replicate the exact same learning experience, wherever they are.

The Learning Objective: Use Tcpdump to do something

…or, more specifically, use tcpdump to inspect network packets and see which container is sending too much traffic. You’ll know you did it correctly because stopping that container fixes the problem.

Tcpdump can show us a whole lot of things about the network packets flying around our system, and in this case, our express webserver is receiving too many of them to adequately handle the load.

Nevermind that, in the real world, we would probably want to re-architect this to be distributed to global CDNs, or to scale horizontally behind a load balancer, or to just use golang…but we want to have a use case for tcpdump, and in our investigation, it turns out that one of the containers in our system is sending WAY more packets than the other ones.

listening on veth4123d57, link-type EN10MB (Ethernet), capture size 262144 bytes
82 packets captured
117 packets received by filter
0 packets dropped by kernel

this interface is veth4123d57

So with a bit of piecing together of the clues, we can connect that particular container (or more specifically, its network interface) with the mapping for our host, and then we just stop the offending container.

After that, reloading our webserver shows that it’s way faster. We’ve saved the day!

And that’s it! The whole point of this micromaterial is focused practice with a specific tool for a specific purpose. I learned a lot while making it, and big shout out to Gitpod for being awesome and enabling this.

Source code: https://github.com/lpmi-13/tcpdump-mystery

Open it directly in Gitpod: https://gitpod.io/#https://github.com/lpmi-13/tcpdump-mystery

Advertisement