This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

MSSQL Keep-alive/RST Troubleshooting

We have a billing package that uses MSSQL as it's backend. On a physical machine, there are no issues with the software. In a VM on my system, the software will remain connected to the SQL server (looks like through keep-alives). In a wireshark trace, I can see the keep alive packets and the ACK packets back. Eventually, it looks like the server sends RST packets to the client and that is what breaks the connection and causes the software to stop working (gives a bunch of errors and crashes). What I am trying to determine is why is only this VM affected and if it is software (VMWare, the network driver, etc) or is it my host (no issues running anything on the host). If I can upload the capture somewhere, I would be happy to provide. Thanks for any help that can be offered.

rst ack mssql keep-alive

asked 22 Sep '16, 12:38

bmcwhirter
6●1●1●3
accept rate: 0%

Can you share a capture in a publicly accessible spot, e.g. CloudShark?

(23 Sep '16, 02:07) Jaap ♦

I've been trying to create an account on CloudShark since I posted this question. Their main site works but when I confirm my email address, the page takes forever to load then says that CloudShark is unavailable. I'll keep trying.

(23 Sep '16, 06:29) bmcwhirter

Finally got it uploaded. Is this what you need? https://www.cloudshark.org/captures/6e68c2d61fa7

.19 is the MSSQL server and .96 is the client VM.

(23 Sep '16, 08:10) bmcwhirter

One Answer:

Well, the teardown packet (via RST) is coming from the server, so it's not the physical or virtual client that aborts the connection. The RST looks to me like a connection abort (RST is sometimes also used as a "normal" shutdown of a connection) - the question is, what did the client do to annoy the server that much?

What is odd is how frequently the client uses Keep-Alives - one per 30 seconds is quite normal, but you see that it often fires a series of packets in a few microseconds (especially right before the RSTs).

This is what I would do:

Take a capture of a working setup to compare the behavior between the two setups. What does the client do differently?
Take a capture at the server (if you can) to check if the same packets are seen on both ends - sometimes, firewalls and other middle boxes may be responsible for this kind of thing, e.g. when they suspect malicious behavior (which the rapid fire keep-alives may be considered as)

Also, try to capture with a dedicated capture device/laptop, and NOT on the end system (client or server). Here's why: https://blog.packet-foo.com/2014/05/the-drawbacks-of-local-packet-captures/

answered 25 Sep '16, 05:56

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

edited 25 Sep '16, 05:56