Guy Harris <guy@xxxxxxxxxxxx> wrote on 12/12/2006 09:50:51:
>
> On Dec 12, 2006, at 1:40 AM, Andy.Ling@xxxxxxxxxxx wrote:
>
> > Guy Harris <guy@xxxxxxxxxxxx> wrote on 11/12/2006 18:50:43:
> >
> >> It *is* designed to cope with offset beyond the buffer length - an
> >> offset beyond the buffer length is an obvious error, so it throws an
> >> exception.
> >>
> >
> > Except in this case it is not an error.
>
> Yes, it is. It makes no sense whatsoever to add a protocol tree item
> that refers to data past the end of the packet, as that data doesn't
> exist. It's designed to cope with the offset being beyond the buffer
> length by throwing an exception to report an error. If the packet
> isn't erroneous, then the bug isn't that proto_tree_add_item() isn't
> doing what it should be doing (it's doing exactly what it should be
> doing), it's that it shouldn't be called with that offset in the first
> place.
>
Fine, but then why should it cope with an offset of 0. You shouldn't be
trying to add a protocol tree item when the offset is 0, there's
no data there either.
We could discuss the semantics of this all day, but it's not fixing
the problem. I have perfectly good CORBA packets that are showing
up as errors. I have spent a fair bit of time finding out why and
now I'd like some help to find the best way to fix it.
I agree with you that proto_tree_add_item should not be called if
there is nothing to add and I said as much in one of my earlier
posts, but the current code is based on the principle that this
can be done. To change this requires changing the python code
generator that creates the dissector source from the CORBA idl.
This is outside my experience. I also don't understand the
detail of the wireshark code to know the best way to fix this
problem.
So what is the best way to move forward on this?
Regards
Andy Ling
