Re: kern/99188: [tcp] [patch] FIN in same packet as duplicate ACK is lost



The following reply was made to PR kern/99188; it has been noted by GNATS.

From: Staffan Ulfberg <staffan@xxxxxxxxxx>
To: bug-followup@xxxxxxxxxxx
Cc:
Subject: Re: kern/99188: [tcp] [patch] FIN in same packet as duplicate ACK is lost
Date: 20 Jun 2006 21:49:16 +0200

I forgot to say that the Windows XP test code in the PR was compiled
using the "cl" command line compiler from Microsoft Visual Studio.

Anyway, when runnging the test code in the report, the following is a
dump of the last packets captured by tcpdumpa dn presented by ethereal:

No. Time Source Destination Protocol Info
135 23:48:02.409915 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=122401 Ack=1 Win=65535 Len=1360
136 23:48:02.409922 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=123761 Ack=1 Win=65535 Len=1360
137 23:48:02.409926 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=125121 Ack=1 Win=65535 Len=1360
138 23:48:02.409932 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=126481 Ack=1 Win=65535 Len=1360
139 23:48:02.409936 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=127841 Ack=1 Win=65535 Len=1360
140 23:48:02.409939 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=129201 Ack=1 Win=65535 Len=1360
141 23:48:02.410012 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=121041 Win=65535 Len=0
142 23:48:02.410029 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=130561 Ack=1 Win=65535 Len=1360
143 23:48:02.410033 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=131921 Ack=1 Win=65535 Len=1360
144 23:48:02.410037 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=133281 Ack=1 Win=65535 Len=1360
145 23:48:02.431375 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=125121 Win=65535 Len=0
146 23:48:02.431378 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=127841 Win=65535 Len=0
147 23:48:02.431380 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=131921 Win=65535 Len=0
148 23:48:02.431382 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=134641 Win=65535 Len=0
149 23:48:02.431384 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [FIN, ACK] Seq=1 Ack=134641 Win=65535 Len=0
150 23:48:02.431399 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [PSH, ACK] Seq=134641 Ack=1 Win=65535 Len=1360
151 23:48:02.647004 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=2 Ack=136001 Win=65535 Len=0
152 23:48:03.413573 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [RST, ACK] Seq=2 Ack=136001 Win=0 Len=0

10.0.3.5 was the client computer, and 172.22.32.206 was the server.

After the session above, the socket on the server was in "ESTABLISHED" state.

Staffan

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Packet cap diff... for classic dhcp over winxp s/w bridge prob.
    ... the server simultaneously. ... DHCP Discover - Transaction ID 0xe5448fbb ... Time delta from previous packet: ... Time since reference or first frame: ...
    (comp.os.linux.networking)
  • [Full-disclosure] Quick Blind TCP Connection Spoofing with SYN Cookies
    ... TCP uses 32 bit Seq/Ack numbers in order to make sure that both sides of a connection can actually receive packets from each other. ... these numbers make it relatively hard to spoof the source address because successful spoofing requires guessing the correct initial sequence number which is generated by the server in a non-guessable way. ... This article shows that the effort required for guessing a valid ISN can be reduced from hours to minutes if the server uses TCP SYN Cookies, which are enabled by default for various Linux distributions including Ubuntu and Debian. ... The Client sends a SYN packet to the server in order to initiate a connection. ...
    (Full-Disclosure)
  • Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: How to terminate a socket in CLOSE_WAIT state
    ... FTP Server fixed for certain FTP clients who use both passive ... This was causing a PASSIVE opened socket to be left ... but instead expect the "half close" from the receiver. ... this sends a TCP/IP FIN packet to the ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Sockets class question - sending TCP data
    ... Announcement DEV02, Workstation, Server, SQL Server, NT Workstation, NT ... Time delta from previous packet: ... Receiver's Name: DYNAMICSYSTEMS(Local Master Browser) ... You say that you did this in a Java applet. ...
    (microsoft.public.dotnet.languages.csharp)