On Thu, 2 Mar 2017 22:43:41 +0100
Alexander Bluhm <[email protected]> wrote:

> On Thu, Mar 02, 2017 at 06:08:45PM -0300, Gleydson Soares wrote:
> > Yes, it's using libtls and evbuffer_tls(came from syslogd).
> 
> I have copied it from libevent and adapted it to tls.
> 
> > I did some tests and I think this hangs with jpeg >=4k and <=15k,
> > other image sizes not triggers the issue.
> > ..weird
> 
> libevent uses 4k read blocks and libssl 16k blocks internally.
> This is at least inefficent and I guess could lead to hangs.
> 
> Could you test this diff?
> 

The issue still shows up, but more erratically: When you can't ldapadd
with a certain image size it may well work when you try a second time
(at least for small size; see below).

First, when using ldap instead of ldaps all image sizes up to at least
70000 bytes succeed (that is the maximum size I tested).

When using ldaps it hangs at different image sizes.  I had hangs at:
4339, 4603, 3600, 3179, 3414, 3700, and 5239 byte-sized images using the
script attached, using the default values.

When trying image sizes from upwards down, e.g.:
  FIRST_IMAGE_SIZE=48750 LAST_IMAGE_SIZE=10000 DEBUG= ./test2.sh

(test script attached)

I found there seems to be a boundary 16384*n - 409 and less for 16K
sizes where ldapadd may fail:

size 16500 and lower had failures at image sizes of:
- 15974
- 15975 (almost always 15975)

size 33000 and lower (I lowered the upper limit after the first couple
of times):
- 32358
- 32359 (almost always 32358)

size 49152 and lower:
- 48743 (thrice)
- 48742 (twice)
- 48733 (once)
- 48742 (once)

size 65536 and lower (order of appearance):
- 65126
- 65121
- 65126
- 65127
- 65117
- 65124
- 65112
- 65117
- 65122
- 65124
- 65119
- 65125
- 65126
- 65116
- 65117


I also checked sizes around 8K; failures above and below (8163,
8297, 8187) with a command line of

FIRST_IMAGE_SIZE=8200 LAST_IMAGE_SIZE=1 DEBUG= ./test2.sh


ldapadd trace always shows a repeated output of
--- snip ---
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 100) = 0 (Timeout)
--- snip ---

or, with debugging enabled:

--- snip ---
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 100) = 0 (Timeout)
write(2, "ldap_result ld 0x563bac634770 ms"..., 38) = 38
write(2, "wait4msg ld 0x563bac634770 msgid"..., 57) = 57
write(2, "wait4msg continue ld 0x563bac634"..., 50) = 50
write(2, "** ld 0x563bac634770 Connections"..., 34) = 34
write(2, "* host: r310  port: 636  (defaul"..., 35) = 35
write(2, "  refcnt: 2  status: Connected\n", 31) = 31
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(2, "  last used: Fri Mar  3 08:26:00"..., 39) = 39
write(2, "\n", 1)                       = 1
write(2, "** ld 0x563bac634770 Outstanding"..., 43) = 43
write(2, " * msgid 2,  origid 2, status In"..., 41) = 41
write(2, "   outstanding referrals 0, pare"..., 43) = 43
write(2, "  ld 0x563bac634770 request coun"..., 50) = 50
write(2, "** ld 0x563bac634770 Response Qu"..., 37) = 37
write(2, "   Empty\n", 9)               = 9
write(2, "  ld 0x563bac634770 response cou"..., 37) = 37
write(2, "ldap_chkResponseList ld 0x563bac"..., 53) = 53
write(2, "ldap_chkResponseList returns ld "..., 52) = 52
write(2, "ldap_int_select\n", 16)       = 16
poll([{fd=4, events=POLLIN|POLLPRI}], 1, 100^CProcess 22140 detached
--- snip ---

Best regards
Robert



> bluhm
> 
> Index: usr.sbin/ldapd/evbuffer_tls.c
> ===================================================================
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/ldapd/evbuffer_tls.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 evbuffer_tls.c
> --- usr.sbin/ldapd/evbuffer_tls.c     1 May 2016 00:32:37
> -0000 1.1 +++ usr.sbin/ldapd/evbuffer_tls.c   2 Mar 2017
> 21:36:35 -0000 @@ -289,7 +289,7 @@ buffertls_connect(struct buffertls
> *buft
>   * Reads data from a file descriptor into a buffer.
>   */
>  
> -#define EVBUFFER_MAX_READ    4096
> +#define EVBUFFER_MAX_READ    16384
>  
>  int
>  evtls_read(struct evbuffer *buf, int fd, int howmuch, struct tls
> *ctx)
> 

Attachment: test2.sh
Description: application/shellscript

Reply via email to