Wireshark-bugs: [Wireshark-bugs] [Bug 11322] Regression: TCP reassembly can fail DISSECTOR_ASSER

Date: Tue, 30 Jun 2015 20:20:04 +0000

Comment # 7 on bug 11322 from
(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.