PSH, ACK; FIN, ACK; PSH, ACK; RST,ACK;

Question

i copied the picture url::https://i.stack.imgur.com/ORq6X.png

1) 53165->8475 Psh,Ack Len 57; 2) 53165->8475 Fin,Ack len 0; 3) 8475 ->53165 Psh,Ack len 0; 4) 53165->8475 Rst,Ack len 0

My scenario:: 53165(windows server) is the source 8475(mainframe -OS/400) is the destination machine

53165(Source) port sending data and waiting for the response from port 8475.

8475(destination) takes 15 minutes to execute and will reply back but unfortunately tcp connection is getting closed after 2 minutes So the source is never getting the result back. I have to correct this.

Please explain which system is responsible for closing the connection? Can you explain me what is happening? Why the connection is getting closed?

Answer 1

2

The Client (Port 53165) closes the Connection with a FIN packet. That is no problem normally the mainframe is allowed to send his data as long as he sends a FIN, too. But when the Mainframe ACKs the FIN, the Client terminates teh Session with an RST and no more data is allowed to send.

answered 22 Feb '17, 14:32

Christian_R
1.8k●2●6●25
accept rate: 16%

"But when the Mainframe ACKs the FIN,"

mainframe cannot send the data until 15 minutes. It takes 15 minutes for mainframe to execute the request. So the underlying protocol TCP(mainframe) do not has any response other than zero bytes.

So mainframe cannot send the data as soon as it recieved FIN.

