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

MS SQL link being disconnected

0

Hi, I am beginning to feel lost and I need some help because I need to fix this problem I've been having at work.

Basically, I have been having issues with my network drives, seems like after a certain amount of time computers are not able to see my other computers in the same workgroup, and the most important one the company server. As a result, networks drives are not found, as well as having reliability issues with a sql driven program that uses sql native drivers, this is the most pervasive and important of the two.

Here are the things I've tried not sure what order or combination.

disabled firewall in server and client disabled antivirus added a wins server to the mix hoping it would help the problem, didn't work added entries to the host files of the workstations pointing to the server, no good either. bought a new main switch, nothing both wired and wireless devices are experiencing the same issue Weirder still is that I set an endless ping and the problem occurs to a lesser extent, but still happens.

Attached a wireshark dump for the application connection.

192.168.1.110 is the server. Any help is greatly appreciated, not sure what other things to do to get this fixed.

Link to better resolution picture. alt text

asked 28 Jul '14, 18:52

geo77's gravatar image

geo77
11113
accept rate: 0%

edited 28 Jul '14, 18:54

You should post a link to the capture file itself.

(29 Jul '14, 02:11) Jaap ♦

Hi all, I found this article that could be related to my issue above, it seems there is something that the combination of smb NAT and vpn do weird things to micsoft's tcp communications. I have two locations connected via vpn, and my firewall which is the same as vpn gateway is using NAT. Now, I have disabled my shared folders in my remote location, and see improvement, but I'm still seeing the same behavior. Any help is greatly apreciated.

http://social.technet.microsoft.com/Forums/windowsserver/en-US/0d2b5954-6cea-4ce3-96f5-a59dadbb89c9/intermittent-error-when-connecting-to-win2k8-shares-the-specified-network-name-is-no-longer?forum=winserverPN

(02 Aug '14, 11:31) geo77

3 Answers:

0

As mentioned by @Jaap, it would be better to post a capture file instead of a screenshot, because doing packet analysis, based on screenshots is

  • time consuming and thus not really motivating for those you are asking for help
  • boring
  • near to impossible

;-))

However, in your case I don't need the capture file, because there is (most certainly) nothing in the capture file that would explain why the server sends a RESET and then continues to send keep-alive frames. There are two possible reasons I can imagine

  • The TCP reset was sent by a security device/software between the client and the server. As both systems seem to be in the same subnet, it could be some security software on the server (like Firewall, AV, Endpoint Security, etc.).
  • There is a bug in the server software

In either case, staring at the capture files won't help, as that won't explain why it happens. ;-) So, you should check the available logs (system, sql server, etc.) to figure out what's going wrong.

Regards
Kurt

answered 03 Aug '14, 10:01

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 03 Aug '14, 10:06

Hello all, I would like to make my trace file available, but how do I make sure I don't have sensitive information in it? passwords and such.

I don't know if this is relevant, but if I open a command window and enter an endless ping to the SQL server, reliability improves.

(04 Aug '14, 12:56) geo77

but how do I make sure I don't have sensitive information in it?

Take a look at TraceWrangler a tool made by our member @Jasper.

I don't know if this is relevant,

I don't think so.

but if I open a command window and enter an endless ping to the SQL server, reliability improves.

If it is really relevant, you've found a solution yourself ;-))

(04 Aug '14, 15:09) Kurt Knochner ♦

0

Hi,

I agree with Kurt that a bit more information would be useful. For me, especially important is the timeline, i.e. at what time did the user experience the problem and what was the symptom. The reason I ask is that at around 888 seconds into the trace the last data flow was from the database service to the client. If the user had a problem between 888 and 949 seconds this would appear not to be a problem with the interactions to the database. It would be down to a problem inside the client or an interaction with something else not shown in the screenshot.

You haven't said where this trace was captured; adjacent to or on the database server or adjacent to or on the client. The handling of the RST looks as though the client process (using TCP port 56926) is not seeing the RST. Intermediate firewalls or proxies should be identified and checked to see how they handle RSTs - for example firewalls can be configured to silently drop RSTs.

That said, dropping packets with the RST flag set may not explain the user's problem if the symptom is experienced in the +888 to +949 second timeframe.

Best regards...Paul

answered 04 Aug '14, 08:00

PaulOfford's gravatar image

PaulOfford
131283237
accept rate: 11%

0

You could use TraceWrangler to anonymize the trace.

The continuous ping could be relevant if it prevented an idle timer tripping in a component in the path. But this all brings us back to the fundemental questions; what was the symptom the user experienced and at what time in the trace did the problem occur.

If you don't know, capture the trace again but as soon as the user experiences the problem send a single ping of 101 bytes:

Ping -n 1 -l 101 192.168.1.110

This will act as a marker and you will know that the problem happened a second or two before the ping.

answered 04 Aug '14, 15:11

PaulOfford's gravatar image

PaulOfford
131283237
accept rate: 11%

Ok, so I have tried using Trace Wrangler without luck, the program just crashes while anonimizing the trace file. Even if it did work I don't feel confident putting a trace file in the internet of my network for anybody to analyze, I am a newbie at this and don't feel comfortable doing that. So, I will do the next best thing, I will post more screen shots, and hope you guys can keep helping figure out this problem that has me pulling my hair out and my boss on my back.

I noticed a couple of weird things, I get radom ICMP Destination unreachable errors in my logs, on multiple computers to the server, and to other computers

My network mappings keep getting reset on some machines and as a result the erp application complains about the path not being available.

I have taken the wins server out of the equation all together.

THIS SCREENSHOT is from one of my workstations (192.168.2.42) in a remote location connected via vpn, but I am similar traffic in computers in the same subnet as the server which is (192.168.1.110)

(06 Aug '14, 21:16) geo77

Hi Geo,

I don't think I can help here. The only way I can diagnose a problem is to focus intensely on one instance of one symptom and work out what went wrong.

There are other approaches to problem diagnosis such as collecting examples of various symptoms and trying to establish a pattern, which is the approach I think you are taking. With a bit of luck there will be someone reading the information you have posted who will recognize the pattern.

Best regards...Paul

(07 Aug '14, 23:50) PaulOfford

@geo77, @PaulOfford

Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information.

(08 Aug '14, 02:52) grahamb ♦

Sorry Graham - my mistake.

(08 Aug '14, 08:06) PaulOfford