This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Doubt in TCP RFC(seg.seq+seg.len-1=last seq no of segment)

0

Below is the trace of client side communication(all the way from first packet to last) from which i am looking to understand a statement in RFC793.

In pg.28 :seg.seq(first seq number of a segment)+seg.len(the no.of octets occupied by data)-1=last seq no of segment

Here my first sequence number is 0 and total amount of data that traversed is 723 bytes but if we apply this formula the last no should be [0+723-1]=722 which is obviously wrong.Please let me clarify if i am missing any thing here.

Trace:

35   5.680942 192.168.0.101 -> 199.232.41.10 TCP 62  nhci > http [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
42   5.721403 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [ACK] Seq=1 Ack=1 Win=64240 Len=0
43   5.745246 192.168.0.101 -> 199.232.41.10 HTTP 393  GET /gnu.css HTTP/1.1
48   5.791402 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [ACK] Seq=340 Ack=1604 Win=64240 Len=0
49   5.806331 192.168.0.101 -> 199.232.41.10 HTTP 438  GET /graphics/gnu-head-sm.jpg HTTP/1.1
53   5.851962 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [ACK] Seq=724 Ack=4524 Win=64240 Len=0
57   5.895093 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [ACK] Seq=724 Ack=7226 Win=64240 Len=0
72  22.646439 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [ACK] Seq=724 Ack=7227 Win=64240 Len=0
73  31.086352 192.168.0.101 -> 199.232.41.10 TCP 54  nhci > http [FIN, ACK] Seq=724 Ack=7227 Win=64240 Len=0

asked 23 Jun '13, 22:21

krishnayeddula's gravatar image

krishnayeddula
629354148
accept rate: 6%

edited 24 Jun '13, 01:46

grahamb's gravatar image

grahamb ♦
19.8k330206


2 Answers:

3

seg.seq(first seq number of a segment)+seg.len(the no.of octets occupied by data)-1=last seq no of segment

These sequence numbers refer to the sequence numbers in one segment, not to the sequence numbers in the whole TCP stream.

So in your case:

  • Frame 35: SYN packet, no length, do add 1 for the phantom byte
  • Frame 42; ACK packet, no length, start seq = 1 (because of the phantom byte after the SYN)
  • Frame 43: GET request, seq nr of first byte in segment is 1, length is 723, so seq nr of last byte in segment is 1+339-1=339, next seq nr should be 339+1 = 340
  • Frame 48: ACK packet, no length
  • Frame 43: GET request, seq nr of first byte in segment is 340, length is 384, so seq nr of last byte in segment is 340+384-1=723, next seq nr should be 723+1 = 724

I guess you did not take into account the phantom byte after the SYN packet. See page 16 of rfc 723:

The sequence number of the first data octet in this segment (except
when SYN is present). If SYN is present the sequence number is the
initial sequence number (ISN) and the first data octet is ISN+1.

answered 24 Jun '13, 00:00

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

edited 24 Jun '13, 02:21

3

The solution is pretty simple: The SYN like the FIN Bits count as one Byte sent, which is why there's an ACK for those packets as well. So if you sent 723 Bytes you've sent those with Seq.Nr. 1 instead of 0 because those were sent after the SYN.

answered 23 Jun '13, 23:45

Landi's gravatar image

Landi
2.3k51442
accept rate: 28%