https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5257
--- Comment #5 from Mike Morrin <wireshark@xxxxxxxxxxxxxxx> 2010-10-04 08:21:03 PDT ---
2 reasons:
1. For the HL bits, the meaning depends on the difference between the
transmitted bit and the nominal "padding" bit, so sometimes 1 is true and
sometimes 0 is true, so the spec refers to them as H/L bits rather than 1/0 and
it seems sensible for the dissector to treat them the same way.
2. For PDUs where truncation is allowed, there are implicit "L" bits which
don't correspond to any actual bit in the buffer, and decode_bits_in_field()
throws an error when trying to handle these (I did try modifying
decode_bits_in_field() to cope with imaginary data, but it was even uglier).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.