On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote:
> Hi Louie.
>
> As per Testing
>
> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open]
> 2. Then Expects to RECEIVE SYN packet and
> 3. To Send SYN & ACK to reach SYN-RCVD state.
That does not sound quite correct. The normal sequence for the TCP
three-way handshake is:
-----> SYN
<----- SYN+ACK
-----> ACK
while you for some reason seem to be expecting
-----> SYN
<----- SYN
-----> SYN+ACK
which is not what I would expect.
>
> In Free BSD active SYN-RCVD state is not happening .
>
> In TCP state tranistion my expectation is represented for SYN_RCVD state.
>
>
> Thanks.
> Saravanan
>
>
> --- On Tue, 6/16/09, saravana perumal <seesarava...@yahoo.co.in> wrote:
>
>
> From: saravana perumal <seesarava...@yahoo.co.in>
> Subject: Re: TCP Free-BSD setup behaviour.
> To: "Louis Mamakos" <lo...@transsys.com>
> Cc: "FreeBSD Mailer List" <freebsd-net@freebsd.org>
> Date: Tuesday, June 16, 2009, 3:15 PM
>
>
>
>
>
>
>
> Hi Louie
>
> We are trying to make Active Sync Received state.
>
> As per our testing we are trying to received Syn packet from APPLICATION end
> and to send syn & ACK from Device END and hence reaching the ACTIVE
> SYN-RECEIVED state.
>
> 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
>
> I hope the expectation should be rite in case of ACTIVE-SYN received State.
>
> Thanks.
> Saravanan
>
>
>
> --- On Tue, 6/16/09, Louis Mamakos <lo...@transsys.com> wrote:
>
>
> From: Louis Mamakos <lo...@transsys.com>
> Subject: Re: TCP Free-BSD setup behaviour.
> To: "saravana perumal" <seesarava...@yahoo.co.in>
> Cc: freebsd-net@freebsd.org, sarba...@gmail.com
> Date: Tuesday, June 16, 2009, 3:05 AM
>
>
>
> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote:
>
> > Hi Louie ,
> >
> >
> > Thanks for the Response on my Queries.
> >
> > For QUERY 3,
> > ACTIVE open frm Free BSD end:
> >
> > FREE BSD APPLICATION
> > Send ---------> syn
> > Receive <-------- SYN
> >
> > Expect SYN & ACK-------------> Getting only ACK in this Scenario,
> >
> > Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is
> >sending only ACK message as the response.
>
> There's no reason why the FreeBSD host would send another SYN; presumably the
> "APPLICATION" host received the SYN and responds back with SYN of it's own
> and ACK of the FreeBSD host's SYN. Once the SYN has been ACK'd, there's no
> reason to resend it. I suppose I wonder why you expect the FreeBSD system to
> retransmit it's SYN?
>
> > 4 .When checking the State - TIME-WAIT Sending FIN and expecting the
> > ACK ;Getting the ACK properly. Sending Data Segment and Expecting the RST
> > signal not getting the RST ; Instead DUT is sending the Last TCP packet.
> > Issue seen only in Free BSD
> >
> >
> > For this Issue mentioned above, Last TCP packet is jst a Testing packet
> > with the
> > following Field set in TIME-WAIT state ,
> >
> >
> > TCP: ---- TCP Packet ----
> > TCP:
> > TCP: Source Port = 16815 (16815)
> > TCP: Destination Port = 16816 (16816)
> > TCP: Sequence Number = 3865716731 (0xE66A27FB)
> > TCP: Acknowledgment Number = 0 (0x00000000)
> > TCP: Data Offset = 5 (20 bytes)
> > TCP: Reserved = 0
> > TCP: Control Bits = 0x10
> > TCP: |543210
> > TCP: |0..... = Urgent Pointer Isn't Significant
> > TCP: |.1.... = Acknowledgment Is Significant
> > TCP: |..0... = No Push Function
> > TCP: |...0.. = No Reset Connection
> > TCP: |....0. = No Synchronize Sequence Numbers
> > TCP: |.....0 = More Data From Sender
> > TCP: Window = 32752 bytes
> > TCP: Checksum = 0x41A0 (Correct)
> > TCP: Urgent Pointer = 0 (Not Significant)
> > TCP:
> > TCP: --- Trailing Data [12 bytes] ---
> > TCP: 53 61 6D 70 6C 65 20 44 61 74 61 00 Sample Data.
> > TCP: --- Trailing Data End ---
> > From machine Sending to the FREE BSD machine,
> >
> > This is to verify that Free BSD is in TIME-WAIT state.
>
> 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.
> Perhaps that the send sequence is outside the window. 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?
>
> louie
>
>
>
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1...@student.uu.se
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
