https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2812
Graham Bloice <graham.bloice@xxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |graham.bloice@xxxxxxxxxxxxx
--- Comment #3 from Graham Bloice <graham.bloice@xxxxxxxxxxxxx> 2011-07-06 02:18:08 PDT ---
(In reply to comment #2)
> For packet-dnp.c, I don't know if a call to dnp3_al_get_timestamp() is the
> answer there or not in the case of AL_OBJ_BIC_RTIME, similar to the AL_OBJ_TD +
> AL_OBJ_TDCTO case. Or quite possibly it's fine as it is since it's all wrapped
> in a for() loop going back to line 1390 and perhaps you'll never see a case of
> AL_OBJ_BIC_RTIME without a prior AL_OBJ_TD or AL_OBJ_TDCTO within this
> protocol? If so, maybe just initializing al_cto to zero is good enough?
> Unfortunately, I don't know anything about dnp either to make a good enough
> determination for the best fix here. :(
>
As per the protocol spec, you can't have an object with relative time without a
preceding common time object, as the time is relative to that.
However it's conceivable that a protocol implementation may get this wrong and
not provide a CTO, so we should then detect this with an Expert Info error.
I'll look into this.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
