Still looking at the problem of minimal headers split across tcp segments...
Given a minimum header length of L, we only get L - k bytes of the
header at the end of the first packet. So we record in the reassembly
data structures that we need k more bytes. They come in the next
packet, and I think what may be happening is that when fragment_add*
is called the desegment_tcp or reassembly engine thinks we're "done"
at that point... we have all fragments necessary to dissect the PDU so
a non-null fd_head is returned. In fact we do have all the data, but
the reassembly engine hasn't been updated to know about the length of
data beyond the L bytes of minimal header.
When should desegment_tcp reevaluate the amount of remaining data (by
calling the higher level dissector (which calls tcp_dissect_pdus)) and
update the reassembly engine?
Sorry I'm just getting up to speed on this reassembly stuff... it's a
bit complex. Multiple hash tables, basic list operations conflated
with reassembly and validation (fragment_add sometimes returns an
object sometimes it doesn't based on evaluating what it just got in
the context of what it already has), tail recursion: desegment_tcp has
got it all.
The fragment reassembly engine definitely deserves some more
documentation. If I end up grokking it I will help write some.
-- John.
