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

Remoteapp connection drop

0

Hello friends, I'm trying to troubleshoot the remoteapp intermitent connection drop. we have a 3 RDS Servers and one connection Broker and a Hardware loadbalancer. Uers get disconnected randomly and it's completely random. So i have decided to monitor the connections on one of the RDS servers and i see quite a few colour coded as Black. Can someone have a look at this let me know what is happening here?

regards mat

asked 28 Aug '13, 06:29

RAINBOW007's gravatar image

RAINBOW007
11112
accept rate: 0%

can someone let me know how i can attach my pcap zip file here please?

(28 Aug '13, 06:34) RAINBOW007

Can someone have a look at this let me know what is happening here?

a look at what?

(28 Aug '13, 06:36) Kurt Knochner ♦

Hi Kurt, Sorry i was trying to attach a file but i see no option here.Can you tell me how i can upload my wireshark dump file please?

(28 Aug '13, 06:40) RAINBOW007

Can you tell me how i can upload my wireshark dump file please?

Google drive, Dropbox, Cloudshark (HINT: You can't delete files later), etc.

(28 Aug '13, 06:47) Kurt Knochner ♦
(28 Aug '13, 06:54) RAINBOW007

if required i can upload a complete dump. the above is only a filtered pcap file. thanks

(28 Aug '13, 06:55) RAINBOW007
showing 5 of 6 show 1 more comments

One Answer:

0

and i see quite a few colour coded as Black.

That's just because the IP checksum in the packet is different than the one generated by Wireshark, probably due to IP checksum offloading into the NIC driver.

Header checksum: 0x0000 [incorrect, should be 0x380b (may be caused by "IP checksum offload"?)]

Regarding your question:

I'm trying to troubleshoot the remoteapp intermitent connection drop.

There are two TCP Reset in the capture file and both are sent from the client to the server.

tcp.flags.reset eq 1

In the capture file itself there is no indication why the connection was closed. The client could have received all requested data or it could have received data it did not expect (see logs) and thus closed the connection with a RESET.

So, what are the symptoms of the 'connection drop'? Any messages in the logs? You need the time stamps of those events and then see if there are any 'unusual' events in the capture file at the same time stamp, given, that the time of the involved systems and the capture machine are in sync.

You say, there is a load balancer involved. I guess you have 'sticky connections' (connection persistence) enabled. Maybe the problem is caused by a timeout of some sticky connections. In that case, you would need a capture file near the client and right after the load balancer.

Regards
Kurt

answered 28 Aug '13, 07:14

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 28 Aug '13, 07:30

Hi Thanks for your kind reply.the pcap file i sent was between the RDS server and the SQL server(192.168.6.19). regarding the TCP Checksum offload. I can see TCP Checksum offload has been disabled on SQL server(192.168.6.19), but not on RDS server. Is it really a requirement in a Vmware environment(Vsphere 5.1)? do you want me to leave the default settings of VM NIC (Vmxnet3) or disable TCP checksum offload on All RDS servers to match SQL server in question? There are event loggs relating to the connection drop. The application we use is a bespoke one, but used by several companies. application closes all of a sudden while the users were actively working on the machine and they had reopen the application again to get connected to a disconnected session.

thanks Mat

(28 Aug '13, 07:37) RAINBOW007

do you want me to leave the default settings of VM NIC (Vmxnet3) or disable TCP checksum offload on All RDS servers to match SQL server in question?

Checksum offloading will (most certainly) have no effect at all on your problem. So, please leave everything as it is.

There are event loggs relating to the connection drop.

Good. Please get the time stamps of those events and check if there is anything "suspicious" in the full capture file. HINT: Please ensure that the time on all involved systems is in sync up to milliseconds, otherwise you will look at the wrong place in the capture file.

application closes all of a sudden while the users were actively working on the machine and they had reopen the application again to get connected to a disconnected session.

As I mentioned, this could be caused by a problem with 'sticky sessions' (persistent connections) on the load balancer or with connection timeouts (for whatever reason). To identify such a problem you need to capture at several capture points in parallel, as I mentioned in my answer.

To rule out the load balancer you can also define a pool with just one backend server and see if the problem is still there. If it disappears with one server the problem is (most certainly) related to sticky sessions.

BTW: The source/destination IP are in the same subnet and the MAC addresses are all VMware. Are you sure there is a load balancer involved? If so, is it a virtual device (e.g. F5 VE)?

(28 Aug '13, 08:46) Kurt Knochner ♦

Hi Ya, thanks for your reply. Sorry my mistake in typing. Actually i do not have any event logs showing connection drops. You said there is no problem with TCP Checksum. So What should i do about the SQL server, where currently the TCP Checksum offload has been disabled? Should i leave it? or revert it back to 'enable' which is default?

I'll try looking into loadbalancer, but these sudden connection drops were before introducing the Hardware Load balancer.

thanks mat

(28 Aug '13, 09:02) RAINBOW007

Actually i do not have any event logs showing connection drops.

well, then have a look at the load balancer.

So What should i do about the SQL server, where currently the TCP Checksum offload has been disabled?

as I said: TCP checksum offloading is (most certainly) not part of the 'connection drop' problem, so if you changed anything, please revert that, as it may have an Impact on other things!!

I'll try looking into loadbalancer, but these sudden connection drops were before introducing the Hardware Load balancer.

As I said: The IP and MAC address in your capture file show no indication of a (hardware) load balancer! Are you sure that there is a load balancer involved in the communication shown in the capture file and that the capture file actually contains a connection that was 'dropped'?

(28 Aug '13, 09:10) Kurt Knochner ♦