Date: Mon, 15 Jun 2009 13:14:13 +0530 (IST) From: saravana perumal <seesaravanan@yahoo.co.in> To: Louis Mamakos <louie@transsys.com> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Subject: Re: TCP Free-BSD setup behaviour. Message-ID: <882612.80583.qm@web8320.mail.in.yahoo.com>
next in thread | raw e-mail | index | archive | help
Hi Louie , =A0 =A0 Thanks for the Response on my Queries. =A0 For QUERY 3,=20 ACTIVE open frm Free BSD end: =A0 =A0=A0=A0=A0=A0=A0 FREE BSD=A0=A0=A0=A0=A0=A0=A0=A0=A0 APPLICATION =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Send ---------> syn =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Receive <-------- SYN =A0 Expect SYN & ACK-------------> Getting only ACK in this Scenario, =A0Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sen= ding only ACK message as the response. 4=A0=A0=A0 .When checking the State - TIME-WAIT=A0=A0=A0=A0Sending FIN and = expecting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment a= nd Expecting the RST signal not getting the RST ; Instead DUT is sending th= e Last TCP packet.=A0Issue seen only in Free BSD =A0 =A0 For this Issue mentioned above, Last TCP packet is jst a Testing packet wit= h the=20 following Field set=A0 in TIME-WAIT state , =A0 =A0 TCP: ---- TCP Packet ---- TCP: TCP: Source Port=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 16815 (16815) TCP: Destination Port=A0=A0=A0=A0=A0 =3D 16816 (16816) TCP: Sequence Number=A0=A0=A0=A0=A0=A0 =3D 3865716731 (0xE66A27FB) TCP: Acknowledgment Number =3D 0 (0x00000000)=20 TCP: Data Offset=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 5 (20 bytes) TCP: Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0=20 TCP: Control Bits=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x10 TCP:=A0 |543210 TCP:=A0 |0.....=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D Urgent Pointer I= sn't Significant TCP:=A0 |.1....=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D Acknowledgment I= s Significant TCP:=A0 |..0...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Push Function TCP:=A0 |...0..=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Reset Connect= ion TCP:=A0 |....0.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Synchronize S= equence Numbers TCP:=A0 |.....0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D More Data From S= ender TCP: Window=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 32752 bytes TCP: Checksum=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x41A0 (Correct) TCP: Urgent Pointer=A0=A0=A0=A0=A0=A0=A0 =3D 0 (Not Significant) TCP: TCP: --- Trailing Data [12 bytes] --- TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Sample Data. TCP: --- Trailing Data End --- >From machine Sending=A0 to the FREE BSD machine, =A0 This is to verify that Free BSD is in TIME-WAIT state. =A0 =A0 Thanks, Saravanan --- On Sat, 6/13/09, Louis Mamakos <louie@transsys.com> wrote: From: Louis Mamakos <louie@transsys.com> Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" <seesaravanan@yahoo.co.in> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Saturday, June 13, 2009, 10:54 PM On Jun 10, 2009, at 9:47 AM, saravana perumal wrote: >=A0 Hi , >=20 >=A0=A0=A0Have some behaviour change=A0 with FREEBSD=A0 compared to=A0 LINU= X . You probably ought to verify the behavior against the protocol specificatio= ns, and not what some other TCP implementation happens to to. >=20 > 1. When sending the Same=A0 TCP packet once again [ Retranmission of TCP = packet ] Whether the Same Identification field [ IP packet]used or not . > but when seeing that thru packet capture, Free BSD sending the differnt o= ne [ increases sequentially IP Identification] The IPID header field is used for reassembly of IP fragments, and is not of= consequence to TCP.=A0 If the protocol stack absolutely knows that a TCP r= etransmission is identical to the previous segment, then in theory, it coul= d use the same IPID fields to increase the chance that a previously fragmen= ted TCP segment with a lost segment could get reassembled with fragments fr= om the retransmission.=A0 Since there's much work done to avoid fragmentati= on in the first place (e.g., using Path MTU discovery), this "feature" prob= ably never gets used. This behavior makes more sense if the TCP implementation keeps around a ret= ransmit queue of previously sent packets, rather than simply generating new= TCP segments with whatever data happens to be in the TCP send window at th= e time of the retransmission attempt. >=20 > 2.Retranmission Time is not increasing Linearly with Respect to BSD. not = keeping more time interval . AS per RFC > expecting Retransmission timeout should=A0 increase Linearly. Issue is no= t seen with Linux Setup Retransmission time is highly dependent on many factors, like the implement= ation of TCP slow-start, what the TCP stack has estimated as the round-trip= time, etc.=A0 In the general case, over the span of many retransmissions, = the sending TCP stack should back-off the retransmit times. >=20 > 3. Active SYN open state in FREE BSD setup , Does not reach Syn-received = State. When Sending syn packet to DUT but=A0 for that FreeBSD is not sendin= g back > SYN/ACK .=A0 Issue is with Free BSD Setup.Linux works fine, If the FreeBSD system is doing a TCP active open (e.g., a connect() system = call), then it sends a SYN to the remote TCP, and expects a SYN/ACK back fr= om the remote system.=A0 At that point, since the remote has ACK'd the SYN,= it should correctly respond with simply an ACK of the remote TCP's SYN, an= d perhaps any data that might have been piggybacked in the ACK segment.=A0 = There's no need to retransmit the SYN. Or is the remote system doing the active open to the FreeBSD system?=A0 It'= s hard to believe that the FreeBSD TCP can't respond to an incoming TCP seg= ment to a listening socket carrying a SYN segment? >=20 > 4.When checking the State - TIME-WAIT >=A0=A0=A0Sending FIN and expecting the ACK ;Getting the ACK properly. >=A0=A0=A0Sending Data Segment and Expecting the RST signal not getting the= RST ; Instead DUT is sending the Last TCP packet. >=20 > Issue seen only in Free BSD. I may be misunderstanding.=A0 When in TIME-WAIT state, the local TCP is wai= ting for a bit in case the "final" ACK of the remote TCP's FIN got lost, an= d the remote retransmits the FIN (and perhaps any data that might have been= in the window along with the FIN).=A0 The local TCP shouldn't generate a R= ST assuming that the remote's retransmitted TCP segment is still within the= window.=A0 I'm not sure what's in the "Last TCP packet." >=20 > Same issue in FIN-WAIT2=A0 & FIN-WAIT1 State also . >=A0=A0=A0Sending FIN and Expect the ACK : Getting the ACK >=A0=A0=A0Sending Data segment with Data : Expecting the RST signal from DU= T ; but got Last transmitted TCP packet[ FIN -ACK] >=20 Ditto. > Any idea about the above scenario would be helpful >=20 > Thanks, > Saravanan. The TCP in Linux is hardly the reference implementation; with the TCP stack= in various 4.xBSD varients preceeding it by many years, not to mention man= y others implementations in other platforms.=A0 I'm not sure looking for va= riances between some random Linux TCP stack is really the right way to appr= oach testing. louie =0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?882612.80583.qm>