In the second post of “network analysis tricks” series, I’ll explain how to focus on a certain range of packets in a network trace.
When I ask for a network trace from a customer, I almost always ask for ICMP markers before and after reproducing the problem. You can see an example action plan below to see what I mean:
<<Start network trace on the client>>ping -l 22 -n 1 IP-address-of-default-gateway<<Reproduce the problem now. Example: Try to connect to www.microsoft.com from IE and once you get the “page not found” run the second ping>>ping -l 33 -n 1 IP-address-of-default-gateway<<Stop network trace on the client>>
Note: You can check the following blog post for more information about general network trace collection tricks
In our example, when the network trace is collected as per the above action plan, it’s very clear that we will only be focusing on packets that were received/sent between 22 bytes and 33 bytes ICMP packets sent to the default gateway and we will safely ignore packets before 22 bytes ICMP packet or packets after 33 bytes ICMP packet. So if the 22 bytes and 33 bytes ICMP requests and responses are as given below:
Packet6 <<22 bytes ICMP echo request>>
Packet9 <<22 bytes ICMP echo response>>
Packet20 <<33 bytes ICMP echo request>>
Packet23 <<33 bytes ICMP echo request>>
it will mean we will only need to focus on packets between packet10 and packet19 and can safely ignore all packets after packet19 or all packets before packet10.
You might be wondering how you can identify those 22 bytes or 33 bytes ICMP packets in a network trace. It’s fairly simple, we filter the network trace based on icmp protocol and ip packet length. For example the following Wireshark filter will show us all ICMP packets whose payloads are 22 bytes or 33 bytes:
icmp and (ip.len==50 or ip.len==61)
=> Total length in IP header is set to 50 when we send a 22 bytes ping request:
20 bytes IP header + 8 bytes ICMP header + 22 bytes ICMP payload
=> Total length in IP header is set to 61 when we send a 33 bytes ping request:
20 bytes IP header + 8 bytes ICMP header + 33 bytes ICMP payload
That would mean that we need to focus on frames between frame #126 and frame #210 since we reproduced the problem between 22 bytes and 33 bytes pings as given below:
Of course we’ll need to do further filtering based on the problem we’re troubleshooting, but for now we managed to isolate the traffic that we need to analyze to a certain range.
From this point on, whatever filter we apply to the network trace, we can put the following filter in front of it:
frame.number>=126 and frame.number<=210
Let’s say that we troubleshoot a TCP connection problem to TCP port 389 in this network trace. Then we can simply apply the following filter (in Wireshark):
as we won’t be interested in any packets sent/received to TCP port 389 before frame#126 or after frame#210 (because those frames are sent/received before we reproduce the problem and after we reproduce the problem)
Hope this helps