[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS #910, ber_pvt_sb_do_write()

The 64K limit comes from the max maxbufsize.  The encode
routine, of course, should choke if maxbufsize is exceeded,
it should just split the data over multiple buffers.

Kurt


At 03:26 AM 2002-05-03, Howard Chu wrote:
>> -----Original Message-----
>> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
>
>> Howard Chu wrote:
>> > -----Original Message-----
>> > Subject: Re: bugfix disposition
>> >
>> >> ITS#910 - filed against 2.0.7 and left Suspended. Seems this
>> code hasn't
>> >> ever changed, but the bug itself is pretty unlikely in the first place.
>> >>        liblber/sockbuf.c
>> >
>> > A fix for this is needed.
>> >
>> >hyc< This is pretty surprising to me. The submitted patch looks
>> fine, but I
>> >hyc< was unable to reproduce any failure on Linux. Perhaps I
>> need to use a
>> >hyc< larger group, but the one I used was already 26K in size. I
>> suppose an
>> >hyc< entry with a jpeg file or somesuch would do just as well.
>>
>> I haven't tried, but:  Did you use Cyrus sasl?  ber_pvt_sb_do_write()
>> is only used in libldap/cyrus.c:sb_sasl_write().
>
>Yes. Unfortunately it is pretty much impossible for me to create the
>conditions that trigger this bug. The only way is to cause a write that is
>so big that it takes multiple attempts for the data to be pushed out onto
>the network. On Linux, the default socket send buffer size is large enough
>that writes of 64K succeed in one attempt. However, SASL has hardcoded
>limits of 64K on its own internal buffers. So, any packet large enough to
>trip this bug is rejected as invalid by the SASL encode and decode routines,
>which makes it a moot point.
>
>I've spent quite a few hours tweaking MAXBUFSIZ constants all over the LBER
>and SASL libraries to allow me to recreate the bug but at this point I'm
>sick of chasing it down.
>
>I should note that this 64K limit (SASL_MAX_BUFF_SIZE) could be quite a
>surprising limitation to run into, we need to doc it somewhere or find a way
>to work around it.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support