From owner-freebsd-net@FreeBSD.ORG Mon Jun 15 07:44:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18460106564A for ; Mon, 15 Jun 2009 07:44:17 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8320.mail.in.yahoo.com (web8320.mail.in.yahoo.com [202.43.219.75]) by mx1.freebsd.org (Postfix) with SMTP id E28858FC08 for ; Mon, 15 Jun 2009 07:44:15 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 81898 invoked by uid 60001); 15 Jun 2009 07:44:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245051853; bh=wjpb/LFXMaKSy269MqpL9zGR6M6+Ii98YRyzhGTgHKo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Z4caUA4ZhrAPghq59uPC0uy5wBRYTdY6z9B/JX05wtGUSFTVHAdC13psc99bCa+qkRiiXJxcYb13I3L5quGYGB3zLt1FjQyU/J1nokHg/N8FXo38qnbo1SI4XKmfBU3zyV1zYEuxQSnf4rn4hKS/95buTsX3UZuJt8opRpHRGi4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=dft1IXrAFz59phK8D/NW6fe1iiz/5YRPXwoOx1gViH2obpIIHHC7yM+qUJYhuDroIBDZFR4X+inpB4FFSUfD6tRf/kWkB32gzUNiFZopsERIG7jq4FEuC6hH8ErOAZnNacvT5VC/vQ3b4WOGIQsZk0EvnChs12p/n6rQ2uEq4Fc=; Message-ID: <882612.80583.qm@web8320.mail.in.yahoo.com> X-YMail-OSG: 9.GCwRkVM1lutkOQfuP9kSfIaPgQJT4Zyoo2.B2qh4fXJyDOdJcwDNdgLDBfuTt4eBjdprhG8.DiuSTDs6BiZP4xojSzaF7TUaqf.gcnrbm7V59YQEc.EIGtazeIRJ6onGLelHhaTjxdZJJx0aTVRWaifbIGkr_fJsTm4lr1WbmhPlj.zcTVpApIxjvzFO6aB6PxspE4zXrbrzvG7Kj0aqLinPdQC1Qp3_Oq4z1_eD1ljZIBHw-- Received: from [125.22.253.101] by web8320.mail.in.yahoo.com via HTTP; Mon, 15 Jun 2009 13:14:13 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Mon, 15 Jun 2009 13:14:13 +0530 (IST) From: saravana perumal To: Louis Mamakos MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Subject: Re: TCP Free-BSD setup behaviour. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 07:44:17 -0000 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 wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" 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