[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.

One thought on “[understanding networks week 5] packets and mysteries”

  1. Hey there! I work in IT Security, so I’m more than happy to answer any questions you might have about this stuff 🙂

    FTP is generally on the “Naughty” list, as far as we’re concerned. All your credentials are passed around in the clear, much as they are if you use Telnet. If you must transfer files around, use FTP/S (the TLS encrypted version of FTP) or either SFTP (the File Transfer system executed from SSH, and bundled with most SSH packages) or SCP (the File Copy system, which is part of SSH, unless it’s been compiled out…. anyway, it’s usually there!).

    You’ll have seen packets being shipped around when you were on the console of the SSH server, as it needs to know which characters you are typing on the command line (e.g. if you press the Tab key, it might try to complete a command or switch). Also, if you have an interactive process, like tmux or Byobu running, there will be screen updates from that application all the time it’s running.

    I’m not sure why you didn’t see anything from your Pi when it was supposed to have been tweeting. It probably should have made an HTTPS request on TCP/443 at the point the request was going out.

    You can also use the tcpdump command when SSH’d into the device and force a request to occur, like this:

    tcpdump -w capture.pcap -s 0 -i eth0 not port 22

    This means:
    * “-w capture.pcap”
    run the tcpdump and output what’s occuring to a file called “capture.pcap” for later analysis in Wireshark or tcpdump.
    * “-s 0”
    capture all the bytes in the packet, not just the first 1024
    * “-i eth0”
    Use the interface eth0. If you’ve got more than one interface, use just the one you’re expecting the traffic to exit from.
    * “not port 22”
    Here you can specify things like “host and host” to see the conversation between two hosts, or “not icmp” or “port 443” or “not host″… but the reason I specifically call out “not port 22” is because otherwise you’ll see the SSH session you’ve got running 🙂

    Anyway, there’s a lot of stuff here. Feel free to ping me back if there’s something you’d like help with!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: