From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 14:14:40 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 C3DCB10656C5 for ; Tue, 16 Jun 2009 14:14:40 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8318.mail.in.yahoo.com (web8318.mail.in.yahoo.com [202.43.219.53]) by mx1.freebsd.org (Postfix) with SMTP id 6AC718FC52 for ; Tue, 16 Jun 2009 14:14:39 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 59980 invoked by uid 60001); 16 Jun 2009 14:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245161677; bh=CFP5O+WPCokLpEEr2wBeLqk/yLXRxSy2Fh2bE+Qm/7k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=oADB2xdyHIpMwuoX683XN5H7BbpBzEEXGLbAQmYFX8hHdImee6v88oCmSvvfK7Dqj2KtEykE1jXH4P7dbLgt9sEhFWuC3PY+vbmv6ns6zgyKl7sqvNx4Biui1uFvF3BecPREzEf3VB/LkMfhQn8NRTEfyskihXGdWQg1xwXge+o= 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=PE1D3JNE/ctJU8fJy5PHVZDKf4846R7Wpm2X1yl0hi+yTN1x+pP1a2dyPcV7NwXjebr5AacfF5porT0quZL/VV6O2U8PPvlYTaDUE94drzbLBbpoPiYKudqqnSWirXUB6hfHFrSwIF+lNmziTl2X/RocApt0sR/J6eOiVcq0Lhs=; Message-ID: <576824.58716.qm@web8318.mail.in.yahoo.com> X-YMail-OSG: Fu9LOjwVM1kZXhpZVYHSIMK4hCjCbrEcleOvxD_n66mwzZXbCY7rrRudQoIlnjJArD6mPuDYT7a34Rqfq.vGZAl912ljylW3XTeVOZroPRZwpZ1ffQPcrIv1hzh_LcWd33Z8sm5U7SNSB7be6SayCM58gqsEzS2ulplxCgpbUOBm8kuj1bdGqAzovufQOMvInSYiT4uY3vn_qDay3ELg3FP0yNiH3lhSOUF6QdJTZw-- Received: from [125.22.253.101] by web8318.mail.in.yahoo.com via HTTP; Tue, 16 Jun 2009 19:44:37 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Tue, 16 Jun 2009 19:44:37 +0530 (IST) From: saravana perumal To: Erik Trulsson , Harti Brandt 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 Mailer List 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: Tue, 16 Jun 2009 14:14:51 -0000 Hi Erik =A0 =A0 Have a look into the below link =A0 http://www.jxos.org/Projects/TCP/tcpstate.html =A0 See how from CLOSED----------> SYN sent ---------> syn Received=A0 state. =A0 Let me know if anything I am missing here. =A0 Thanks. Saravanan --- On Tue, 6/16/09, Harti Brandt wrote: From: Harti Brandt Subject: Re: TCP Free-BSD setup behaviour. To: "Erik Trulsson" Cc: "saravana perumal" , "FreeBSD Mailer List" Date: Tuesday, June 16, 2009, 5:47 PM On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi=A0 Louie. ET>> =A0 ET>> As per Testing=20 ET>> =A0 ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and=20 ET>> 3. To Send SYN & ACK=A0 to reach=A0 SYN-RCVD state. ET> ET>That does not sound quite correct.=A0 The normal sequence for the TCP ET>three-way handshake is: ET> ET>=A0 =A0 -----> SYN ET>=A0 =A0 <----- SYN+ACK ET>=A0 =A0 -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET>=A0 =A0 -----> SYN ET>=A0 =A0 <----- SYN ET>=A0 =A0 -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> =A0 ET>> In Free BSD active SYN-RCVD state is not happening . ET>> =A0 ET>> In TCP state tranistion my expectation is represented for SYN_RCVD sta= te. ET>> =A0 ET>> =A0 ET>> Thanks. ET>> Saravanan ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, saravana perumal wrote= : ET>>=20 ET>>=20 ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> Hi Louie ET>> =A0 ET>> =A0We are trying to make Active Sync Received state. ET>> =A0 ET>> As per our testing we are trying to received Syn packet from APPLICATI= ON end and to send syn & ACK from Device END and hence reaching the ACTIVE = SYN-RECEIVED state. ET>> =A0 ET>> So initially make the application to send SYN sending the Initial SYN = and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> =A0 ET>> I hope the expectation should be rite in case of ACTIVE-SYN received S= tate. ET>> =A0 ET>> Thanks. ET>> Saravanan ET>> =A0 ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>>=20 ET>>=20 ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>>=20 ET>>=20 ET>>=20 ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>>=20 ET>> > Hi Louie , ET>> >=20 ET>> >=20 ET>> > Thanks for the Response on my Queries. ET>> >=20 ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> >=20 ET>> >=A0 =A0 =A0 =A0 FREE BSD=A0 =A0 =A0 =A0 =A0 APPLICATION ET>> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Send ---------> syn ET>> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Receive <-------- SYN ET>> >=20 ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> >=20 ET>> >=A0 Now Expects FREE BSD to respond back with the SYN & ACK , but BSD= is sending only ACK message as the response. ET>>=20 ET>> There's no reason why the FreeBSD host would send another SYN; presuma= bly the "APPLICATION" host received the SYN and responds back with SYN of i= t's own and ACK of the FreeBSD host's SYN.=A0 Once the SYN has been ACK'd, = there's no reason to resend it.=A0 I suppose I wonder why you expect the Fr= eeBSD system to retransmit it's SYN? ET>>=20 ET>> > 4=A0 =A0 .When checking the State - TIME-WAIT=A0 =A0 Sending 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 t= he Last TCP packet. Issue seen only in Free BSD ET>> >=20 ET>> >=20 ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing pac= ket with the ET>> > following Field set=A0 in TIME-WAIT state , ET>> >=20 ET>> >=20 ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port=A0 =A0 =A0 =A0 =A0=A0=A0=3D 16815 (16815) ET>> > TCP: Destination Port=A0 =A0 =A0 =3D 16816 (16816) ET>> > TCP: Sequence Number=A0 =A0 =A0=A0=A0=3D 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number =3D 0 (0x00000000) ET>> > TCP: Data Offset=A0 =A0 =A0 =A0 =A0=A0=A0=3D 5 (20 bytes) ET>> > TCP: Reserved=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 ET>> > TCP: Control Bits=A0 =A0 =A0 =A0 =A0 =3D 0x10 ET>> > TCP:=A0 |543210 ET>> > TCP:=A0 |0.....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Urgent Pointer Isn't = Significant ET>> > TCP:=A0 |.1....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Acknowledgment Is Sig= nificant ET>> > TCP:=A0 |..0...=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Push Function ET>> > TCP:=A0 |...0..=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Reset Connection ET>> > TCP:=A0 |....0.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Synchronize Sequen= ce Numbers ET>> > TCP:=A0 |.....0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D More Data From Sender ET>> > TCP: Window=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 32752 bytes ET>> > TCP: Checksum=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x41A0 (Correct) ET>> > TCP: Urgent Pointer=A0 =A0 =A0 =A0 =3D 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0=A0Sample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending=A0 to the FREE BSD machine, ET>> >=20 ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>>=20 ET>> Not sure what good this packet trace is; the only reason the TCP would= respond with a RST segment is if the segment it receives is somehow bogus.= =A0 Perhaps that the send sequence is outside the window.=A0 If the data is= within the window, it might be considered an "old" segment that happens to= arrive, perhaps out-of-order; why would the local TCP reset the connection= for no good reason? ET>>=20 ET>> louie ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> _______________________________________________ ET>> freebsd-net@freebsd.org mailing list ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ET> ET>=0A=0A=0A