In the “network analysis tricks” series of posts, I’ll try to explain some techniques that I use when analyzing network traces.
In this first post, I would like to explain how I find all TCP connection attempts in a network trace.
To see all TCP connection attempts in a network trace, you can use the following filter: (applies to both Network Monitor and Wireshark)
Network Monitor output:
After we apply the filter, we see that 10.1.1.4 tries to open different TCP sessions to 10.1.1.3 at TCP port 135, 1064, 3028 and 3029. Please note that the filter only displays the first two packets of each TCP session because only the first two TCP segments have the SYN flag set to 1. After finding out the TCP sessions, you can see the whole TCP session with a new filter.
For example, if we need to see the all TCP packets in the TCP session between 10.1.1.4:3026 <--> 10.1.1.3:135, we can apply the following filter and see all the packets exchanged in that session:
You can extend the filter to limit the output. Please see some examples below:
=> This filter will show all TCP connection attempts to TCP port 80 (HTTP)
tcp.flags.syn==1 and tcp.port==80
=> This filter will show all TCP connection attempts to TCP port 80 (HTTP) between 10.1.1.3 and 10.1.1.4
tcp.flags.syn==1 and tcp.port==80 and ip.addr==10.1.1.3 and ip.addr==10.1.1.4 (for Wireshark)
tcp.flags.syn==1 and tcp.port==80 and ip.addr==10.1.1.3 and ip.addr==10.1.1.4 (for Network monitor)
If you would like to see all TCP sessions ongoing in a network trace (not just the ones that was established within the timeframe covered by the trace) with some useful information, you can use a nice Wireshark feature called “Conversations”.
You first need to select "Conversations" from "Statistics" menu in Wireshark:
Then you need to click on "TCP" tab in the "Conversations" window
So we can see the same four TCP sessions that were seen with the previous filter. On top of that we can see many details for each session like how many packets/bytes were exchanged in each direction, the duration of a given TCP session seen in the trace, and approximate bandwidth usage of a given TCP session.
When troubleshooting network connectivity/performance problems, I very oftenly use the above techniques to find out different TCP sessions because an application/service might try to establish multiple TCP sessions when doing its work.
Hope this helps
A simple check you can have the application support guys do without netmon is to have them run "netmon -an 3" and watch for syn_sent states. In a complicated environment this simple view of tcp session establishment can give the application guys the clue they need to further their investigation.