[e2e] Is this a bug with Windows TCP Stack ?

[Goutham S Mohan]

I have a TCP client which does a HTTP-POST to IIS 5.0 / 6.0. When the webserver completes sending data, it does an active close and moves into the FIN_WAIT_2.

By this time, the client is still reading the data from the socket buffer. After a timeout, IIS is sends a RST to the client TCP. This stops the client from reading the data from the buffer. read() errors out with a ECONNRESET. 

My question is, "Why does the Windows TCP stack send an RST when in FIN_WAIT_2 ? Is this an intended behaviour ?" 

Just thought I will attach the TCP dump of the communication:

tcpdump: listening on lan0

17:44:38.866196 forti.58705 > mustangrr.http: S 3780990706:3780990706(0) win 32768 <mss 1460,wscale 0,nop> (DF)

17:44:38.867048 mustangrr.http > forti.58705: S 1452070376:1452070376(0) ack 3780990707 win 17520 <mss 1460,nop,wscale 0> (DF)

17:44:38.867336 forti.58705 > mustangrr.http: P 1:163(162) ack 1 win 32768 (DF)

17:44:38.867508 forti.58705 > mustangrr.http: P 163:204(41) ack 1 win 32768 (DF)

17:44:38.867547 forti.58705 > mustangrr.http: P 204:262(58) ack 1 win 32768 (DF)

17:44:38.867572 forti.58705 > mustangrr.http: P 262:303(41) ack 1 win 32768 (DF)

17:44:38.868047 forti.58705 > mustangrr.http: P 303:357(54) ack 1 win 32768 (DF)

17:44:38.868071 forti.58705 > mustangrr.http: P 357:398(41) ack 1 win 32768 (DF)

17:44:38.868097 forti.58705 > mustangrr.http: P 398:457(59) ack 1 win 32768 (DF)

17:44:38.868123 forti.58705 > mustangrr.http: P 457:498(41) ack 1 win 32768 (DF)

17:44:38.868156 forti.58705 > mustangrr.http: P 498:623(125) ack 1 win 32768 (DF)

17:44:38.868188 forti.58705 > mustangrr.http: P 623:664(41) ack 1 win 32768 (DF)

17:44:38.868214 forti.58705 > mustangrr.http: P 664:718(54) ack 1 win 32768 (DF)

17:44:38.868244 forti.58705 > mustangrr.http: P 718:761(43) ack 1 win 32768 (DF)

17:44:38.868275 forti.58705 > mustangrr.http: P 761:762(1) ack 1 win 32768 (DF)

17:44:38.869140 mustangrr.http > forti.58705: . ack 204 win 17317 (DF)

17:44:38.869166 mustangrr.http > forti.58705: . ack 303 win 17218 (DF)

17:44:38.869228 mustangrr.http > forti.58705: . ack 398 win 17123 (DF)

17:44:38.869296 mustangrr.http > forti.58705: . ack 498 win 17023 (DF)

17:44:38.872038 mustangrr.http > forti.58705: . ack 664 win 16857 (DF)

17:44:38.872061 mustangrr.http > forti.58705: . ack 761 win 16760 (DF)

17:44:38.887618 mustangrr.http > forti.58705: P 1:228(227) ack 762 win 16759 (DF)

17:44:38.888503 mustangrr.http > forti.58705: FP 228:780(552) ack 762 win 16759 (DF)

17:44:38.888537 forti.58705 > mustangrr.http: . ack 781 win 32768 (DF)

17:44:38.888559 mustangrr.http > forti.58705: R 1452071157:1452071157(0) win 0 (DF)

17:44:38.888884 mustangrr.http > forti.58705: R 1452071157:1452071157(0) win 0

 12431 packets received by filter

0 packets dropped by kernel

I could not figure out why on earth Windows TCP sends an RST, but however it was a simple fix for me in my application. 

The client now sends Keep-Alives so that, the web svr which by definition does a active close will not do so. This allows my client to keep the connection alive and do the active close when its done with its job.



I did post this into Microsoft IIS newsgroups, it wasn’t of any use. 

Found a similar article posted in 2003 :-

http://www.postel.org/pipermail/end2end-interest/2003-January/002599.html

Regards,

Goutham S Mohan

---------------------------

Software Engineer, 

Hewlett Packard [Global Delivery India Center]



		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Helps protect you from nasty viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041201/50bf0d85/attachment.html