(22 Feb '17, 14:54) vaibhav_v

The mainframe can't send data after it has received the client's Reset.

It appears that your client is timing out the connection - probably due to no activity. You need to be focussing on how to make the client keep the connection open for longer.

Or can you make the PC and/or mainframe keep the connection going by sending Keep-Alive packets.

(22 Feb '17, 19:35) Philst

Thank you, i will try that. Actually I dont know i can do that because i am calling a .net program which is using tcp.

(23 Feb '17, 09:27) vaibhav_v

Do you use z/OS or which OS does the Mainframe use?

(23 Feb '17, 11:27) Christian_R

As it is long time ago I have worked with z/OS, here is what I googled for z/OS at the TCPIP.Profile configuration Reference, but maybe @mrEEde could help you further:

INTERVAL default_keepalive_interval
    The default TCP keepalive interval for applications that enable the SO_KEEPALIVE socket option and do not override the interval using the TCP_KEEPALIVE socket option. The range is 0 - 35791 minutes, and the default is 120. A value of 0 disables the keepalive function, so that sockets for which SO_KEEPALIVE is specified do not perform TCP keepalive. In this case, sockets specifying a specific interval using TCP_KEEPALIVE continue to send keepalive probes.
TCP keepalive probes end TCP connections after a period of inactivity. TCP keepalive is disabled by default for a connection, but can be enabled by issuing the SO_KEEPALIVE or TCP_KEEPALIVE socket options. The TCP_KEEPALIVE socket option enables the application to specify the keepalive probe interval, while the SO_KEEPALIVE socket option uses default_keepalive_interval as the interval.

After the interval has expired, TCP sends a single keepalive probe to the peer. If the TCP_KEEPALIVE socket option is not used to specify the probe interval, a total of ten probes are then sent at 75-second intervals if no response is received from the peer. If no response has been received 75 seconds after the last probe, the connection is reset. If TCP_KEEPALIVE is used to specify the keepalive probe interval, the number of probes and the interval between the probes might differ depending on the interval specified.</code></pre></div><div id="comment-59639-info" class="comment-info"><span class="comment-age">(23 Feb '17, 11:39)</span> <span class="comment-user userinfo">Christian_R</span></div></div><span id="59641"></span><div id="comment-59641" class="comment not_top_scorer"><div id="post-59641-score" class="comment-score"></div><div class="comment-text"><p>I am doing research on what you just informed, I will keep you posted.</p></div><div id="comment-59641-info" class="comment-info"><span class="comment-age">(23 Feb '17, 13:25)</span> <span class="comment-user userinfo">vaibhav_v</span></div></div><span id="59644"></span><div id="comment-59644" class="comment not_top_scorer"><div id="post-59644-score" class="comment-score"></div><div class="comment-text"><p><span>@Christian_R</span></p><p>Can you summarize what happening with my request? Client(windows-53165) closes the connection with FIN and Mainframe acknowledges the FIN.So client terminates the session.</p><p>So here the culprit is mainframe's configuration right? As mainframe acknowledges the fin.</p><p>So i have to correct the mainframe tcp ip configuration, not the windows. Is it right?</p></div><div id="comment-59644-info" class="comment-info"><span class="comment-age">(23 Feb '17, 14:31)</span> <span class="comment-user userinfo">vaibhav_v</span></div></div><span id="59645"></span><div id="comment-59645" class="comment not_top_scorer"><div id="post-59645-score" class="comment-score"></div><div class="comment-text"><p>Please look at the successful process's trace here::</p><p><img src="https://i.stack.imgur.com/pWW2J.png" width="640" /></p><p>52531 - windows(client) , 8475- mainframe (server)</p><pre><code>1) 52531-&gt;8475 Psh,Ack Len 57;


52531->8475 Fin,Ack len 0;
8475->52531 Psh,Ack len=0
8475->52531 Psh,Ack len=38
8475->52531 Fin,Psh,Ack len=0
52531->8475 Ack Len=0

I removed the delay, now the server(mainframe) responds immediately so i got the success.

But in reality, my process will have the 15 min delay. So i have to correct this.

(23 Feb ‘17, 14:42) vaibhav_v

OS/400 - is the OS for mainframe

(23 Feb ‘17, 14:54) vaibhav_v

Well the mainframe reacts correct. Would be helpful if you could share the trace or at least the time column

(23 Feb ‘17, 14:58) Christian_R

windows(client) , 8475- mainframe (server)

Failure::

Client sends the request, mainframe takes 15 minutes to execute the request. So mainframe cannot send any response until 15 minutes. Getting an error after 2 minutes on the client side.

Error::
{"HISMDTT0006 The DPCTransport received a socket error while attempting to receive user data when processing method P4667. IP Address: xx.xxx.xxxxx.xxxx, port: 8475, program name: P4667, Error description: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."}

Success::

Client sends request, This scenario mainframe only takes 5 secs to execute the request. So Client(windows) is getting back the response back .

Can you help me who is the culprit mainframe(server- 8475 port) or windows(client)?

(23 Feb ‘17, 15:32) vaibhav_v

Hi @vaibhav_V I have converted your answers to comments, as they are more comments for me.

Thank you for the timings. Yeah now we clearly can see the things. Well The windows system terminates the session 2 minutes after the FIN which would be ok. So now you can do different things from my point of view.

The windows client should finish (FIN) the session first after he receives the answer from the mainframe (my preffered way)
Try to play with keepalives
Try to play with the FINWAIT1 Timer at client side

(24 Feb ‘17, 03:55) Christian_R

@Christian_R

I already played with Below entries in windows(client). “TcpTimedWaitDelay=300”, “TcpMaxDataRetransmissions= 5” ; “KeepAliveInterval= 1” ;StrictTimeWaitSeqCheck=1 and other. Nothing really helped. As you have mentioned i will try again, to makesure.

Please check my windows(client) registry entries:: alt text

At comment section i am unable to add image- there is no image icon that is why i am posting as an answer so that i can copy url as an image.

(24 Feb ‘17, 07:51) vaibhav_v

““““TCPIP driver won’t start sending TCP Keepalives until Keepalives are enabled via various methods at upper layers (layers above TCPIP driver). "”” Source:: https://blogs.technet.microsoft.com/nettracer/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives/

above link says, i have to set those values explicitly by program otherwise those registry values will remain ineffective.

(24 Feb ‘17, 08:11) vaibhav_v

If I were you I would really try to tune the client application behaviour. Or to find out why the mainframe needs 15 Minutes????

(24 Feb ‘17, 20:52) Christian_R

Thank you, i will try the same.

(27 Feb ‘17, 08:51) vaibhav_v

showing 5 of 16 show 11 more comments