[ NemesisRD 1.x ] LDAP: Core durante recepcion de Done OK tras un entry mal codificado

[Eduardo Ramos Testillano]

Hola

El core es debido a un abort() en openLdap (ldap_get_attribute_ber ):

Session::receiveEntry:
..
  while (ldap_get_attribute_ber (handle, hmessage, ber, &name, &values) == LDAP_SUCCESS) {
 441       if (name.bv_val == NULL)                            // (1)
 442          break;


Estas son las ultimas trazas del conectorLDAP:

[11/05/2010 10:15:17] Debug | ldap.Session.cc (0) | ldap::Session::apply | end
[11/05/2010 10:15:21] Debug | ldap.Session.cc (224) | ldap::Session::apply | begin
[11/05/2010 10:15:21] Debug | ldap.Session.cc (423) | ldap::Session::receiveEntry | ldap::Response { ClassCode: Search | IdMessage: 2 | ldap::ResultCode { Value: 0 } }
[11/05/2010 10:15:21] Debug | ldap.Session.cc (438) | ldap::Session::receiveEntry | DN:



¿el abort() se debe a un assert que no podemos evitar?

--

--
Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.

[Eduardo Ramos Testillano]

Escenario:

1) Bind & BindResponseOK
2) Search OK
3) Recepcion de ResultEntry mal codificada:
30 59 02 01 02 64 54 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
4) Recepcion de ResultDone OK
30 0C 02 01 02 65 07 0A 01 00 04 00 04 00

Te adjunto la salida de nivel de depuracion de openLdap, mezclado con trazas a nivel notice, a partir del envio del punto 2).
Como se ve, efectivamente hay un abort() de openLdap:

../../../libraries/libldap/getattr.c:151: ldap_get_attribute_ber: Assertion `ber != ((void *)0)' failed.

Así que no parece una situación controlable.

Sólo me queda la duda, de si sería posible llevar un control en tu recubrimiento, de la "salud" de los receiveEntry previos al resultDone.
La idea sería evitar la invocacion a 'ldap_get_attribute_ber' dentro del Session::receiveEntry, cuando algún entry previo estaba mal codificado.
El problema es que creo que para relacionarlos haría falta el msgId !

un saludo

[Cisco]

Hola.

Habría que ver si la librería de OpenLDAP detecta/informa de alguna
forma cuando está en el punto 3.

Las trazas y demás deben ir en texto plano o en texto comprimido.

Un saludo.


P.D: Bueno, espero que no os dé por enviar datos mal codificados para
la librería de Oracle .... porque nos llevaríamos más de una
sorpresa. ;-)

On May 11, 2:17 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Escenario:
> 1) Bind & BindResponseOK
> 2) Search OK
> 3) Recepcion de ResultEntry mal codificada:30 59 02 01 02 64 54 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

> 4) Recepcion de ResultDone OK30 0C 02 01 02 65 07 0A 01 00 04 00 04 00

> Te adjunto la salida de nivel de depuracion de openLdap, mezclado con trazas a nivel notice, a partir del envio del punto 2).
> Como se ve, efectivamente hay un abort() de openLdap:

> ...
>
> read more »
>
>  image_jpeg_part
> 8KViewDownload
>
>  firma.jpg
> 8KViewDownload
>
>  trazasNoticeYOpenLdapDebug.rtf
> 8KViewDownload

[Eduardo Ramos Testillano]

He visto que quiza se pueda hacer algo:

Al invocar al:

while (ldap_get_attribute_ber (handle, hmessage, ber, &name, &values) == LDAP_SUCCESS) {

el 'ber' obtenido previamente con 'ldap_get_dn_ber' es NULL.
Bastaría hacer la comprobacion para evitar caer en el agujero del abort() de openLdap.
Echale un vistazo y reproduzco la prueba a ver si se soluciona.

un saludo

--

[Cisco]

Hola.

El parche NemesisRD.ldap 1.11.16 debería solucionar el problema.

Referencia: http://groups.google.com/group/nemesisrd-1x/browse_frm/thread/3a4a223141348b36#

On May 11, 12:47 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola
> El core es debido a un abort() en openLdap (ldap_get_attribute_ber ):
> Session::receiveEntry:
> ..
>   while (ldap_get_attribute_ber (handle, hmessage, ber, &name, &values) == LDAP_SUCCESS) {
>  441       if (name.bv_val == NULL)                            // (1)
>  442          break;
> Estas son las ultimas trazas del conectorLDAP:
> [11/05/2010 10:15:17] Debug | ldap.Session.cc (0) | ldap::Session::apply | end
> [11/05/2010 10:15:21] Debug | ldap.Session.cc (224) | ldap::Session::apply | begin
> [11/05/2010 10:15:21] Debug | ldap.Session.cc (423) | ldap::Session::receiveEntry | ldap::Response { ClassCode: Search | IdMessage: 2 | ldap::ResultCode { Value: 0 } }
> [11/05/2010 10:15:21] Debug | ldap.Session.cc (438) | ldap::Session::receiveEntry | DN:
> ¿el abort() se debe a un assert que no podemos evitar?--
>
>
>

> --
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>

>  image_jpeg_part
> 8KViewDownload