Dear all, Is there someone who can explain to me why in my Wireshark captures I have sessions that ends with several RST packets following normal TCP end Session and the other not. I want to specifie that hosts concerned are always the same hosts but in different processes numbers here attaching the captures. Thank you for your help. asked 20 Jun '12, 08:51 KD001 |
One Answer:
In the capture file we can only see the first two frames of the 3-way TCP handshake (SYN, SYN-ACK but no ACK!) and then either a FIN or a RST. Where did you capture that data? On the Netscreen firewall? If yes, the multiple TCP Resets could be generated by the firewall (IDS on the Firewall or regular behaviour). To verify, I suggest to capture in front of the firewall and after the firewall. Then compare the capture files. Do you have any network problems with those RESETS or are you just curious about it? Regards answered 24 Jun '12, 23:20 Kurt Knochner ♦ Hello Kurt, 1 / in fact I do not have ACK packets because I put a filter to capture only the SYN, FIN and RST. I wanted to limit the number of packs ... because if not everyone tired of ACK packets have, and it would have been too many frames. 2 / I actually have a firewall between the client and server. and I wondered why sometimes I RST packets after the normal closing time of 4. I launched this catch because I have a user who said that the network is Responsible for the failure of some transfers. I think it's Sql Server which is the responsable. But I have to prove. (27 Jun '12, 01:24) KD001
It could be the Firewall or the Client. According to the MAC addresses you captured between the Firewall (Netscreen) and the next Router (Cisco). In that case you cannot tell if the Firewall sent the RESET or the Client. You need to capture between Client and Firewall AND between Firewall/Router. Furthermore you need to look at the SQL traffic itself, not just the TCP Flags. Maybe there is an error message in the answer from the SQL server that gives you a hint.
Your capture does not contain any special hints about SQL problems. To analyze those, we would need:
Regards (27 Jun '12, 03:59) Kurt Knochner ♦ |
can you please upload the capture file somewhere (maybe cloudshark.org) and post the link.
BTW: do you know of any IDS (intrusion detection system) or any firewall in the path to the SQL server?
hi kurt,
here is the link to the capture. https://www.cloudshark.org/captures/c2b111ed1b79
thank you for all.