Skip to main content

How to interpret captured Wireshark information

Learn to capture and interpret network information with Wireshark.
Image
How to interpret network information from Wireshark

Wireshark is a GUI network protocol analyzer. It lets you interactively browse packet data from a live network or a previously saved capture file. It enables you to see what's happening on your network at a microscopic level.

TShark is a terminal-oriented version of Wireshark designed to capture and display packets when an interactive user interface isn't necessary or available. It supports the same options as Wireshark. On its website, Wireshark describes its rich feature set as including the following:

  • Deep inspection of hundreds of protocols, with more being added all the time
  • Live capture and offline analysis
  • Multi-platform: Runs on Windows, Linux, macOS, Solaris, FreeBSD, NetBSD, and many others
  • The most powerful display filters in the industry
  • Rich VoIP analysis
  • Read/write many different capture file formats: tcpdump (libpcap), Pcap NG, Cisco Secure IDS iplog, Microsoft Network Monitor, and many others
  • Capture files compressed with gzip can be decompressed on the fly
  • Live data can be read from Ethernet, IEEE 802.11, Bluetooth, USB, and others (depending on your platform)
  • Decryption support for many protocols, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2
  • Coloring rules can be applied to the packet list for quick, intuitive analysis
  • Output can be exported to XML, PostScript, CSV, or plain text

Installation

Wireshark can be installed with the standard simple commands.

On Red Hat Enterprise Linux (RHEL) 7:

yum install wireshark 

On Red Hat Enterprise Linux (RHEL) 8:

dnf install wireshark

Use cases

Without any options set, TShark works much like tcpdump. It uses the pcap library to capture traffic from the first available network interface and displays a summary line on each received packet's standard output.

Before we start any capture, we need define to which interfaces on our server TShark can use. You may need to use sudo or root access in this case.

[ You might also like: My 5 favorite Linux sysadmin tools ]

To get this information, you will need to run the command below:

# tshark –D

A sample output is below:

[root@server ~]# tshark -D
1. eth0
2. nflog
3. nfqueue
4. usbmon1
5. any
6. lo (Loopback)

If we wanted to capture traffic on eth0, we could call it with this command:

tshark -i eth0

Sample output:

[root@server ~]# tshark -i eth0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
  1 0.000000000 41.242.139.31 -> 207.180.200.5 TCP 60 61513 > tcoaddressbook [ACK] Seq=1 Ack=1 Win=508 Len=0
  2 0.103588364 41.242.139.31 -> 207.180.200.5 TCP 60 61513 > tcoaddressbook [ACK] Seq=1 Ack=81 Win=508 Len=0
  3 0.690499219 173.212.240.3 -> 255.255.255.255 DHCP 362 DHCP ACK      - Transaction ID 0x6b443d32
  4 0.819279418 207.180.200.5 -> 41.242.139.31 TCP 342 tcoaddressbook > 61513 [PSH, ACK] Seq=81 Ack=1 Win=283 Len=288
  5 0.987663435 45.77.145.115 -> 207.180.200.5 TCP 60 wso2esb-console > https [SYN] Seq=0 Win=5840 Len=0
  6 0.987758650 207.180.200.5 -> 45.77.145.115 TCP 54 [TCP ACKed unseen segment] https > wso2esb-console [ACK] Seq=1 Ack=316217230 Win=29200 Len=0
  7 1.001310441 207.180.200.5 -> 45.77.145.115 TCP 58 [TCP ACKed unseen segment] [TCP Retransmission] https > wso2esb-console [SYN, ACK] Seq=0 Ack=316217230 Win=29200 Len=0 MSS=1460
  8 1.002550877 41.242.139.31 -> 207.180.200.5 TCP 60 61513 > tcoaddressbook [ACK] Seq=1 Ack=369 Win=513 Len=0
  9 1.014391846 207.180.200.5 -> 80.237.128.149 NTP 90 NTP Version 4, client
 10 1.039819501 80.237.128.149 -> 207.180.200.5 NTP 90 NTP Version 4, server

The packets above are denoted by numbers at the beginning of the line.

These lines include two IP addresses on either side of an arrow—these are the hosts that are exchanging the packet. The arrow's direction indicates which direction the packet is going. Therefore, 41.242.139.31 -> 207.180.200.5 means the packet originated at host 41.242.139.31, which is my computer, and is headed for destination 207.180.200.5, which is the remote server where TShark is installed. My computer is trying to connect to this server, so it's going through the TCP handshake.

