TCP Sequent Numbers are incorrect

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a TCP SYN and ACK packets with specific Seq# and ACK#
2. Send the SYN and ACK packets (with or without waiting for the SYN+ACK packet 
to arrive)
3. Capture the outgoing packets and Check the seq# and ack#

What is the expected output? What do you see instead? == Expected to see the 
seq# and ack# values that I had entered manually, however they were quite 
different (for ex, I expected seq#=2 in SYN, but I saw 0 or 495849504 or 
something else).

What version and revision of the product are you using (available in the
About dialog)? == 0.5.1

On what operating system? == OSX 10.8.2.

Please provide any additional information below.
Would appreciate a quick fix.

Original issue reported on code.google.com by rajiv.as...@gmail.com on 9 Jul 2013 at 5:22

Attachments:

• [TCP handshake spoofed Sequence-no capture.pcap](https://storage.googleapis.com/google-code-attachments/ostinato/issue-105/comment-0/TCP handshake spoofed Sequence-no capture.pcap)

[GoogleCodeExporter]

If you are checking the sequence numbers using Wireshark, make sure you are 
checking "absolute" sequence numbers not "relative" sequence numbers. For the 
attached pcap file, what were the seq/ack numbers you specified in the ostinato 
stream. It would be useful to attach the stream file here as well that was used 
when the pcap capture was done.

Also note that both sides of the TCP connection can start off their sequence 
numbers independently with any random value. This means that the ACK (of the 
SYN, SYN-ACK, ACK handshake) needs to have a ACK number based on the Seq num in 
the received SYN-ACK.

Original comment by pstav...@gmail.com on 10 Jul 2013 at 3:57

• Changed state: Reviewed

[GoogleCodeExporter]

Of course.

I don't have the complete stream file, but here is the TCP parts of two packets 
/ files  -

core {
   name: "SYN"
//
   [OstProto.tcp] {
     is_override_src_port: true
     is_override_dst_port: true
     is_override_hdrlen: true
     is_override_cksum: true
     src_port: 59925
     dst_port: 80
     seq_num: 2
     ack_num: 0
     hdrlen_rsvd: 80
     flags: 2
     window: 65535
     cksum: 56705
     urg_ptr: 0
   }

########
stream {
 stream_id {
   id: 1
 }
 core {
   name: "ACK"
//
   [OstProto.tcp] {
     is_override_src_port: true
     is_override_dst_port: true
     is_override_hdrlen: false
     is_override_cksum: true
     src_port: 59925
     dst_port: 80
     seq_num: 1
     ack_num: 100
     hdrlen_rsvd: 80
     flags: 16
     window: 65535
     cksum: 56592
     urg_ptr: 0
   }
 }
}

Of course. But that should be orthogonal to the seq/ack numbers chosen by 
ostinato, since I am manually generating them. 

Original comment by rajiv.as...@gmail.com on 10 Jul 2013 at 8:25

[GoogleCodeExporter]

TCP Seq/Ack numbers in the PCAP file are same as what is in the stream - turn 
off relative seq numbers in wireshark to verify.

Note that SYN has an absolute Seq No. of 2 while the SYN ACK has an absolute 
Seq No. of 1 (instead of 3) - wireshark translates this to relative seq no. 0 
and 4294967295 (0xFFFFFFFF)

Original comment by pstav...@gmail.com on 12 Jul 2013 at 3:59