https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3749
Mark Chambers <mark.chambers@xxxxxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark.chambers@objectmastery.
| |com
--- Comment #3 from Mark Chambers <mark.chambers@xxxxxxxxxxxxxxxxx> 2009-07-30 17:39:56 PDT ---
Improvements:
1. GDSDB packets contain one or more, full or partial messages. The old
dissector only attempted to decode the first message in a packet. The new
dissector attempts to decode all the messages in a packet.
2. There are about 80 message types defined in the protocol. The old dissector
didn't attempt to decode all of them. The new dissector does.
3. Each message contains several fields. The old dissector didn't attempt to
show many of these fields. The new dissector does.
Known Problems:
1. GDSDB messages are not self describing and the length of the data is very
difficult to determine just by looking at an individual packet. Unfortunately,
the "fetch response" message (which contains the actual data returned by an
sql query) is one of these. In order to decode it, information from a previous
message (the "prepare response") needs to be remembered and matched against at
he multiple following "fetch response" messages. The format of the data for
both the description in the "prepare response" and "fetch response" is not
described anywhere except deep in the firebird source code.
As a result of this, the dissector cannot currently decode "fetch response"
messages and gets confused about messages that follow it. Both the old and new
dissectors suffer from this but it is more of a problem in the new dissector
because it tries harder to actually decode following messages.
This confusion can result in garbled messages, dissector exceptions and
hangups.
2. Follow on messages (ie. the ones that you use DESEGMENT_ONE_MORE_SEGMENT to
handle) are not processed correctly. Theoretically, this can be fixed, but it
doesn't work the way I expected it to and due to the problems outlined in (1),
there doesn't seem to be much point.
Summary
On reflection, I am not happy at all with the state of this dissector. You get
a better (although still incomplete) picture of what is going on with the new
dissector than the old one but at the expense of dissector exceptions and
hangups. Should it be included? I don't know.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.