https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12882
--- Comment #11 from Guy Harris <g...@alum.mit.edu> --- (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.
___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
