Wireshark-bugs: [Wireshark-bugs] [Bug 11322] Regression: TCP reassembly can fail DISSECTOR_ASSER
Comment # 7
on bug 11322
from Hadriel Kaplan
(In reply to Pascal Quantin from comment #4)
> Note that those sanity checks are also present in master-1.12 branch, but
> were done only for some sub dissectors and not for all. The changeset you
> refer to simply extended the check to all returns from dissectors rejecting
> the packet.
> It really look like an issue in your Lua script that was simply hidden
> previously.
As far as I can tell, the difference is that in 1.12 the check only verified
that a *heuristic* dissector didn't change the desegment_len/desegment_offset,
if the heuristic dissector did not decide the packet belonged to it.
But for other dissector types, they could change the
desegment_len/desegment_offset, even if their dissection process returns a
value of 0/false. But in 1.99, the change makes it impossible to change those
values unless the dissector returns a non-0 value.
According to https://wiki.wireshark.org/Lua/Dissectors as well as section 2.7.2
of README.dissector, a dissector is supposed to set pinfo's desegment_len and
desegment_offset to indicate where to start off the next time. So as far as I
can tell, dissectors are supposed to modify those values if (1) the packet is
for them but (2) it's not a complete message yet.
But what those docs don't say is what value the dissector function should
return in such a case. The docs say that they should return the number of
bytes "successfully processed", but in a reassembly case they may not have
successfully processed any bytes yet.
So what should a dissector use for its return value if the packet is for it,
but it cannot parse the packet because it needs more bytes?
You are receiving this mail because:
- You are watching all bug changes.
