Topic Information
This case is the third topic in the Sharkfest 2015 Packet Challenge, FTP ME, BABY (this name is really good), and the packet trace file is tcp-bigftp.pcapng .
The main description is as follows:
1. What TCP options are supported by both client and server in this trace file?
2. What Window Size(s) are advertised in each Window Update packet?
3. What operating system must be supported to use the downloaded file?
4. How much is the largest delay preceding a Window Update packet?
5. Why does Wireshark indicate the Window Scaling factor is ‐1 in some of the packets?
Packet information
The basic information of the packet trace file is as follows:
λ capinfos tcp-bigftp.pcapng
File name: tcp-bigftp.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 6120
File size: 11 MB
Data size: 11 MB
Capture duration: 24.668708 seconds
First packet time: 2012-08-02 03:38:39.142142
Last packet time: 2012-08-02 03:39:03.810850
Data byte rate: 468 kBps
Data bit rate: 3748 kbps
Average packet size: 1888.69 bytes
Average packet rate: 248 packets/s
SHA256: bfb28f553bea551a2023825ed6ec1aa2bb57a8893111c8baa804d2ee0a1b3929
RIPEMD160: af787ba3f0cf4f933e35fba11b82276c482a1892
SHA1: c416ef5f71076c7dc1dad7d5f4978d37b2ee41c6
Strict time order: True
Capture oper-sys: 64-bit Windows 7 Service Pack 1, build 7601
Capture application: Dumpcap 1.8.1 (SVN Rev 43946 from /trunk-1.8)
Number of interfaces in file: 1
Interface #0 info:
Name = \Device\NPF_{6E79FEC0-FF79-4970-96E4-EEFF300A9B9F}
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Operating system = 64-bit Windows 7 Service Pack 1, build 7601
Number of stat entries = 1
Number of packets = 6120
λCaptured directly via Wireshark on a Windows 7 system, without truncation, the file size is 11MB, the number of captured packets is 6120, the capture duration is 24.67 seconds, and the average rate is 3748 kbps.
The protocol layer information statistics are as follows, including FTP control connection and data connection information.
The expert information is displayed as follows, which is unusually concise and has no Warning level information, only a large number of TCP window updatemessages.
Packet Analysis
The initial expanded information of the packet trace file is as follows. There are actually 2 TCP Streams, one for the FTP control connection and the other for the FTP data connection.
λ tshark -r tcp-bigftp.pcapng -T fields -e tcp.stream | sort -n | uniq
0
11. What TCP options are supported by both client and server in this trace file?
In this trace file, what are the TCP options supported by both the client and the server?
Analysis steps
Speaking of which TCP options, I think of the TCP header message format diagram, which is classic. You can see TCP optionsthat it is an optional field of variable length.
Generally, TCP interaction between clientTCP options and server starts with TCP three-way handshake, and the common support between them is also negotiated at this stage. You can filter out SYN and SYN/ACK by displaying the filter expression.
tcp.flags.syn == 1
Detailed information of client No.8 and server No.9 TCP optionsshows that they both support MSS, Window Scale, SACK, TCP Timestamps.
Analyze the answer
In this trace file, the TCP options supported by both the client and the server are: MSS, Window Scaling, SACK, TCP Timestamps.
2. What Window Size(s) are advertised in each Window Update packet?
What is the Window Size announced in each Window Update Packet.
Analysis steps
The first thing to note is the specified packet category, which is Window Update packet, so first filter by display filter, there are 245 packets in total, accounting for 4.0%.
tcp.analysis.window_update
Secondly, the Window Size comes from the product of the notification Window and the Window size scaling factor (which is also the result of TCP Options in 1, supported by both the client and the server), that is, 33304 * 2 = 66608 .
Of course, you can also Packet Listadd Window sizean information column in the view, all of which are 66608.
Analyze the answer
The Window Size announced in each Window update packet is: 66608.
3. What operating system must be supported to use the downloaded file?
What operating systems must the downloaded files support?
Analysis steps
First, analyze what file is being transferred and downloaded in the packet trace file. Through the control connection, you can see that the client is requesting kidsatbeach.jpga file.
The question describes downloading, but the actual FTP data packet is uploading. In addition, the file format is jpg . I don’t know much about the operating system. What operating system must be supported? Win is OK, but Linux is not? ⁉️
Analyze the answer
What operating system must the downloaded file support: win.
The answer is win for now, maybe there is something wrong with my approach to solving the problem…
4. How much is the largest delay preceding a Window Update packet?
What is the maximum delay before a Window update packet?
Analysis steps
This question is also a bit confusing. Taking a Windows Update data frame on the client as an example, there may be several types of delays:
- Comparison with the last captured data frame ;
- Comparison with the last displayed data frame (based on TCP stream filtering);
- Comparison with the previous data frame displayed in the same direction (based on TCP flow filtering).
This problem is solved with the second approach. First, filter out all the data packets in TCP Stream 1 and export them into a new pcapng file. Then, filter them out in the new pcapng file using the display filter expression Windows Updata packet.
tcp.analysis.window_update
Then Packet Listadd an information column in the view with the fields as frame.time_deltafollows, which are the time difference between each Window Update packet and the last captured data frame.
This is a time comparison with the last captured data frame because the TCP Stream has been filtered out and saved as a new file, and then filtered out by tcp.analysis.window_update.
By arranging from large to small, we can see that the maximum delay time is as follows: 0.006486 seconds, the time interval between No.6103 and No.6102.
Analyze the answer
The maximum delay before a Window update packet is: 0.006486 seconds.
5. Why does Wireshark indicate the Window Scaling factor is ‐1 in some of the packets?
Why does Wireshark indicate a Window Scaling Factor value of -1 on some packets?
Analysis steps
First, Window Scaling Factor is a field in TCP Options. In question 1, we mentioned that TCP interaction between a client and a server generally starts with a TCP three-way handshake, and the commonly supported options TCP optionsare negotiated at this stage. The use of Window Scaling Factor can be divided into the following situations:
- If both the client and the server support it, the WS value announced by each SYN or SYN/ACK can be used in subsequent data exchanges, and the Window size Scaling Factor is marked as this value;
- If either the client or the server does not support it or both ends do not support it, the Window size Scaling Factor will be marked as -2 during subsequent data exchange.
- There is also a special case where SYN and SYN/ACK are not captured in the packet trace file, that is, Wireshark cannot determine whether the Window Scaling Factor is used, then the Window size Scaling Factor will be marked as -1 in subsequent data interactions.
tcp.window_size_scalefactor == -1The results filtered by displaying the filter expression are actually all FTP control connection data packets, because no TCP three-way handshake phase messages were captured under TCP Stream 0 , so the Window size Scaling Factor is -1. And the Window of No.1 is 16114 bytes, because the Window size Scaling Factor is unknown, so the Calculated window size is also 16114 bytes.
The Window Size Scaling Factor value of -1 is just a judgment made by Wireshark based on the context of the packet trace file. It is marked as -1 when the actual Factor value is unknown. It does not mean that the TCP connection between the actual client and server is not supported.
Analyze the answer
Why does Wireshark identify the Window Scaling Factor value as -1 on some packets: Because the TCP three-way handshake is not captured.