On Jan 19, 2012, at 15:16, Chris Ridd <chrisr...@mac.com> wrote:
> > On 19 Jan 2012, at 14:05, Chris Ridd wrote: > >> >> On 19 Jan 2012, at 14:00, John Devitofranceschi wrote: >> >>> >>> >>> On Jan 19, 2012, at 8:21, Chris Ridd <chrisr...@mac.com> wrote: >>> >>>> >>>> On 19 Jan 2012, at 12:39, John Devitofranceschi wrote: >>>> >>>>> Two bugs! Such a deal! >>>> >>>> No extra charge :-) >>>> >>>>> Yes, the cookie setting code is in the while (1) loop and the callback >>>>> merely prints out the dn of the returned entries. >>>> >>>> You mentioned that the OpenLDAP ldapsearch command-line tool seemed to >>>> work. Can you double-check it is getting multiple pages back (try using >>>> pr=2/prompt), or whether it is stopping after the first page because of >>>> the misplaced result cookie? >>> >>> OpenLDAP's ldapsearch works as expected. Multiple pages get returned. >> >> That's puzzling, and suggests my analysis is wrong. Can you get some >> (snoop/tcpdump) packet traces from ldapsearch and perl up to and including >> the first page search done? It'll have passwords and your data in so if you >> want to send them off-list that's fine. > > Just to follow up on-list - the snoops that John sent me both showed that > Oracle consistently sends the paged results control in the wrong place. > Wireshark also complained. > > Unless Oracle's shipping a version of ldapsearch that reads the control from > the wrong place and counteracts their server bug, I'm puzzled how John's > ldapsearch works. > > Chris Actually, that ldapsearch is from Openldap on Redhat Linux.
