For a number of reasons I use it only later in the troubleshooting process, if at all: The function is great for troubleshooting plain text protocols. While teaching Wireshark classes I noted that many engineers tend to focus on the session with the context menu “Follow -> TCP stream”. Once we have located the session we can start the real work. It is very easy to navigate between marked packets using the keyboard shortcuts Ctrl-Shift-N and Ctrl-Shift-B or the respective functions found in the Edit-Menu. In a more complex scenario you might want to mark interesting packets using Ctrl-M on your keyboard or Edit -> Mark/Unmark. If you know the frame number where the connection starts you can use Ctrl-G to navigate to the frame number that you already know.A display filter that only covers the server port (here: 5061) is likely to include multiple TCP sessions.If the trace file covers multiple hosts using this TCP port you might want to add an IP address to the filter. Then enter the following display filter to locate the start of our TCP session: Once the client trace file has been loaded into Wireshark we have a number of options to navigate through bulky files:
We already know that the failed connection uses TCP port 53695. Let’s find the faulty connection in our trace file. Segment size and window scaling are just two of the parameters. Here is why: Both sides exchange a lot of important information in the first two packets. When analyzing a failed connection I like to start with the session setup. We know from the firewall’s log file that the firewall permits the connection: action=accept Initially our network diagram looks like this:
The failed connection uses TCP port 53695 on the client side and port 5061 on the server side. We will make educated guesses about the number of routers during the analysis. The two servers 10.1.1.1 and 10.2.2.2 are sitting on different network segments, one of them protected by a firewall. For those who are new to network analysis we use this blog post to introduce helpful Wireshark features and present a techniques to gather extra information about the network. Seasoned network engineers will quickly find the culprit by a careful look at the packet list of both traces. We need to find the root cause for this problem. The Skype administrator has identified the TCP port number for one of the failed connections. Network traffic was recorded on both servers. Still, the desired data exchange does not happen.
The firewall log file documents that the connection is allowed. Two servers running Skype for Business try to exchange information. We assume that the reader is familiar with TCP basics like session setup, retransmissions, window size etc. We identify the root cause and gather information about the network topology. This post demonstrates how to correlate two or more trace files to analyze a broken connection.
0 kommentar(er)
