[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 11 on bug 12882 from Guy Harris

(In reply to Michael Mann from comment #10)
> (In reply to Guy Harris from comment #9)
> > If there are TCP dissectors that do reassembly, use a heuristic, and don't
> > use conversation_set_dissector(), there can be cases where the reassembly
> > will fail, so those dissectors are buggy.
> 
> Are you talking TCP reassembly or reassembly of layer above the protocol
> running over TCP? (TDS certainly qualifies trying to reassemble NETLIB)

TCP reassembly.

> I think I've been lulled into believing that heuristics are used for the
> start of a packet and most TCP dissectors use them just because they don't
> have the "determinism" of a reserved IANA port.  How often are you really
> presented with the start of a TCP PDU in the middle of a TCP packet?

If you mean "how often does *the first captured packet of a TCP connection*
contain the end of a multi-segment PDU and the beginning of the next PDU", the
answer is "probably not too often", but which dissectors handle that cases?

(If you mean "how often does an arbitrary packet in a TCP connection contain
the end of a multi-segment PDU and the beginning of the next PDU", the answer
is "often enough that it's a good thing that, given the general way
tcp_dissect_pdus() works, we happen to handle that case as long as reassembly
is being done and we managed to dissect the beginning of the first of those
PDUs".)

> Maybe
> the first PDU at the start of a capture, and I guess I can usually live with
> that (not being dissected), because it would end up being way too expensive
> (performance) to ensure Wireshark "guessed right".  I also sometimes have a
> hard time distinguishing "need" (for heuristics) from overzealous developer
> trying to put as many entrances to his protocol as possible (especially with
> older dissectors).

I'd say that any protocol that 1) is a popular protocol and 2) doesn't have a
fixed port assigned to it should have a heuristic dissector if possible; if the
heuristic is really weak (such as the RTP heuristic), it should probably not be
enabled *by default*, but we shouldn't require the user to use "Decode As..."
for protocols such as ONC RPC-based protocols (to give an example of a
heuristic that works pretty well and that is pretty useful).

> I still think switching to TDS to use tcp_dissect_pdus is worthwhile, but
> without removing conversation_set_dissector(), this capture is still stuck
> thinking it's TDS.  I can see the merits of keeping the
> conversation_set_dissector, I'm just not sure how practical it is and I
> would be okay removing the heuristic dissector altogether (in favor of using
> preferences/Decode As) rather than disabling the heuristic for being too
> weak.

I wouldn't be okay with it, given that SQL Server is, as far as I know, a
fairly popular database server, so there's probably a significant amount of TDS
traffic out there.  If you have the heuristic, you can disable it; if you
*don't* have the heuristic, you can't enable it....

What might be useful here would be

  1) a way of saying "frames XXX through YYY of this conversation should be
decode as protocol PPP" (which might also be useful for protocols that can
switch to TLS in the middle of a session, for example)

and

  2) having tcp_dissect_pdus() (and other wrappers that handle reassembly over
byte-stream protocols, such as the text-based request-response protocol code)
on the first pass *automatically* mark the conversation as "all frames from the
current frame through the end of the capture should be decoded as protocol PPP"
if it decides that more data needs to be added as part of reassembly, so that,
at minimum, the next segment in that flow gets handed to the dissector so that
the reassembly can be one, and have it only close out that mark when it finds a
PDU that ends at the end of the segment.

At least that way, we wouldn't be marking the *entire* conversation as TDS in
this capture.  If we don't want *any* conversations dissected as TDS, either we
need to strengthen the heuristic in the TDS dissector, or the user has to
disable the TDS heuristic.  Users doing a significant amount of MSSQL
dissection would presumably want to leave that heuristic enabled, as it would
probably get the right answer more often than it gets the wrong answer.)

(Actually, that needs to use both frame numbers *and* offsets within the
segment, in case the protocol changes in the middle of the segment.  Dissecting
protocols running over protocols offering a byte-stream service is hard, let's
go shopping!)

---

      You are receiving this mail because:

• You are watching all bug changes.