https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5391
--- Comment #11 from Emil Wojak <emil@xxxxxxxx> 2010-11-22 17:05:06 PST ---
That's great! Thanks for committing the patch, I'm very happy to see it in :)
(In reply to comment #10)
> > Is there any chance for the patch to enter Wireshark-1.4?
> Hmm, I think this qualifies as an enhancement, not a bug fix, so it normally
> won't be backported to the stable branch.
Tough luck, I'll have to wait for the next major release then :]
I have one objection to your changes. The DISSECTOR_ASSERT_NOT_REACHED macros
were in places, that the dissector indeed should never reach regardless of
packet's payload.
In the first case the switch must handle all data types, for which the
dissector itself might have set plp = TRUE in dissect_tds_type_info().
In the second case the inner switch must handle all data types that lead here
from the outer switch in the first place.
So there's no input dependency here.
BTW the return statement in place of the second DISSECTOR_ASSERT_NOT_REACHED is
indented with tabs, I'm not sure whether that conforms to Wireshark's
formatting rules, so I'm just letting you know ;)
As to the ReportedBoundsError, I thought this is the correct way of aborting
dissection in case further parsing makes no sense. When we encounter a type
that is either unknown or unsupported yet, further dissection has literally no
chance of yielding any reasonable results. The dissector will just try to parse
another RPC parameter from the middle of currently incompletely parsed
parameter. That can't do any good.
This could be justified if it was possible to just skip to the next parameter,
but in TDS that's impossible, because the size of an RPC param is not known in
advance, so it needs to be parsed fully and correctly to get to the next param.
In case of dissect_tds_all_headers it's questionable whether to continue
parsing, because in case total headers length differs from sum of headers'
lengths, then at what offset should further dissection continue? Either choice
is totally arbitrary and each might succeed in one type of protocol error and
fail in another.
Please tell me what you think.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
