Ethereal-dev: Re: [Ethereal-dev] Re: rev 17527: /trunk/plugins/profinet/: packet-pn-dcp.c
I'm not familiar with this protocol, too.
However I guess that it is mandatory in this protocol to have a length
indicator after the type and subtype indicator.
Thus the length of the value should be stored unconditionally in
"block_length", like in dissect_PNDCP_Suboption_IP().
If the remaining length of the pdu, which is stored in "length", is big
enough to contain the whole tlv block, should be checked seperately.
IMO in its current state the dissector is not very robust.
I have some time left to work on these issues on the weekend, but I don't
have any traces to test with or a specification to verify my assumptions
on the protocol structure.
As a short time workaround, it should be sufficient to throw an exception,
if "block_length" is used uninitialized.
Am 10.03.2006, 00:33 Uhr, schrieb ronnie sahlberg
<ronniesahlberg@xxxxxxxxx>:
I would say just throw an exception there.
I am not familiar at all with that protocol and usually dont even
build with plugins.
On 3/9/06, Gerald Combs <gerald@xxxxxxxxxxxx> wrote:
sahlberg@xxxxxxxxxxxx wrote:
> User: sahlberg
> Date: 2006/03/08 04:59 AM
>
> Log:
> fix coverity bug 122
>
> Directory: /trunk/plugins/profinet/
> Changes Path Action
> +6 -4 packet-pn-dcp.c Modified
There are a few places in the PN-DCP dissector that block_length might
be used unititialized. Is a zero block_length value ever valid in these
cases? If not, is it OK to throw an exception if it's
zero/uninitialized?
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
