why some tcp packets doesn't have sequence number in tcpdump?

Question

I have a redis server on my host(macOS), it's port is 6378, first I execute this command:

sudo tcpdump -vvvn -i lo0 port 6378

Then execute this in another tab

redis-cli -h 127.0.0.1 -p 6378

And here is the results from tcpdump after redis-cli connected to redis-server

21:29:05.866610 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
    127.0.0.1.64020 > 127.0.0.1.6378: Flags [S], cksum 0xfe34 (incorrect -> 0xf8d2), seq 1870296365, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 3029686726 ecr 0,sackOK,eol], length 0
21:29:05.866682 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
    127.0.0.1.6378 > 127.0.0.1.64020: Flags [S.], cksum 0xfe34 (incorrect -> 0x4dad), seq 3099403233, ack 1870296366, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 962237723 ecr 3029686726,sackOK,eol], length 0
21:29:05.866693 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.64020 > 127.0.0.1.6378: Flags [.], cksum 0xfe28 (incorrect -> 0xaeb6), seq 1, ack 1, win 6379, options [nop,nop,TS val 3029686726 ecr 962237723], length 0
21:29:05.866701 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.6378 > 127.0.0.1.64020: Flags [.], cksum 0xfe28 (incorrect -> 0xaeb6), seq 1, ack 1, win 6379, options [nop,nop,TS val 962237723 ecr 3029686726], length 0
21:29:05.866949 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 69, bad cksum 0 (->3cb1)!)
    127.0.0.1.64020 > 127.0.0.1.6378: Flags [P.], cksum 0xfe39 (incorrect -> 0x2629), seq 1:18, ack 1, win 6379, options [nop,nop,TS val 3029686726 ecr 962237723], length 17
21:29:05.866967 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.6378 > 127.0.0.1.64020: Flags [.], cksum 0xfe28 (incorrect -> 0xaea5), seq 1, ack 18, win 6379, options [nop,nop,TS val 962237723 ecr 3029686726], length 0
21:29:05.907727 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 86, bad cksum 0 (->3ca0)!)
    127.0.0.1.6378 > 127.0.0.1.64020: Flags [P.], cksum 0xfe4a (incorrect -> 0xde76), seq 1:35, ack 18, win 6379, options [nop,nop,TS val 962237762 ecr 3029686726], length 34
21:29:05.907757 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.64020 > 127.0.0.1.6378: Flags [.], cksum 0xfe28 (incorrect -> 0xae35), seq 18, ack 35, win 6379, options [nop,nop,TS val 3029686765 ecr 962237762], length 0

But in wireshark, it has a sequence number

And from here we can know that every packet of TCP must have a 32bit "Sequence Number", so, should I add some args to tcpdump so it can show the seq number of lines that has Flags [.]?

Answer 1

According to the Transmission_Control_Protocol on Wikipedia:

Sequence number (32 bits)

Has a dual role:

If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.

If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.

And according to the Stevens's TCP IP Illustrated, Volume 1:

Every TCP segment (except those exchanged during connection establishment) includes a valid Sequence Number field, an ACK Number or Acknowledgment field, and a Window Size field (containing the window advertisement).

Now let's construct a scenario and use tcpdump to trace the tcp segments:

1. Initialize a HTTP (i.e. TCP) request with curl:

$ curl -iIL https://blog.codefarm.me/
HTTP/2 200 
server: GitHub.com
.....

2. Meanwhile, executing tcpdump and write the dump date to a file as below:

tcpdump -n port 443 -r /tmp/https.pcap

3. Reading the dump data with the following command:

$ tcpdump --number -ntS port 443 -r /tmp/https.pcap
reading from file /tmp/https.pcap, link-type EN10MB (Ethernet), snapshot length 262144
    1  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [S], seq 2427498844, win 64240, options [mss 1460,sackOK,TS val 2733586448 ecr 0,nop,wscale 7], length 0
    2  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [S.], seq 1574645920, ack 2427498845, win 64240, options [mss 1460], length 0
    3  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574645921, win 64240, length 0
    4  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427498845:2427499362, ack 1574645921, win 64240, length 517
    5  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499362, win 64240, length 0
    6  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574645921:1574650508, ack 2427499362, win 64240, length 4587
    7  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574650508, win 61320, length 0
    8  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499362:2427499442, ack 1574650508, win 62780, length 80
    9  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499442:2427499488, ack 1574650508, win 62780, length 46
   10  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499488:2427499537, ack 1574650508, win 62780, length 49
   11  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499442, win 64240, length 0
   12  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499488, win 64240, length 0
   13  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499537, win 64240, length 0
   14  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499537:2427499640, ack 1574650508, win 62780, length 103
   15  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499640, win 64240, length 0
   16  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574650508:1574651050, ack 2427499640, win 64240, length 542
   17  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574651050:1574651109, ack 2427499640, win 64240, length 59
   18  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574651109, win 62780, length 0
   19  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499640:2427499671, ack 1574651109, win 62780, length 31
   20  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499671, win 64240, length 0
   21  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574651109:1574651502, ack 2427499671, win 64240, length 393
   22  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499671:2427499695, ack 1574651502, win 62780, length 24
   23  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499695, win 64240, length 0
   24  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [F.], seq 2427499695, ack 1574651502, win 62780, length 0
   25  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499696, win 64239, length 0
   26  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [FP.], seq 1574651502:1574651526, ack 2427499696, win 64239, length 24
   27  IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [R], seq 2427499696, win 0, length 0

The packets at the line 11-13 are all ACK segments without palyload. And tcpdump also doesn't show the seq field which is should be 1574650508 as the last sending segment with payload from server (i.e. packet 6 at line number 6).

Why?

Now let's run tcpdump with the following options:

$ tcpdump --number -ntSxx port 443 -r /tmp/https.pcap
.....
    6  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574645921:1574650508, ack 2427499362, win 64240, length 4587
.....
   11  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499442, win 64240, length 0
    0x0000:  000c 298c df3f 0050 56e9 f627 0800 4500
    0x0010:  0028 5a0e 0000 8006 9e38 b9c7 6c99 c0a8
    0x0020:  5b80 01bb 8064 5ddb 428c 90b0 b3b2 5010
    0x0030:  faf0 0b70 0000 0000 0000 0000
   12  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499488, win 64240, length 0
    0x0000:  000c 298c df3f 0050 56e9 f627 0800 4500
    0x0010:  0028 5a0f 0000 8006 9e37 b9c7 6c99 c0a8
    0x0020:  5b80 01bb 8064 5ddb 428c 90b0 b3e0 5010
    0x0030:  faf0 0b42 0000 0000 0000 0000
   13  IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499537, win 64240, length 0
    0x0000:  000c 298c df3f 0050 56e9 f627 0800 4500
    0x0010:  0028 5a10 0000 8006 9e36 b9c7 6c99 c0a8
    0x0020:  5b80 01bb 8064 5ddb 428c 90b0 b411 5010
    0x0030:  faf0 0b11 0000 0000 0000 0000
.....    

Actually, with the xx option, we can analyze the 32bit sequence number (i.e. 5ddb 428c) of the above TCP segments (11-13) and convert it to decimal number as below:

$ echo $((16#5ddb428c))
1574650508

Here, we can see the sequence number that repeated in ACK segment three times is 1574650508 which is same as the WireShark (with absolute sequence number option).