Date: Tue, 16 Jun 2009 14:17:16 +0200 (CEST) From: Harti Brandt <hartmut.brandt@dlr.de> To: Erik Trulsson <ertr1013@student.uu.se> Cc: FreeBSD Mailer List <freebsd-net@freebsd.org>, saravana perumal <seesaravanan@yahoo.co.in> Subject: Re: TCP Free-BSD setup behaviour. Message-ID: <20090616141644.L82919@beagle.kn.op.dlr.de> In-Reply-To: <20090616113659.GA99604@owl.midgard.homeip.net> References: <925929.71164.qm@web8315.mail.in.yahoo.com> <20090616113659.GA99604@owl.midgard.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1964543108-1775022277-1245154636=:82919 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi=9A Louie. ET>> =9A ET>> As per Testing=20 ET>> =9A 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=9A to reach=9A SYN-RCVD state. ET> ET>That does not sound quite correct. The normal sequence for the TCP ET>three-way handshake is: ET> ET> -----> SYN ET> <----- SYN+ACK ET> -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET> -----> SYN ET> <----- SYN ET> -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> =9A ET>> In Free BSD active SYN-RCVD state is not happening . ET>> =9A ET>> In TCP state tranistion my expectation is represented for SYN_RCVD sta= te. ET>> =9A ET>> =9A ET>> Thanks. ET>> Saravanan ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, saravana perumal <seesaravanan@yahoo.co.in> wrote= : ET>>=20 ET>>=20 ET>> From: saravana perumal <seesaravanan@yahoo.co.in> ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" <louie@transsys.com> ET>> Cc: "FreeBSD Mailer List" <freebsd-net@freebsd.org> 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>> =9A ET>> =9AWe are trying to make Active Sync Received state. ET>> =9A 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>> =9A 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>> =9A ET>> I hope the expectation should be rite in case of ACTIVE-SYN received S= tate. ET>> =9A ET>> Thanks. ET>> Saravanan ET>> =9A ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, Louis Mamakos <louie@transsys.com> wrote: ET>>=20 ET>>=20 ET>> From: Louis Mamakos <louie@transsys.com> ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" <seesaravanan@yahoo.co.in> 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>> >=9A =9A =9A =9A FREE BSD=9A =9A =9A =9A =9A APPLICATION ET>> >=9A =9A =9A =9A =9A =9A =9A =9A=9A=9ASend ---------> syn ET>> >=9A =9A =9A =9A =9A =9A =9A =9A=9A=9AReceive <-------- SYN ET>> >=20 ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> >=20 ET>> >=9A 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.=9A Once the SYN has been ACK'd, = there's no reason to resend it.=9A I suppose I wonder why you expect the Fr= eeBSD system to retransmit it's SYN? ET>>=20 ET>> > 4=9A =9A .When checking the State - TIME-WAIT=9A =9A Sending FIN and= expecting the ACK ;Getting the ACK properly.=9A=9A=9ASending 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=9A in TIME-WAIT state , ET>> >=20 ET>> >=20 ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port=9A =9A =9A =9A =9A=9A=9A=3D 16815 (16815) ET>> > TCP: Destination Port=9A =9A =9A =3D 16816 (16816) ET>> > TCP: Sequence Number=9A =9A =9A=9A=9A=3D 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number =3D 0 (0x00000000) ET>> > TCP: Data Offset=9A =9A =9A =9A =9A=9A=9A=3D 5 (20 bytes) ET>> > TCP: Reserved=9A =9A =9A =9A =9A =9A =9A =3D 0 ET>> > TCP: Control Bits=9A =9A =9A =9A =9A =3D 0x10 ET>> > TCP:=9A |543210 ET>> > TCP:=9A |0.....=9A =9A =9A =9A =9A =9A =9A =3D Urgent Pointer Isn't = Significant ET>> > TCP:=9A |.1....=9A =9A =9A =9A =9A =9A =9A =3D Acknowledgment Is Sig= nificant ET>> > TCP:=9A |..0...=9A =9A =9A =9A =9A =9A =9A =3D No Push Function ET>> > TCP:=9A |...0..=9A =9A =9A =9A =9A =9A =9A =3D No Reset Connection ET>> > TCP:=9A |....0.=9A =9A =9A =9A =9A =9A =9A =3D No Synchronize Sequen= ce Numbers ET>> > TCP:=9A |.....0=9A =9A =9A =9A =9A =9A =9A =3D More Data From Sender ET>> > TCP: Window=9A =9A =9A =9A =9A =9A =9A =9A =3D 32752 bytes ET>> > TCP: Checksum=9A =9A =9A =9A =9A =9A =9A =3D 0x41A0 (Correct) ET>> > TCP: Urgent Pointer=9A =9A =9A =9A =3D 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:=9A 53 61 6D 70 6C 65 20 44 61 74 61 00=9A =9A =9A =9A =9A =9A = =9A=9A=9ASample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending=9A 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.= =9A Perhaps that the send sequence is outside the window.=9A 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> --1964543108-1775022277-1245154636=:82919--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090616141644.L82919>