Comment # 11
on bug 11322
from Hadriel Kaplan
(In reply to Pascal Quantin from comment #9)
> The current code does not seem to have triggered any issue with all the
> existing builtin dissectors since a year, so maybe I'm missing something.
Well it's not like a lot of people use 1.99. :)
I'm sure it works fine for HTTP and the popular protocols - heck it could work
fine for ALL the built-in c-code based dissectors as far as I know.
> Right now when dissector_try_uint_new returns 0, we seem to consider that
> the packet was rejected by the dissector registered on that port:
Yup.
> SO I find it odd to have a dissector that acknowledges a packet as being for
> it still returning 0: how can the caller can make the difference between an
> existing and non existing sub dissector?
Yeah, I've been trying to figure out how their Lua script worked in previous
releases, even ignoring this assertion check. I think what happened was, in
the first dissection pass of the packet it ends up getting "dissected" by the
plain "data" dissector; but on the second pass it's been associated with the
later fragments into a bigger one and processed by their BNETP dissector, and
the "data" dissector doesn't get called nor show up.
You can actually see this happening if you do it in tshark and compare what
gets shown for wireshark, for frame #6.
So yeah this does look like a bug in the script, fundamentally. My only worry
is that other scripts people use may have done the same thing. (I know we don't
guarantee backward-compatibility, but I try hard to keep it if possible)
You are receiving this mail because:
- You are watching all bug changes.