https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7008
--- Comment #6 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-04-05 12:36:24 PDT ---
(In reply to comment #5)
> This, of course, doesn't help if you didn't capture the connection setup; it's
> useful, but insufficient.
I'm open to ways to make it more sufficient. I was more worried that there
was a reason this wasn't done already. It is possible it will add more
confusion because different dissectors will be chosen based on if the
connection setup is captured or not?
> I'm also not sure how the "minimum segment size" affects things here. Is the
> "minimum segment size" a value used by heuristic dissectors, i.e. the minimum
> amount of data necessary to see whether the data in a TCP stream is for the
> protocol in question? Or is it the "fixed_len" argument to tcp_dissect_pdus(),
> which is *not* a minimum segment size - if tcp_dissect_pdus() doesn't
> reassemble smaller segments as necessary to get that amount of data, that's a
> bug, as it means that it's not doing enough reassembly?
No, you're right in that its the "fixed_len" argument that is the same for the
dissectors in question. My thinking was that the "fixed_len" argument for
those dissectors was a "minimum segment size" because within that "minimum
size" it contained the "expected length of the (protocol) packet" (per the
dissector) to reassemble. If the "minimum size" was different, it's more
likely that a dissector's "length field" would be at a different offset/size,
and possibly return an "invalid" value, causing the TCP dissector to try
another dissector (ie the "higher" port).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.