Closed xiaohuihui1024 closed 3 years ago
I found that just two changes will get the desired result.
I've already seen what the tcp_reassemble
function does here. The merged TCP packet is formed from the last segment and splits the defragmenting payload. The relevant code is as follows:
Change 1:
The wirelen
obtained here is still the wirelen
of the original last segmented TCP packet (Frame 9), which will cause the TCP payload to show only the first 741 bytes
of the reassembled payload in Wireshark, with an expected value of 3641 bytes
I changed the value of wirelen
to caplen
during debugging, and Wireshark successfully identified the TLS Layer.
Change 2: [Expert Info (Warning/Sequence): Previous segment(s) not captured (common at capture start)]
For a similar reason, simply change seq
of the reassembled packet to the seq
of the first packet in the fragments, instead of the seq
of the last packet.
To record the seq
field of the first packet in TCP fragments, add this information to the metadata
, such as here
https://github.com/secdev/scapy/blob/6eef12d2de02ec4822c19621fd3847a498ca1387/scapy/sessions.py#L291-L302
metadata["seq"] = pkt[TCP].seq
The seq
needs to be corrected when returning the defragmented packet
if packet:
pkt["TCP"].seq = metadata["seq"] # before metadata clears, correct it !
data.clear()
metadata.clear()
del self.tcp_frags[ident]
pay.underlayer.remove_payload()
if IP in pkt:
pkt[IP].len = None
pkt[IP].chksum = None
Brief description
At first, I parsed the
pcap
file throughrdpcap()
, however it can`t handle TCP defragmentation.Under the guidance of #2763 and https://scapy.readthedocs.io/en/latest/usage.html#advanced-sniffing-sniffing-sessions, I use
pkt = sniff(offline="xxx.pcap", session=TLS_over_TCP)
to read and the parse pcap file. From the result ofpkt.show()
, it solves TCP fragmentation well.However, when I try
wrpcap("sniff_dealed_xxx.pcap", pkt)
, the defragmentation results don`t show up in Wireshark.Environment
2.4.5rc1.dev55
6eef12d3.7.4
Windows 10
How to reproduce
To be specific, I used 192.168.165.217_49183_156.38.206.18_443_1593515552.pcap provided by @knwng in #2763
You can run the following python code to reproduce the bug:
Actual result
No.6 ~ No.9 packets in the original pcap file are automatically defragmented in Wireshark , as shown in the figure below.
After
wrpcap("sniff_dealed_xxx.pcap", pkt)
, use Wireshark to viewsniff_dealed_xxx.pcap
We focus on No.6 packet.
It is found that it does merge data packets from No.6 to No.9 into No.6, but there are two problems:
Total Length:3681
that the TCP segment data is indeed mergedTCP payload (741 bytes)
length is still the length of the last TCP packet before the merge (No.9 in original pcap).The result of
pkts[5].show()
isAt least in the Scapy data structure, it does merge, but why the strange phenomenon in Wireshark ?
Expected result
The more reasonable results are as follows:
I'm willing to provide a PR but it may take some time. I'm debugging the code implemented internally, hoping to find out why.