In some captures we might have already established and BOUND LDAP

session where GSS-SPNEGO is used.
If we havent seen the BIND call ethereal would assume it is
vanilla non-GSS-SPNEGO LDAP and would fail to decode the packet.

Add heuristics to the LDAP dissector so that
IF the first 4 bytes of the LDAP PDU looks like ity could be a length field
and IF the fifth byte has the value 0x60
then assume what we have is GSS-SPNEGO and assume this and all further commands on this session is GSS-SPNEGO as well.

svn path=/trunk/; revision=8904
This commit is contained in:
Ronnie Sahlberg 2003-11-07 04:03:44 +00:00
parent c4ffda6028
commit 7b14d3a754
1 changed files with 16 additions and 1 deletions

View File

@ -3,7 +3,7 @@
*
* See RFC 1777 (LDAP v2), RFC 2251 (LDAP v3), and RFC 2222 (SASL).
*
* $Id: packet-ldap.c,v 1.67 2003/11/06 09:18:46 sahlberg Exp $
* $Id: packet-ldap.c,v 1.68 2003/11/07 04:03:44 sahlberg Exp $
*
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com>
@ -2079,6 +2079,21 @@ dissect_ldap(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
}
}
/* It might still be a packet containing a SASL security layer
* but its just that we never saw the BIND packet.
* check if it looks like it could be a SASL blob here
* and in that case just assume it is GSS-SPNEGO
*/
if( ((tvb_get_ntohl(tvb, offset)+4)<=tvb_reported_length_remaining(tvb, offset))
&&(tvb_get_guint8(tvb, offset+4)==0x60) ){
ldap_info->auth_type=LDAP_AUTH_SASL;
ldap_info->first_auth_frame=pinfo->fd->num;
ldap_info->auth_mech=g_strdup("GSS-SPNEGO");
doing_sasl_security=TRUE;
continue;
}
/*
* OK, try to read the "Sequence Of" header; this gets the total
* length of the LDAP message.