Repository navigation
refactor(reassembly): bring DTLS reassembly to IP/TCP parity (deferred packet, __protocol_type__) #2531
Description
Follow-up from #2528 (owner's answer to Q4). After #2496's rework, DTLS reassembly still differs from IP and TCP in the two ways reassembly-integration.rst lists as remaining divergences:
- no deferred
Datagram.packetthat runsdtls_handshakethe way IP and TCP useDeferred; - no
__protocol_type__on the DTLS reassembly class, which is now possible becauseDTLS.read()no longer imports reassembly.
Blocked: this builds on #2528's toolkit and analysis routing, and unblocks when #2528 merges.
Activity
JarryShaw commentedon Nov 1, 2026
Unblocked: #2528 merged, so DTLS reassembly now routes through the toolkit and
foundation.analysis. Dispatched.JarryShaw commentedon Nov 1, 2026
And what about IP and TCP reassembly analysis? Should we also add to the analysis module?
JarryShaw commentedon Nov 1, 2026
Paraphrased: should IP and TCP reassembly also get
foundation.analysismodules? Today only DTLS has one. IP and TCP outcomes go through the generalProtocol.analyzedispatcher viaDeferred, and reassembly-integration.rst records that point 3 holds for DTLS alone. Options and a recommendation are on #2581: add thinanalysis/ip.pyandanalysis/tcp.py, so the package mirrors reassembly engine by engine. That is a separate change after this issue's PR, since both edit the same package and page. This issue stays on its DTLS parity scope.