[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.


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