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"
