dcerpc: reassemble fragmented TCP messages

[RajaMuhammadAwais]

Fixes the TCP-layer fragmentation reported in #3048 using a bounded per-direction buffer and add the issue PCAP as a regression test.

Please sign (check) the below before submitting the Pull Request:

• I have signed the ntop Contributor License Agreement at https://github.com/ntop/legal/blob/main/individual-contributor-licence-agreement.md
• I have read the contributing guidelines at https://github.com/ntop/nDPI/blob/dev/CONTRIBUTING.md
• I have updated the documentation (in doc/) to reflect the changes made (if applicable)

Link to the related Fixes #3048

Describe changes:

Fix DCERPC detection for fragmented TCP messages

Problem

The DCERPC dissector currently validates connection-oriented DCERPC only when the complete message is available in a single TCP payload. When a valid DCERPC fragment is split across multiple TCP segments, the dissector evaluates each segment independently. The first segment does not contain a complete DCERPC PDU, so the dissector is excluded before the remaining segments can be inspected.

As a result, the DCERPC flow from the issue-provided capture is reported as Unknown instead of DCERPC.

The attached issue capture demonstrates a valid DCERPC message distributed across multiple TCP packets, including the DCERPC header and body being received in separate segments.

Root Cause

The previous implementation had no TCP reassembly state for DCERPC and excluded the dissector when an individual payload did not satisfy the complete-message checks.

The existing connection-oriented validation also expects the payload length to match the DCERPC fragment length exactly, which is not true for an incomplete TCP segment.

Solution

This change adds a bounded, per-direction TCP reassembly path for connection-oriented DCERPC messages:

• Maintains separate reassembly state for each TCP direction.
• Buffers candidate DCERPC TCP payloads until the minimum header fields are available.
• Reads the DCERPC fragment length using the protocol byte-order flag.
• Validates the fragment length before allocating or extending the buffer.
• Limits the reassembly buffer to 65,535 bytes.
• Passes the reconstructed complete PDU through the existing DCERPC classifier.
• Frees all reassembly buffers during normal flow cleanup.
• Preserves the existing UDP connectionless and complete single-packet TCP detection paths.
• Avoids treating TCP retransmissions as new fragment data.

Regression Test

The PCAP supplied in issue #3048 was added as a regression fixture:

tests/cfgs/default/pcap/dcerpc-fragmented.pcap
tests/cfgs/default/result/dcerpc-fragmented.pcap.out

The fixture verifies that the fragmented flow is detected as DCERPC instead of remaining Unknown.

Verification

The following checks were completed:

• Issue Wrong classification of DCERPC PCAP data #3048 fragmented PCAP: detected as DCERPC with 19 packets and 1 flow.
• Existing dcerpc.pcap fixture: passes with no output difference.
• New regression fixture using the same command format as tests/do.sh: passes with no output difference.
• ./tests/do-unit.sh: passes.
• ./example/ndpiReader --run-tests: exits successfully.
• git diff --check: passes.
• Project compilation with make: passes.

The complete ./tests/do.sh suite was started but became excessively long in this environment, so it was stopped safely. The focused regression, existing DCERPC fixture, internal tests, and unit tests listed above were run successfully.

Scope

This is a focused fix for DCERPC connection-oriented messages fragmented across TCP segments.

It does not change the existing connectionless UDP detection logic or the normal complete-PDU TCP fast path.

Related Issue

Closes #3048

[IvanNardi]

@RajaMuhammadAwais, could you rebase please?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud