exercise 1 question H

Followings are the individual description of the frames:

Frame 13:

Source: 64.233.161.99

Destination: 131.247.95.216

Protocol: TCP

information: TCP segment of a reassembled PDU

From the above information the packet send to the address 131.247.95.216 got the following descriptions:

Transmission control protocol, src port: http (80), dst port imyx (1143), seq:1652, ack:961, Len: 1430

Source port: http (80)

Destination port: imyx (1143)

Sequence number: 1652 (relative sequence number)

[Next sequence number: 3082 (relative sequence number)

Acknowledgment number : 961 (relative ack number)

header length: 20 bytes

Flag: 0x10 (ACK) which seems ok in this frame

Checksum: 0x736c which is define as correct by the analyzer.

SEQ/ACK analysis

This is an ACK to the segment in frame :12

.i.e. the RTT to ACK the segment was: 0.036996000 seconds

and the TCP Segment data is 1430 bytes.

This all data shows that the packet sends to the destination was segmented TCP which needed to reassembled using PDU (Protocol Data Unit).

Frame 14:

Source: 64.233.161.99

Destination: 131.247.95.216

Protocol: TCP

information: TCP segment of a reassembled PDU

From the above information the packet send to the address 131.247.95.216 got the following descriptions:

Transmission Control Protocol, src port: http (80) dst port: imyx (1143), seq: 3082, ack: 961, len: 1430

source port: http (80)

Destination port: imyx (1143)

sequence number: 3082 (relative sequence number)

next sequence number: 4512 (relative sequence number)

acknowledgement number: 961 (relative ack number)

header length: 20 bytes

flags: 0x10 (ACK) which ok in the frame 14 as well.

Checksum: 0xdfb5 [correct]

Reassembled PDU in frame: 22

TCP segment data 1430 bytes

The above information given by the analyzer shows that the segmented TCP is will be reassemble in frame 22.

Frame 15:

Source: 131.247.95.216

Destination: 64.233.161.99

Protocol: TCP

information: TCP Checksum incorrect

From the above information the packet send to the address 64.233.161.99 got the following descriptions:

Transmission Control Protocol, src port: imyx (1143), dst port: http (80), seq: 961, Ack:4512, len:0

source port: imyx (1143)

destination port: http (80)

sequence number: 961 (relative sequence number)

acknowledgment number: 4512 (relative ack number)

header length: 20 bytes

Flags: 0x10 (ACK)

Checksum: 0xc636 [incorrect, should be 0xbc2e (it may cause due to the offload of the TCP checksum on the frame)]

good checksum: False

Bad Checksum: True

SEQ/ACK Analysis

according to the analyzer this frame acknowledge the segment if frame 14. Due to this reason the frame got the checksum error.

The RTT to ACK the segment was:0.000060000 seconds.

Here in Frame 16,17 and 18 following things were happened:

The only difference in these frame is that they just replace the sequence number to each other. i.e. Sequence number of each frame is been changed to other frame number.

For example:

the sequence number if frame 16 is 4512 and the next sequence number is 5942. The sequence number 5942 is indicate the following sequence for the frame 16 while sequence 5942 is the primary sequence number in frame 17. Similarly in frame 17 the primary sequence number is 5942 and the following sequence number is 7372. The sequence number 7372 is the main sequence number for the frame 18. Same thing is happening in the frame 18. The primary sequence number of this frame is 7372 and the following sequence number is 8802, and the acknowledgment for all these frame 16, 17, and 18 is same as 961. source port for every frame 16, 17 and 18 are same to http (80) and similarly the destination port is also same to imyx (1143) to all port 16, 17 and 18.

The checksum of the different frame is different. The following are the checksum for the different frame

frame 16: checksum: 0x6948 which is correct for this frame.

Frame 17: checksum 0xabe7 which is also correct for this frame.

Frame 18: checksum 0xec55 this also shows the correct checksums for this frame.

Flags for all these frame 16, 17 and 18 is same to each others which is 0x10 (ACK)

following are the information of the Frame 16, Frame 17 and Frame 18.

Frame 16: SEQ/ACK analysis.

This frame shows ACK in frame 15 and the time for this segment is 0.0000.44000 seconds. The segmented ACK is will be reassembled PDU in the frame 22, where the TCP segmented data is 1430 bytes.

Frame 17: The segmented packet sent in this frame will be reassembled in the frame 22 by the help of PDU.

Frame 18: In this frame same thing will be applied as in the frame 17.

Here in Frame 19 and 21 shows the same kind of error. Following are the information provide by the frame 19 and frame 21.

What we found in the information of Frame 19 and frame 21 is almost same except the data shown in the Ack, in frame 19 the Ack is 7372 and in frame 21 Ack is 10232. This is the only different found on the information of the frame 19 and 21. Even the packet send by the same address and the destination is also same in for the both the frame 19 and the frame 21.

In frame 20 and 22 following are the information provided:

Transmission Control Protocol, src port: http (80), Dst port: imyx (1143), seq: 8802, Ack: 961, len:1430

next sequence number is 10232

Acknowledgment is similar to the frame 19 and 21 which is 961

header length: 20 bytes

Flags:0x10

checksum is correct in this frame

SEQ/ACK analysis

This is the ack segment which is occur in the frame 19 with the RTT to ACK the segment was: 0.000050000 seconds.

The segmented ack will be reassemble in the frame 22 with the TCP segment data 1430 bytes.

Similarly;

In Frame 22 we cam find the following data:

Transmission Control Protocol, src port: http (80), Dst port: imyx (1143), seq:10232, ack:961, len:184

next sequence number:10416

Acknowledgment number is same to the other frame like 19,20, and 21 which is 961

header height is 20 bytes

flags: 0x18 (PSH, ACK)

checksum: 0x9f21 which is correct for this frame.

The above information of the Frame 13 to 22 shows the different similarity between the frame and the information of those frames. It helps to compare the bad checksums with the correct checksums and the what are the error of the bad checksums.