vishgupta92 / ostinato

Automatically exported from code.google.com/p/ostinato
GNU General Public License v3.0
0 stars 0 forks source link

TCP Sequent Numbers are incorrect #105

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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