Ask Your Question
0

tcp.nxtseq not incremented on zero len SYN/FIN packets

asked 2019-07-19 15:40:38 +0000

Chuckc gravatar image

From 3.0.2 source:

   1 /* packet-tcp.c
   2  * Routines for TCP packet disassembly

5961 static int
5962 dissect_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void* data _U_)
5963 {

6213             /* Compute the sequence number of next octet after this segment. */
6214             nxtseq = tcph->th_seq + tcph->th_seglen;
6215             if ((tcph->th_flags&(TH_SYN|TH_FIN)) && (tcph->th_seglen > 0)) {
6216                 nxtseq += 1;

Why is this check "&& (tcph->th_seglen > 0)" in the code?

Example FTP connection: Packets 1 and 2 show next sequence numbers are 0. (TCP Len = 0 so check above kicks in) Packets 3 and 4 come back with sequence numbers of 1 (0 + ghost byte in packets 1 and 2) FIN/ACK from server in packet 36 has nxtseq of 574 but it's next packet (41) has sequence of 575. FIN/ACK from client in packet 40 has nxteq of 97 but the server ACKs back 98 in packet 41.

No.     Time           Source                Destination           TTL        SEQ#       TCP Len    NEXTSEQ#   ACK#       TCP Flags  Info
      1 0.000000       Client                Server                128        0          0          0          0          ··········S· 60446 → 21 [SYN] Seq=0 Win=17520 Len=0 MSS=1460 WS=256 SACK_PERM=1
      2 0.028188       Server                Client                54         0          0          0          1          ·······A··S· 21 → 60446 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1
      3 0.028327       Client                Server                128        1          0          1          1          ·······A···· 60446 → 21 [ACK] Seq=1 Ack=1 Win=17408 Len=0
      4 0.061681       Server                Client                54         1          84         85         1          ·······AP··· Response: 220 This is 

     35 0.448758       Client                Server                128        91         6          97         560        ·······AP··· Request: QUIT
     36 0.488215       Server                Client                54         574        0          574        97         ·······A···F [TCP Previous segment not captured] 21 → 60446 [FIN, ACK] Seq=574 Ack=97 Win=65664 Len=0
     37 0.488216       Server                Client                54         560        14         574        97         ·······AP··· [TCP Out-Of-Order] 21 → 60446 [PSH, ACK] Seq=560 Ack=97 Win=65664 Len=14
     38 0.488285       Client                Server                128        97         0          97         560        ·······A···· [TCP Dup ACK 34#1] 60446 → 21 [ACK] Seq=97 Ack=560 Win=16896 Len=0
     39 0.488473       Client                Server                128        97         0          97         575        ·······A···· 60446 → 21 [ACK] Seq=97 Ack=575 Win=16896 Len=0
     40 0.488690       Client                Server                128        97         0          97         575        ·······A···F 60446 → 21 [FIN, ACK] Seq=97 Ack=575 Win=16896 Len=0
     41 0.528202       Server                Client                54         575        0          575        98         ·······A···· 21 → 60446 [ACK] Seq=575 Ack=98 Win=33024 Len=0
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2019-08-15 13:24:31 +0000

Chuckc gravatar image

updated 2019-08-15 14:04:53 +0000

grahamb gravatar image

Bug 15964 and Change 34273.

Comment 1 Gerrit Code Review 2019-08-13 19:39:33 UTC
Change 34273 had a related patch set uploaded by Uli Heilmeier:
TCP: increment nextseq for FIN and SYN packets

https://code.wireshark.org/review/34273

Comment 2 Uli Heilmeier 2019-08-13 19:40:19 UTC
Good catch. Don't see any reason for this check.
Pushed a fix to review.
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-07-19 15:40:38 +0000

Seen: 474 times

Last updated: Aug 15 '19