Re: found a weird bug....

[Pythagoras W. <py...@ec...>]

On Wed, May 10, 2000 at 05:30:13AM -0700, Kurt D. Zeilenga wrote:
:At 02:59 AM 5/10/00 -0700, Pythagoras Watson wrote:
:>This appears to be a decoding error on Net::LDAP's part.  When the
:>operation number (5th byte of response) reaches 128 (0x80), the
:>resulting message code changes to two.
:>
:>To wit:
:>  searching 126
:>  ...
:>  30 38 02 01 7F 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py,
:>  ...
:>  0002 02    1:   INTEGER = 127
:>  ...
:>  searching 127
:>  ...
:>  30 38 02 01 80 64 33 04 2F 75 69 64 3D 70 79 2C 08...d3./uid=py,
:>  ...
:>  0002 02    1:   INTEGER = -128
:>  search failed: 2
:>
:
:	02 01 7F ==  127
:	02 01 80 == -128
:
:02 INTEGER
:01 length of 1
:xx 2-complement base-256 value

Interesting and good to know.

:>From RSA's Layman's Guide:
:> Some example BER encodings (which also happen to be DER
:> encodings) are given in Table 3.
:>
:>                   Integer   BER encoding
:>                   value
:>                   0         02 01 00
:>                   127       02 01 7F
:>                   128       02 02 00 80
:>                   256       02 02 01 00
:>                   -128      02 01 80
:>                   -129      02 02 FF 7F
:
:Appears to me that your server is broke.

Always a possibility, although I get the same results against both
Netscape Directory Server 3.X and OpenLDAP 1.2.3.  Perhaps the problem
is still in Net::LDAP.  Specifically I note that the SENDING debug info
(which I did not generate before) has (for the 127th search):
  30 52 02 01 80 63 4D 04 29 6F 3D 43 61 6C 69 66 0R...cM.)o=Calif
which I assume is also incorrect and is causing the server to return
the same bad info.  I note that both sent and received packets are
encoded correctly when using Convert::BER.

-- 
Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383...
Pythagoras Watson -- "Live long and may all your kernels pop."
=== py...@cs... ==== http://www.ecst.csuchico.edu/~py/ ===