Here is a basic explanation of how TShark works: It captures all traffic that is initiated to and from the server where it's installed. With the power of TShark's filtering, we can display the traffic we are interested in.

We can also limit the output of the capture to specific lines. For example, if we want to limit the output to 10 lines, we will use the command below:

# tshark -i eth0 -c 10

Capture traffic to and from one host

We can filter out traffic coming from a specific host. For example, to find traffic coming from and going to 8.8.8.8, we use the command:

# tshark -i eth0 -c 10 host 8.8.8.8

For traffic coming from 8.8.8.8:

# tshark -i eth0 src host 8.8.8.8

For traffic going to 8.8.8.8:

# tshark -i eth0 dst host 8.8.8.8

Sample output:

[root@server2 ~]# tshark -i eth0 -c 10 host 8.8.8.8
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
  1 0.000000000      8.8.8.8 -> 207.180.229.97 DNS 185 Standard query response 0x8d7a No such name
  2 0.004498954      8.8.8.8 -> 207.180.229.97 DNS 184 Standard query response 0x2302 No such name
  3 0.024649288      8.8.8.8 -> 207.180.229.97 DNS 146 Standard query response 0x24d2 No such name
  4 0.125434062      8.8.8.8 -> 207.180.229.97 DNS 125 Standard query response 0xf89a  NS ns1.mail.rhsblmail.com NS ns2.mail.rhsblmail.com
  5 0.138280488      8.8.8.8 -> 207.180.229.97 DNS 105 Standard query response 0x1d17  MX 10 mail.rhsblmail.com
  6 0.143231852      8.8.8.8 -> 207.180.229.97 DNS 134 Standard query response 0xc774  NS ns1.hongkongserver.net NS ns2.hongkongserver.net
  7 0.144433854      8.8.8.8 -> 207.180.229.97 DNS 99 Standard query response 0x4682  A 119.8.46.109
  8 0.201845674      8.8.8.8 -> 207.180.229.97 DNS 150 Standard query response 0xfb47 No such name
  9 0.205827278 207.180.229.97 -> 8.8.8.8      DNS 72 Standard query 0x74e3  MX dalcargo.net
 10 0.482611966      8.8.8.8 -> 207.180.229.97 DNS 102 Standard query response 0x74e3  MX 0 mx.sinanet.com

In the above output, we see traffic coming from and going to 8.8.8.8. The host 8.8.8.8 is giving responses to the server 207.180.229.97 about queries it has initiated earlier.

Capture traffic to and from a network

We can also capture traffic to and a specific network. To do this, we use the command below:

# tshark -i eth0 net 10.1.0.0 mask 255.255.255.0

or

# tshark -i eth0 net 10.1.0.0/24

We can also filter based on source or destination.

Based on the source (traffic coming from):

# tshark -i eth0 src net 10.1.0.0/24

Based on the destination (traffic going to):

# tshark -i eth0 dst net 10.1.0.0/24

Capture traffic to and from port numbers

Here are many other variations.

Capture only DNS port 53 traffic:

# tshark -i eth0 port 53

For a specific host:

# tshark -i eth0 host 8.8.8.8 and port 53

Capture only HTTPS traffic:

# tshark -i eth0 -c 10 host www.google.com and port 443

Capture all ports except port 80 and 25:

tshark -i eth0 port not 53 and not 25

Saving output to a file

We can save the output of our capture to a file to be read later. Later versions of Wireshark save the output in the pcapng by default. However, we can save in other formats as well. To check the supported format, run the command below:

# tshark -F

To save the output, we use the -w switch. Using the -w switch provides raw packet data, not text. If you want text output, you need to redirect stdout (e.g., using >). Don't use the -w option for this.

To save a capture to a file name http_capture.pcapng:

# tshark -i eth0 -c 10 port 80 -w http_capture.pcapng

We can save in pcap format, which can be read by tcpdump and older versions of Wireshark:

# tshark -i eth0 -c 10 port 80 -w http.pcap -F libpcap

[ Want to learn more about security? Check out the IT security and compliance checklist. ] 

Wrap up

TShark is a comprehensive tool that sysadmins need to add to their toolset. This is part one of a two-part series. In part two, we will look at more advanced filters and how we can make the output more readable.

Topics:   Linux   Linux administration   Security   Networking  
Author’s photo

Evans Amoany

I work as Unix/Linux Administrator with a passion for high availability systems and clusters. I am a student of performance and optimization of systems and DevOps. I have passion for anything IT related and most importantly automation, high availability, and security. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.