https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4082
Gerasimos Dimitriadis <dimeg@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dimeg@xxxxxxxxxxx
--- Comment #4 from Gerasimos Dimitriadis <dimeg@xxxxxxxxxxx> 2009-10-02 14:25:19 PDT ---
Hi all,
when I updated the dissector for classmark 3, I made the assumption that all
data for a given release would be present, thus checks on the remaining bits
are made only on release boundaries. If an all-zero fraction of an octet is
left then the code assumes that these are spare bits and not actual data from
elements introduced in the next release.
24.008 mentions that 'The receiver may add any number of bits set to "0" at the
end of the received string if needed for correct decoding.' So, thinking about
it again, the above assumption is not necessarily true. The encoder could stop
adding classmark 3 bits at any time.
I disagree with the solution currently attached to this bug. It solves the
issue with this specific 'MS Classmark 3', because the '8-PSK struct present'
bit happens to be the last one in an octet. If the previous bits had other
values, then the '8-PSK struct present' bit could as well be in the middle of
an octet.
I think that a better solution would be to check before each element (or group
of elements) is read, whether enough bits are available. For some elements
(especially early ones) this check could be skipped, but for most of them their
position in an octet depends on the value of previous data so it not known
beforehand.
Best regards,
Gerasimos
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.