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
_______________________________________________
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"
