TCP Free-BSD setup behaviour.

Harti Brandt hartmut.brandt at dlr.de
Tue Jun 16 12:16:28 UTC 2009


On Tue, 16 Jun 2009, Erik Trulsson wrote:

ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote:
ET>> Hi  Louie.
ET>>  
ET>> As per Testing 
ET>>  
ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open]
ET>> 2. Then Expects to RECEIVE SYN packet and 
ET>> 3. To Send SYN & ACK  to reach  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>>  
ET>> In Free BSD active SYN-RCVD state is not happening .
ET>>  
ET>> In TCP state tranistion my expectation is represented for SYN_RCVD state.
ET>>  
ET>>  
ET>> Thanks.
ET>> Saravanan
ET>> 
ET>> 
ET>> --- On Tue, 6/16/09, saravana perumal <seesaravanan at yahoo.co.in> wrote:
ET>> 
ET>> 
ET>> From: saravana perumal <seesaravanan at yahoo.co.in>
ET>> Subject: Re: TCP Free-BSD setup behaviour.
ET>> To: "Louis Mamakos" <louie at transsys.com>
ET>> Cc: "FreeBSD Mailer List" <freebsd-net at freebsd.org>
ET>> Date: Tuesday, June 16, 2009, 3:15 PM
ET>> 
ET>> 
ET>> 
ET>> 
ET>> 
ET>> 
ET>> 
ET>> Hi Louie
ET>>  
ET>>  We are trying to make Active Sync Received state.
ET>>  
ET>> 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.
ET>>  
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>>  
ET>> I hope the expectation should be rite in case of ACTIVE-SYN received State.
ET>>  
ET>> Thanks.
ET>> Saravanan
ET>>  
ET>> 
ET>> 
ET>> --- On Tue, 6/16/09, Louis Mamakos <louie at transsys.com> wrote:
ET>> 
ET>> 
ET>> From: Louis Mamakos <louie at transsys.com>
ET>> Subject: Re: TCP Free-BSD setup behaviour.
ET>> To: "saravana perumal" <seesaravanan at yahoo.co.in>
ET>> Cc: freebsd-net at freebsd.org, sarbalas at gmail.com
ET>> Date: Tuesday, June 16, 2009, 3:05 AM
ET>> 
ET>> 
ET>> 
ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote:
ET>> 
ET>> > Hi Louie ,
ET>> > 
ET>> > 
ET>> > Thanks for the Response on my Queries.
ET>> > 
ET>> > For QUERY 3,
ET>> > ACTIVE open frm Free BSD end:
ET>> > 
ET>> >        FREE BSD          APPLICATION
ET>> >                 Send ---------> syn
ET>> >                 Receive <-------- SYN
ET>> > 
ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario,
ET>> > 
ET>> >  Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response.
ET>> 
ET>> 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?
ET>> 
ET>> > 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
ET>> > 
ET>> > 
ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the
ET>> > following Field set  in TIME-WAIT state ,
ET>> > 
ET>> > 
ET>> > TCP: ---- TCP Packet ----
ET>> > TCP:
ET>> > TCP: Source Port           = 16815 (16815)
ET>> > TCP: Destination Port      = 16816 (16816)
ET>> > TCP: Sequence Number       = 3865716731 (0xE66A27FB)
ET>> > TCP: Acknowledgment Number = 0 (0x00000000)
ET>> > TCP: Data Offset           = 5 (20 bytes)
ET>> > TCP: Reserved              = 0
ET>> > TCP: Control Bits          = 0x10
ET>> > TCP:  |543210
ET>> > TCP:  |0.....              = Urgent Pointer Isn't Significant
ET>> > TCP:  |.1....              = Acknowledgment Is Significant
ET>> > TCP:  |..0...              = No Push Function
ET>> > TCP:  |...0..              = No Reset Connection
ET>> > TCP:  |....0.              = No Synchronize Sequence Numbers
ET>> > TCP:  |.....0              = More Data From Sender
ET>> > TCP: Window                = 32752 bytes
ET>> > TCP: Checksum              = 0x41A0 (Correct)
ET>> > TCP: Urgent Pointer        = 0 (Not Significant)
ET>> > TCP:
ET>> > TCP: --- Trailing Data [12 bytes] ---
ET>> > TCP:  53 61 6D 70 6C 65 20 44 61 74 61 00               Sample Data.
ET>> > TCP: --- Trailing Data End ---
ET>> > From machine Sending  to the FREE BSD machine,
ET>> > 
ET>> > This is to verify that Free BSD is in TIME-WAIT state.
ET>> 
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.  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?
ET>> 
ET>> louie
ET>> 
ET>> 
ET>> 
ET>> 
ET>> 
ET>> _______________________________________________
ET>> freebsd-net at freebsd.org mailing list
ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
ET>
ET>


More information about the freebsd-net mailing list