TCP Free-BSD setup behaviour.

[saravana perumal]

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.

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.
 
 
Thanks,
Saravanan


--- On Sat, 6/13/09, Louis Mamakos <louie at transsys.com> wrote:


From: Louis Mamakos <louie at transsys.com>
Subject: Re: TCP Free-BSD setup behaviour.
To: "saravana perumal" <seesaravanan at yahoo.co.in>
Cc: freebsd-net at freebsd.org, sarbalas at gmail.com
Date: Saturday, June 13, 2009, 10:54 PM



On Jun 10, 2009, at 9:47 AM, saravana perumal wrote:

>  Hi ,
> 
>   Have some behaviour change  with FREEBSD  compared to  LINUX .

You probably ought to verify the behavior against the protocol specifications, and not what some other TCP implementation happens to to.
> 
> 1. When sending the Same  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 one [ increases sequentially IP Identification]

The IPID header field is used for reassembly of IP fragments, and is not of consequence to TCP.  If the protocol stack absolutely knows that a TCP retransmission is identical to the previous segment, then in theory, it could use the same IPID fields to increase the chance that a previously fragmented TCP segment with a lost segment could get reassembled with fragments from the retransmission.  Since there's much work done to avoid fragmentation in the first place (e.g., using Path MTU discovery), this "feature" probably never gets used.

This behavior makes more sense if the TCP implementation keeps around a retransmit queue of previously sent packets, rather than simply generating new TCP segments with whatever data happens to be in the TCP send window at the time of the retransmission attempt.

> 
> 2.Retranmission Time is not increasing Linearly with Respect to BSD. not keeping more time interval . AS per RFC
> expecting Retransmission timeout should  increase Linearly. Issue is not seen with Linux Setup

Retransmission time is highly dependent on many factors, like the implementation of TCP slow-start, what the TCP stack has estimated as the round-trip time, etc.  In the general case, over the span of many retransmissions, the sending TCP stack should back-off the retransmit times.

> 
> 3. Active SYN open state in FREE BSD setup , Does not reach Syn-received State. When Sending syn packet to DUT but  for that FreeBSD is not sending back
> SYN/ACK .  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 from the remote system.  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, and perhaps any data that might have been piggybacked in the ACK segment.  There's no need to retransmit the SYN.

Or is the remote system doing the active open to the FreeBSD system?  It's hard to believe that the FreeBSD TCP can't respond to an incoming TCP segment to a listening socket carrying a SYN segment?

> 
> 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.

I may be misunderstanding.  When in TIME-WAIT state, the local TCP is waiting for a bit in case the "final" ACK of the remote TCP's FIN got lost, and the remote retransmits the FIN (and perhaps any data that might have been in the window along with the FIN).  The local TCP shouldn't generate a RST assuming that the remote's retransmitted TCP segment is still within the window.  I'm not sure what's in the "Last TCP packet."

> 
> Same issue in FIN-WAIT2  & FIN-WAIT1 State also .
>   Sending FIN and Expect the ACK : Getting the ACK
>   Sending Data segment with Data : Expecting the RST signal from DUT ; but got Last transmitted TCP packet[ FIN -ACK]
> 

Ditto.

> Any idea about the above scenario would be helpful
> 
> 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 many others implementations in other platforms.  I'm not sure looking for variances between some random Linux TCP stack is really the right way to approach testing.

louie