TcpReassembly: data frames after FIN

[matthiasklein]

Bug description

I am trying to analyze FTP transfers with PcapPlusPlus. To extract the files from the passive FTP transfers, I used the TcpReassembly example as a reference. Basically, the extraction of the files works via the pcpp::TcpReassembly class. Unfortunately, in a longer test, too little data is extracted from the TCP stream in 14 of 355 transfers. TcpReassembly then reports missing data in the OnTcpMessageReady callback via the TcpStreamData object with the GetMissingByteCount() function. In a debug log, I see the following messages:

Got a packet after FIN or RST were already seen on this side (1). Ignoring this packet

On the hardware side, a TAP is connected between the switch and one of the two participants. From the TAP, the transmission and reception directions are separated via 2x USB Ethernet adapters (LAN9005A chipset) to an ARM Linux computer. There, I combine the two interfaces via the bonding kernel module for the PcapPlusPlus library. The FTP server is Wind River's VwWorks RTOS.

In all 14 “faulty” transmissions, I see a frame with a FIN flag shortly before the end, followed by more data frames. The frame with the FIN flag belongs at the end of the sequence number, but it arrives a few frames too early. See screenshots of three transmissions: (I cannot publish the complete dumps).

By recording via two different network interfaces, I can understand when the ACK packets from the other side are delayed.

Does such an “out-of-order” FIN frame still comply with the TCP specification? Can I expect the other side to understand this normally? (I do not have access to the other side.)

How complex is it to take this case into account in the pcpp::TcpReassembly class?

PcapPlusPlus versions tested on

Other (specify in the next question)

Other PcapPlusPlus version (if applicable)

v25.05

Operating systems tested on

Linux

Other operation systems (if applicable)

Yocto scarthgap armhf

Compiler version

13.2.0

Packet capture backend (if applicable)

libpcap

[seladb]

@matthiasklein thanks for the detailed explanation of your scenarios. To be honest, I'm not super familiar with FTP servers and how they work, and I'm not a TCP protocol as well 🙂

Generally, data packets shouldn't come after FIN. Whether operating systems can handle that - I don't know 🤷‍♂️

Currently TCP reassembly doesn't support that, and it wouldn't be easy to add because it needs to clean up closed flows resources and the best time to do it is when receiving a FIN packet. We could add logic that waits for some time after FIN, but it wouldn't be trivial