SSL/TLS packet capture prompts ignored unknown record
There are two cases of this prompt. First, packet capture is late, part of the SSL/TLS negotiation data is not obtained, and Wireshark cannot recognize and parse it. Second, the packet uses a special protocol type, Wireshark can not correct, waiting for later Wireshark improvement.
Today, we use the windows search function to search the contents of a shared folder on the network. We find that the traffic is huge when we search the network files. Curious to use Wireshark to capture packets, I found that there are many prompt messages of “TCP segment of a reassembled PDU” in Wireshark info column. Don’t understand Baidu for a while, found that everyone is asking this question, online and no good answer. Thinking that “TCP segment of a reassembled PDU” is just a Wireshark prompt, what kind of prompt will be given in Sniffer Pro?Open the same trace with sniffer and find that it prompts “continuation of missing frame” and “continuation of frame XX”. Now you probably know “TCP segment of a reassembled PDU” What does “PDU” mean?In fact, when the host responds to a query or command, if it needs to respond to a lot of data (information) and the data exceeds the maximum MSS of TCP, the host will send multiple packets to transmit the data (Note: these packets are not fragmented). For Wireshark, these packets corresponding to the same query command are marked with “TCP segment of a reassembled PDU”
How does Wireshark identify that multiple packets are responses to the same query packet?Wireshark identifies these packets according to the sequence number. The ACK number of these packets is the same. Of course, the number value is the same as the next sequence number in the query packet.
[background knowledge] MTU: maximum transmission unit
MSS: maximum segment size
PPPoE: PPP over Ethernet
[analysis process] let’s talk about the maximum transmission unit of MTU first. This maximum transmission unit is actually closely related to the link layer protocol. Let’s carefully recall the structure of Ethernet II frame DMAC + SMAC + type + data + CRC. Due to the electrical limitation of Ethernet transmission, each Ethernet frame has a minimum size of 64bytes, which can’t be exceeded 1518 bytes. For Ethernet frames less than or greater than this limit, we can regard them as wrong data frames. General Ethernet forwarding devices will discard these data frames. (Note: data frames smaller than 64bytes are generally caused by “fragmentation” caused by Ethernet conflict, line interference or bad Ethernet interface. For data frames larger than 1518bytes, we generally call them giant frames, which are generally caused by line interference or bad Ethernet interface.)
Since the largest data frame of Ethernet II is 1518bytes, the header of Ethernet frame (DMAC destination MAC address 48bit = 6bytes + SMAC source MAC address 48bit = 6bytes + 2bytes in type field) 14bytes and the CRC check part 4bytes at the end of frame (sometimes called FCS by this department) are removed, so the place where the upper layer protocol is carried is the most important part of data field We call it MTU when the size is only 1500 bytes. This is what the network layer protocol is very concerned about, because the network layer protocol, such as IP protocol, will decide whether to fragment the data passed down from the upper layer according to this value. It’s just like a box can’t hold a big piece of bread. We need to slice the bread and put it in multiple boxes.
When two remote PCs are interconnected, their data need to go through a lot of routers and a variety of network media to reach the opposite end. The MTU of different media in the network is different, just like a long section of water pipe, which is composed of water pipes of different thickness (different MTU). The maximum water flow through this section of water pipe is determined by the thinnest water pipe in the middle.
For the upper layer protocols of the network layer (let’s take TCP/IP protocol family as an example), they don’t care about the thickness of the water pipe. They think it’s a matter of the network layer. Network layer IP protocol will check the size of each packet from the upper layer protocol, and decide whether to “slice” according to the size of the local MTU. The biggest disadvantage of fragmentation is that it reduces the transmission performance. What can be done at one time can be done many times, so we often pay attention to this in the implementation of the higher layer of the network layer (that is, the transmission layer)! For some reasons, some high-level officials will ask me that this bread can’t be sliced, I want to complete the bread, so I will add a label in the IP packet header: DF (donot fragment). In this way, when the IP packet is transmitted in a large network (water pipe), if the MTU is smaller than the IP packet, the forwarding device will discard the packet according to the requirements. Then an error message is returned to the sender. This often causes some communication problems, but fortunately, most of the network links are mtu1500 or larger.
As far as UDP is concerned, it is a connectionless protocol, and it doesn’t care much about the arrival order and correct arrival of packets. Therefore, there are no special requirements for fragmentation in general UDP applications.
For TCP protocol, it is not the same. This protocol is connection oriented. For TCP protocol, it is very concerned about the arrival order of packets and whether there are errors in transmission. Therefore, some TCP applications have requirements for fragmentation – no fragmentation (DF).
Please come out today’s third pig foot: MSS. The abbreviation of MSS maximum transmission size is a concept in TCP protocol. MSS is the largest data segment that TCP packets can transmit each time. In order to achieve the best transmission efficiency, the MSS value of both sides is usually negotiated when TCP protocol establishes a connection. When TCP protocol implements this value, it is often replaced by MTU value (20bytes of IP packet header and 20bytes of TCP packet header need to be subtracted), so the MSS value is usually 1460. Both sides of the communication will determine the maximum MSS value of this connection according to the minimum MSS value provided by both sides.
After introducing the three pigtails, let’s go back to the problem in the foreword. Let’s imagine that if we adjust the maximum MSS of each TCP connection on the intermediate router, so that the maximum MSS value of the PPPoE link plus the packet header and packet tail will not exceed the MTU size of the PPPoE This will not cause the problem of communication failure. Therefore, the above problem can be solved by iptcp adjust MSS 1452.
Of course, the problem can also be solved by modifying the MTU of PC.
The solution is as follows:
1 – open terminal
Look at the name of your actual user
2 – enter the command ‘whoamI’
3 – enter/dev directory CD/dev
4 – enter the command ‘LS – La | grep BP’
5 – enter the result of the command ‘sudo chown whoamI: admin BP *’
6 – turn on Wireshark again and it’s OK
Recently in the project, I found that when I contracted out two machines, one of them was slow to collect. I wanted to take a look at the package. Before, I just looked at the package.
This time I really care about the window. At first glance, I think it’s strange. I used the following command to catch the bag:
tcpdump-ieth0tcpandport9981-w/data/steven/tcpdump/tcpdump.cap-C1-s0&Mainly is – C, limits the file size to 1m to cut the file. Because the two programs are connected for a long time, there is no syn handshake process for the packets caught in the middle.
Looking at the data, I think it’s very strange.
99 machine told 100 machine, win = 36, but then 100 sent a len = 180 data to 99, which is not in line with the implementation of sliding window!
For a long time, I didn’t find the relevant information, because the method I used to check was wrong. Later, I asked my colleagues to restart the program and catch another bag with a handshake
Syn package, a look, it seems to be more normal:
This package win looks a bit normal, although there is still a problem, 99 win is much smaller than 100. Why do I think the first bag is abnormal
Because RFC has said that MSS Ethernet is 1460 bytes (1500 – 40), and the minimum MSS seems to be 536 bytes (576, the minimum number of bytes of reorganization buffer – 40).
Click on the syn package, and the following two fields attract my attention:
Google took a look at Wireshark window size value calculated window size and found two articles in the reference link
You can only look at the first one when you are surrounded by a wall
Since the TCP header window field is only 16bit, which represents 64K at most, an optional magnification is used to represent a larger window.
1. When TCP shakes hands three times, in syn or syn, ACK packet, inform options optional information, inform the other party that the amplification factor will be used.
2. Syn itself is not amplified
3. Therefore, the window size value represents the value of the message, and the calculated window size represents the enlarged value, that is, the actual available value
This value should be calculated by Wireshark for the sake of friendliness.
Back to the question I said at the beginning, I used the – C parameter when I tcpdump, that is, when the file exceeds 1m, it will be cut into multiple files, when your
When the file does not contain the three times handshake packet (SYN), Wireshark will not know your magnification, so the displayed value will have my question:
Why is win only 36 but can be len = 180.
As you can see, in the tcpdump file without syn package, Wireshark does not know your multiple, so – 1 (unknown) is displayed, and
The value win = 37 is displayed outside your package. If you calculate 128 to correct it (actually 128), the calculated window size is correct
It should show 37 * 128 = 4736, which is not much different from the following. It’s much bigger than 180. Of course, it can send 180.
The following package is caught in the included syn. He can tell you that the multiple is 128, which is actually 5760
Finally, there are two questions about this matter:
Why are the windows on both sides so different when shaking hands?100 is at least 2.4 times of 99.
when TCP starts this magnification.
A: it seems that Linux has a kernel configuration parameter
a[ steven@KFJK ~]$ more /proc/sys/net/ipv4/tcp_ window_ Scaling
1
here is a brief description of [original] adjustment algorithm of TCP receiving window (Part 1)
“if the maximum value of receiving window is limited by TCP_ Rmem [2] = 4194304, then RCV_ Wscale = 7, and the window enlargement is 128. ”
and the setting of my system seems to be just right (but the factor is far more than that):
[ steven@KFJK ~]$ cat /proc/sys/net/ipv4/tcp_ Rmem
4096 87380 4194304
the article recommended by colleagues is good, TCP windows and window scaling
by the way, the article recommended by colleagues Wireshark TCP protocol analysis is also very good.
If you have time, you’d better read the detailed explanation of TCP/IP. Here are two articles written by an expert, fast food:
Things about TCP in coolshell (Part 1) and things about TCP (Part 2)
>Windows 10
References
（1）Wireshark No interfaces found
）
）） https:/www.cnblogs.com/lsdb/p/7144605.html
The journey lasted all afternoon.