On Fri, 8 Aug 2008 02:57:54 -0700 (PDT) Peter Miklosko wrote:
> OK, here are filtered based on your previous recommendation (tcp.flags.reset==set)
> Attachment: log.pcap
Hi Peter,
I took a look at your trace file:
$ tshark -r log.pcap -T fields -e frame.number -e frame.time -e frame.time_delta
1 Jul 12, 2008 20:56:04.847988000 0.000000000
2 Jul 12, 2008 20:56:47.208916000 42.360928000
3 Jul 12, 2008 20:56:47.241420000 0.032504000
4 Jul 12, 2008 20:57:17.199471000 29.958051000
5 Jul 12, 2008 20:59:29.660746000 132.461275000
6 Jul 12, 2008 21:01:04.931367000 95.270621000
7 Jul 12, 2008 21:01:12.069220000 7.137853000
8 Jul 12, 2008 21:06:10.856888000 298.787668000
9 Jul 12, 2008 21:11:11.669231000 300.812343000
10 Jul 12, 2008 21:16:12.477209000 300.807978000
11 Jul 12, 2008 21:16:17.312977000 4.835768000
12 Jul 12, 2008 21:16:17.359513000 0.046536000
13 Jul 12, 2008 21:16:47.283492000 29.923979000
14 Jul 12, 2008 21:18:35.158525000 107.875033000
15 Jul 12, 2008 21:18:41.681702000 6.523177000
I don't think these are a lot of resets according to the elapsed time (correct
me if I'm wrong).
By just looking at the resets you cannot figure out, what caused those resets.
Did you, like Abdik (Abhik Sarkar Date: Thu, 7 Aug 2008 20:02:46 +0400) suggested,
capture again using a ringbuffer?
On Thu, 7 Aug 2008 20:02:46 +0400 Abdik wrote:
> If the capture continues while there is a problem, then once you have
> stopped and saved the capture you need to analyze it to see what might
> be going wrong... I think a good place to start would be to find a lot
> of frames at more or less the same time with TCP resets (display
> filter tcp.flags.reset==set). Once you find a clump of packets with
> this at around the same time as you saw the connections going down,
> clear the display filter and then search upwards in the packet list to
> see if there was something suspicious.
Select a packet with the reset flag set and select Follow TCP Stream.
I hope this will help to figure out, what has happened.
Greetz
Joan
