为什么某些TCP数据包在TCPDUMP中没有序列编号？

发布于 2025-02-09 01:31:10 字数 3228 浏览 2 评论 0原文

我的主机（MACOS）上有一个redis服务器，它的端口为6378，首先我执行此命令：

sudo tcpdump -vvvn -i lo0 port 6378

在另一个选项卡中执行

redis-cli -h 127.0.0.1 -p 6378

此命令，这是redis-cli连接到redis-server之后的TCPDUMP的结果

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

然后有一个序列号

和在这里有一个32位的“序列号”，因此，我应该在TCPDUMP中添加一些ARG，以便显示具有flags [。]的线路数？

原文

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 [.]?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

羁客 2025-02-16 01:31:10

根据“ nofollow noreferrer”> tramplast_control_control_protocol wikipedia on wikipedia：

序列号（32位）
具有双重角色：
如果设置了SYN标志（1），则这是初始序列号。实际的第一个数据字节的序列编号和相应的ACK中的已确认数字为此序列编号加1。
如果SYN标志是清晰的（0），则这是当前会话的第一个段字节的累积序列编号。

和根据史蒂文斯的 tcp ip所示，第1卷：

每个TCP段（在连接建立期间交换的TCP段）
包括有效的序列号字段， ack号或确认字段和a 窗口大小字段（包含窗口广告）。

现在，让我们构建一个方案并使用tcpdump跟踪TCP段：

初始化http（IE TCP）请求，curl：

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

同时，执行tcpdump并将转储日期写入文件如下：

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

使用以下命令读取转储数据：

$ 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

第11-13行中的数据包都是ACK段，而无需palyload。 tcpdump还没有显示seq应该为1574650508作为带有有效负载的最后一个发送段（即来自服务器的有效负载）行号6）。

为什么？

现在，让我们运行tcpdump带有以下选项：

$ 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
.....

实际上，使用xx选项，我们可以分析32位序列号（IE 5DDDB 428C）上述TCP段（11-13），然后将其转换为小数号如下：

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

在这里，我们可以看到ACK段中重复三次重复的序列编号为1574650508与Wireshark相同（使用绝对序列编号选项）。

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:

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

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

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

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

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).