Experts, Troubleshooting an intermittent problem with a web application. Problem is that the website is slow to respond, navigate between screens and load data I have a packet capture from a win7 client and a packet capture of the same traffic taken from the perimeter. With these traces, are there any obvious issues? Can you give me some pointers as to what may be causing these issues? Any assistance would be greatly appreciated. asked 31 Mar '15, 07:42  Brad_101 edited 18 May '15, 15:29 |
One Answer:
That's all HTTPS traffic in the capture files, which means we won't see any application specific problems AND you have only captured the first 54 bytes, so no way to look at the payload, but maybe that was your intention by using TraceWrangler! Furthermore, there are 266 TCP connections at the client side and 277 at the firewall side. Without any further information, like WHEN (time stamp) did the problem occur, it's like finding the needle in the haystack.
Not at the client side, except the fact that every session was RESET and none was closed via FIN, which is O.K. if the application was designed to work that way. At the firewall side, there is a big mess in the capture file, with a lot of packet reordering and there are different MAC addresses (f2:39:d0:64:53:4b, f2:c1:04:02:a5:8d) for the same IP address (172.28.1.1). Looks like you were using TraceWrangler and something went awfully wrong (SEQ numbers are weird as well). Unfortunately, it's (almost) impossible to do any meaningful analysis with that capture file. Can you please repeat the anonymization step, check the output file and then post the new file? Regards answered 31 Mar '15, 11:29  Kurt Knochner ♦ edited 31 Mar '15, 11:31 Try these: https://www.dropbox.com/s/qu5bi0fgc5rb5l9/Client_trace.pcapng?dl=0 https://www.dropbox.com/s/vd7v99cxb0zss7m/Firewall_trace.pcapng?dl=0 Both traces were started immediately before recreating the issue (opening a customer and waiting for it to load) (01 Apr '15, 02:05) Brad_101 strange, TraceWrangler doesn't even touch sequence numbers (they're simply copied to the new frame), and keeps track of MAC replacements, so I can't think of a way how the anonymization could have garbled the firewall trace this bad... I'd love to see the original capture file, but I doubt I'll have that chance ;-) (01 Apr '15, 02:40) Jasper ♦♦ In the client trace there are 266 tcp sessions reported between mentioned IP's and out of that only 6 connections took more than 50 seconds and average session time is below 1 second.among 6 sessions who took more than 50 seconds atleast in 5 cases delay is caused on source system 192.168.1.1 itself.you can see delta time difference.are you facing this issue across all systems, if not try from different system. (01 Apr '15, 03:22) kishan pandey The issue affects all systems at the same time - it is not limited to one or some Pc's. (01 Apr '15, 06:23) Brad_101 The firewall trace is still messed up. Several MAC addresses for 172.28.1.1, but more seriously, the SEQ/ACK numbers are totally messed up too. Sorry, it's (almost) impossible to do any usefull analysis with that file. (01 Apr '15, 09:46) Kurt Knochner ♦ Send me and @Jasper the dropbox link vi e-mail. Click on our names to get to the profile with the e-mail address. For @Jasper, follow the link to his blog and the load the "Impressum" page (link at the bottom of the page) for an e-mail address. (01 Apr '15, 13:13) Kurt Knochner ♦ my email is jasper [ät] packet-foo.com (01 Apr '15, 13:35) Jasper ♦♦ After I had a look at the original files I have to say that the client trace shows no TCP problems except for some conversations that were recorded one-sided only (no idea why, but we only see one direction, so the Wireshark TCP expert is unhappy) The firewall trace is a complete mess. There's no way that those packets were correctly captured, as the sequence numbers are so inconsistent that they look like they have been randomized at some point. I doubt that anything can be deducted from those packets, sorry. (02 Apr '15, 01:11) Jasper ♦♦ I second @Jasper: There is a problem in the capture file ("duplicate" frames but with wrong SEQ numbers) and it's either the server sending those frames, or some other device on the network. Take a look at stream 0. There are 3 SYN-ACK frames, while only the last one has the correct ACK. Where do the other two SYN-ACK come from?
(02 Apr '15, 02:41) Kurt Knochner ♦ I have since noticed a security setting on the firewall that randomizes TCP sequence numbers. It is currently enabled. I will disable this temporarily and capture some new traces for you (02 Apr '15, 02:47) Brad_101 Yeah, but it's the server sending the buggy frames? Where exactly did you capture the "Firewall" trace? Did you do that ON the firewall itself? If so, bad idea! Please capture on a switch mirror port in front of the server and/or the firewall. (02 Apr '15, 03:27) Kurt Knochner ♦ It was captured on the firewall itself. Why is that a bad idea? (02 Apr '15, 03:32) Brad_101 Because you don't know (for sure) at which "internal" stage the firewall is actually capturing the frames and how often. If you capture the frames on the wire (switch mirror port) you know exactly what was sent onto the network. So, either your firewall captures "some" frames three times AND modifies some SEQ numbers, OR your server is the problem. So, how are going to decide which of the two statements is the right one? ;-) (02 Apr '15, 03:35) Kurt Knochner ♦ So I'm clear, you're referring to what is causing the odd packets not the reported issue? (02 Apr '15, 05:48) Brad_101 Yes, because without a proper capture file, you can't do any analysis for the other problem. (02 Apr '15, 06:40) Kurt Knochner ♦ showing 5 of 15 show 10 more comments |
Please let me know where I can upload the traces
You can share the captures in a publicly accessible spot, e.g. CloudShark, Google Drive or Dropbox.