Wireshark is my tool of choice for troubleshooting. While most people think of it at the end of the fight, with me it’s always on top of the list.
Recently, I had to look at a problem of a sales application where users reported that “the network was slow”.
The application was developed in-house, didn’t use any of the known application protocols like HTTP or FTP and wasn’t encrypted. In the middle of so many transactions and a working store, how to find the TCP conection that has the transaction to troubleshoot?
- frame contains “string”: searches for a string in all the frame content, independently of being IP, IPv6, UDP, TCP or any other protocol above layer 2.
- ip contains “string”: searches for the string in the content of any IP packet, regardless of the transport protocol.
- udp contains “string” or tcp contains “texto”: by now you already know…
Armed with the knowledge of these filters, all that was needed was some kind of reference. At the time it was the number identifying the customer. After the filter was applied, all packets related to that transaction were filtered and it was possible to the application response times.
Yes! There is nothing better than one to really understand. I can’t publish the specifics I mentioned above, but lets suppose I’m making a capture on my PC and that in the middle of thousands of packets I want to find the sequence that takes me to open www.disney.com.
In the display filter text box, I used “ip contains “disney”“…and the magic happens!
Surprisingly, even TLS packets were filtered. Why? Because somewhere inside those packets there is the word disney.
One is not enough! For the second example, I want to find the TCP conection used to send a file to an FTP server. The filename is “post.txt” and the content is a single line of text “Angola 1 2 3”.
I start the wireshark capture (with no capture filters), make the FTP connection and make 2 transfers. In one I send the file to the server and the other I download the same file.
To find the packets, I could use a filter to find the filename, but for the sake of testing I went deeper and searched for the file content with the filter tcp contains “Angola”.
The results were exactly as expected. 2 packets were found with the word “Angola” in them. One sending the file to the server and the other one in the reverse direction.
All the captures shown here were done with Wireshark 2, but these filters work with the previous version, 1.
If simple text filtering isn’t enough for you, you can replace the “contains” operator with “matches” and filter traffic with regular expressions.
A quick offtopic note
The last capture brought up the importance of encrypting communication and data. In the capture, it was possible to see not only the name of the file and its content but also the username and password used to access the FTP server. I did the capture on my laptop but any network administrator with access to the devices can make capture along the path and examine its content. Take care!