Wireshark-dev: Re: [Wireshark-dev] Malformed packets in CORBA protocol plugin
From: Guy Harris <[email protected]>
Date: Tue, 12 Dec 2006 02:55:20 -0800
[email protected] wrote:

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.
Eh?  An offset of 0 just means "beginning of the packet".

If you mean "length of 0", then a length of 0 is used in two places:

	1) generated items, where neither the offset nor the length are meaningful;

2) the top-level item for a protocol if the amount of data available for the protocol is 0 - that allows the top-level item to be added, with the exception thrown when you create the sub-item.
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.
It's not as if somebody necessarily explicitly said "I'll write this on 
the assumption that there are always parameters to a call" - it might 
have been written without bearing in mind that there aren't (i.e., it's 
not as if it's a Fundamental Design Decision).
I'd suggest moving the start_dissecting() calls into the routines that 
process individual procedure requests and replies, and avoid generating 
those calls if there are no items expected.
See, for example, genOperationRequest() in wireshark_gen.py; it could, 
for example, start out by setting a flag to false and, before the 
self.getCDR3() call, if the flag is false, put out the 
start_dissecting() call and set the flag to true, so that the 
start_dissecting() call is put out before the first parameter.