[asterisk-bugs] [Asterisk 0015895]: When useragent was added to realtime_update_peer in chan_sip the necessary ldap changes were not made

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Sep 15 09:25:43 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15895 
====================================================================== 
Reported By:                jcovert
Assigned To:                suretec
====================================================================== 
Project:                    Asterisk
Issue ID:                   15895
Category:                   Resources/res_config_ldap
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1.6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-09-14 18:39 CDT
Last Modified:              2009-09-15 09:25 CDT
====================================================================== 
Summary:                    When useragent was added to realtime_update_peer in
chan_sip the necessary ldap changes were not made
Description: 
When useragent was added to realtime_update_peer in chan_sip the necessary
ldap changes were not made

The call to realtime_update_peer was modified in chan_sip to store
'useragent' This causes constant error messages:

  [Sep 14 14:34:27] ERROR[30323]: res_config_ldap.c:1286 update_ldap:
Couldn't modify dn:uid=johncovert.test,ou=people,dc=onstate,dc=net because
Undefined attribute type

This problem last happened when "lastms" was added.  See issue
https://issues.asterisk.org/view.php?id=15156.

Whenever a new item is added to realtime, it is necessary to update the
ldap definitions to support it. I propose making the following changes
required to eliminate this error:

1. Modify contrib/scripts/asterisk.ldap-schema as follows:

a. update version number and list this bug number in the changes.
b. Add objectIdentifier AstAccountUserAgent AstAttrType:59
c. Add
  attributetype ( AstAccountUserAgent
    NAME 'AstAccountUserAgent'
    DESC 'Ast Account User Agent'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
d. Add AstAccountUserAgent to objectclass AsteriskSIPUser and for
completeness to objectclass AsteriskIAXUser even though not yet used.

2. Modify configs/res_ldap.conf.sample to include
     useragent = AstAccountUserAgent
  in the Sip Users Table

3. This time also modify chan_sip.c to refer future developers to the need
to update these two files whenever adding new realtime updates.

I expect to submit patches within the next two or three days once I have
actually tested this; I cannot do this while production is running today.

Regards/john
====================================================================== 

---------------------------------------------------------------------- 
 (0110654) jcovert (reporter) - 2009-09-15 09:25
 https://issues.asterisk.org/view.php?id=15895#c110654 
---------------------------------------------------------------------- 
While working on this, I started to put in the following comment:

        /* The following line of code is troubling.  I'm not changing it
yet, but I believe that it is incorrect.  mod_values is an array of
pointers to values (ldap supports attributes with multiple values).  See
ldap.h.  But we're allocating 2 x sizeof(char) when we should be allocating
1 x sizeof(char **).  We then put a pointer into this 2 x sizeof(char)
space, and the only reason it doesn't blow up nastily is that ast_calloc
gets chunks big enough that it doesn't matter. JRC. */

But after writing it up, I convinced myself that I need to make the change
now.  It shouldn't change anything about what happens in execution (at
least with the current allocation scheme in ast_calloc on current hardware
architectures) but it's such an awful piece of code it needs to be fixed. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-15 09:25 jcovert        Note Added: 0110654                          
======================================================================




More information about the asterisk-bugs mailing list