FIN Phantom byte

Question

218, 82.5999, 10.24.233.34 - 10.24.238.2 ,102, smtp → 54361, [FIN, ACK] Seq=450 Ack=1169,Len=0
219, 82.6001, 10.24.238.2 - 10.24.233.34, 102,54361 → smtp ,[FIN, ACK] Seq=1169 Ack=450, Len=0
220, 82.6003, 10.24.238.2 - 10.24.233.34, 102, 54361 → smtp [ACK] Seq=1170 Ack=451, Len=0
221, 82.6003, 10.24.233.34 -10.24.238.2,  102,  smtp → 54361 [ACK] Seq=451 Ack=1170, Len=0

Hi,In above session termination process why in packet 220 sequence no increased by 1 and in second fin ack packet ack is not increased by 1.as per my understanding during session termination process only ack byte(phantom) increases by one.

Accepted Answer

1

In packet 219, 10.24.238.2 sends a FIN flag with Sequence No. 1169, so the next packet needs to use Sequence No. 1170, which it does in packet 220.

The other node sends its FIN in packet 218 with Sequence No. 450, and thus has to use sequence no. 451 in its next packet. Which is packet 221, and it does.

Looks all good to me, but maybe I haven't understood the question :-)

answered 05 Jun '14, 02:29

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

Thanks jasper,why did it increase 1 byte(1170) in seq in packet 220 as the last ack received(218) was 1169.As per my understanding During FIN exchange only ack increases by 1 byte and not seq field.

(05 Jun '14, 02:47) kishan pandey

ACK and sequence both increase - the receiver has to notify that it got the FIN flag (so +1 on the ACK), and the sender has to continue at the sequence after the FIN, so +1 on the sequence.

(05 Jun '14, 02:51) Jasper ♦♦

215, 82.5999, 10.24.233.34 - 10.24.238.2 ,102, smtp → 54365, [FIN, ACK] Seq=450 Ack=434,Len=0

216, 82.6001, 10.24.238.2 - 10.24.233.34, 102,54365 → smtp ,[FIN, ACK] Seq=434 Ack=451, Len=0

227, 82.6003, 10.24.238.2 - 10.24.233.34, 102, 54365 → smtp [ACK] Seq=451 Ack=435, Len=0

Thanks for explanation jasper,Curiosity is growing now,One more FIN termination in same capture and now the pattern is different.Now if we see only ack has increased(packet 216) and seq numbers are same as lask ack.

(05 Jun '14, 04:31) kishan pandey

1

in 215 10.24.233.34 sends a FIN with seq 450, so in 216 that packet is ACKed by 450+1. Which is correct. The seq in 216 is 434, same as the last ack in 215, which means there was no outstanding data to be acknowledged. Everything okay there, too.

Are you sure you got packet 227 right? It looks like you turned the IPs and ports around for that quote... it should be the ACK for 216 but source and destination is in the wrong order. I guess you copied it incorrectly.

(05 Jun '14, 04:43) Jasper ♦♦

yes not copied properly,an packet analyst knows everything.I Understand it now properly.

(05 Jun '14, 05:36) kishan pandey

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(05 Jun '14, 05:51) grahamb ♦

showing 5 of 6 show 1 more comments