Let’s calculate the round trip time (RTT) between client and server. Assuming that the initial TTL is 255 we can infer that 8 routers sit between the client and the server. So we have to assume the trace was recorded locally or through a SPAN port on the same LAN segment. Every router will decrement this number by one when forwarding the packet. IP stacks often (but not always) use the initial TTL of 255, 128 or 64 when transmitting a packet. Noteworthy detailsįrames 47 through 49 reveal a few noteworthy details. Your personal preferences might be different. For this article the client connection is colored with option 1 and the server side is highlighted with option 6. I also like the colors to stand out when using the Wireshark default color set. I tend to use colors with a strong contrast between background and foreground. Right-click on frame 47 and select from the pop-up window “Colorize conversation -> TCP” and click your favorite color. Instead, I use a feature that seems to be somewhat underrated: Colorize conversation. The filter will hide STP topology changes, routing updates, ARP storms and other interesting events.
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.
#View tcp retransmission wireshark how to#
This post demonstrates how to correlate two or more trace files to analyze a broken connection.
0 kommentar(er)
