Hi, I am looking at a trace with the following information (stream is applied as filter): client_pc(source) -> Server(dest) ->Delta Time=0.552->tcp.time_delta=30.277237000 I can interpret this as such: RTT (Delta Time)bit slow but meh, server in US me in germany, it happens. tcp.delta_time extremely slow, probably a timeout fetching data or someother major problem. Question is. Should I be looking for the problem in the client application or on the server? I Know tcp.time_delta is the time from end of previous tcp packet in stream to end of current. But I am not sure if this means the tcp delay is on this packet and the client is slow or it is on the previous and the server is slow. I just need to know if the client is waiting on the server or the server on the client: does the tcp.time_delta refer to the current frame and indicate delay on the client in this case? I am pretty sure the delay is on the client, but that just kinda doesn't make an sense to me.. asked 01 Oct '14, 14:20  DarrenWright |
One Answer:
As usual analysis by screenshot is fraught with issues as we can't see acks, connection setup, etc. Assuming your annotation of source and dest in the diagram is correct, then it does look as though the client is waiting for 30 secs to transmit the data contained in the 3 frames 2277, 2278 & 2279 (probably one application message spread over three tcp segments looking at the relative times) and the server is quick to respond given the likely RTT. What I can't tell is what the client was doing between 2253 & 2277, knowledge of the application would be needed there. I guess that 2253 is a client ack to data from the server in 2252, again due to the very short relative time. answered 02 Oct '14, 05:34  grahamb ♦ If the security team is concerned with disclosing confident information in traces have them look at TraceWrangler (http://www.tracewrangler.com). It's really easy to obfuscate IP addresses and cut away sensitive payloads with it, and usually the results are still usable to do TCP troubleshooting where no exact application behavior is needed. (02 Oct '14, 09:49) Jasper ♦♦ |
Can I try this one then slightly differently..
2253 indicates everything from client to server is okay 2277 indicates the client was just waiting around for 30 seconds 2278 indicates traffic form client to server inside the send window 2279 indicates traffic form client to server inside the send window 2280 indicates server responds to previous packet after 160ms (roughly rtt + 20ms)The delay was on the client either waiting for or working on the data received and I should be looking at whatever it is the client is doing during this pause?
Sound about right?