 | 1 | initial version |
First off I don't think this capture was taken at the server side
as there are other conversations to/from the client at 172.16.2.87
Secondly I don't think that the reset packets are really coming from the "server" but from some device in the middle.
The server ACKs segments after the ACK numbers in the RST packets!
The ip.ttl and ip.id of those packets will give you more clues whether this is true.
Uploading your capture would certainly help giving a better answer .
Regards Matthias
| | 2 | No.2 Revision |
First off I don't think this capture was taken at the server side
as there are other conversations to/from the client at 172.16.2.87
Secondly I don't think that the reset packets are really coming from the "server" but from some device in the middle.
The server ACKs segments after the ACK numbers in the RST packets!
The ip.ttl and ip.id of those packets will give you more clues whether this is true.
Uploading your capture would certainly help giving a better answer .
Regards Matthias
Update
The capture filtered on tcp.port==49470 actually show that the RST packets arrive with a TTL of 241 whereas the other packets arrive with a TTL of 235/236. An indication that another device (LB ? ) is sending the RST packets.
I believe this is/may be caused by an invalid Selective Acknowledgement where the 'server' asks for 3760 and the SACK left edge indicates 801 was successfully received.
(tcp.options.sack_le == 801 or tcp.flags&4)
As the LB/Server are probably not in your scope to fix I would recommend you disable the SACK option and see if this gets you through.
