Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

UCCX 7.0 Release Notes - Question

All,

The UCCX 7 release notes has the following item listed under Important Notes:

SNMP Service Crashes-Ensure that the size of triggers that are created and associated with a single application in the Unified CCX does not exceed 255 bytes. If more triggers are created and associated with an application, the SNMP service on Windows will crash and will not start subsequently in Unified CCX 7.0(1).

Can anyone explain this in more detail?

In order for this statement to make any sense one would need to know how many bytes a single trigger takes in the first place.

Please help us make the communities better. Rate helpful posts!
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: UCCX 7.0 Release Notes - Question

Hi Steven

This note is related to CSCsr91804 - SNMP process terminates on CRS server. This defect has the following release notes:

Symptom:

The SNMP Service does not respond to the SNMP queries. The SNMP Service may have crashed and subsequently does not start again.

Conditions:

The SNMP Service on Windows crashes and does not start subsequently in UCCX 7.0(1), when the user creates and associates a lot of triggers with an application.

Workaround:

The User of the application should ensure that the size of triggers that are created and associated with a single application in the UCCX should not exceed 255 bytes.

UCCX 7.0(1)SR1 includes a fix for this issue.

Further Problem Description:

Currently the logging API used in the SNMP defines the maximum size of a log message to be 255 bytes, and if it tries to write beyond that, the SNMP service crashes. This includes any text included as part of the log message.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsr91804

Here's the Q and A based on your post, posed to the developer who worked on CSCsr91804:

Q:

Regarding CSCsr91804 - is there a way to tell how many bytes a single trigger take in the first place? In other words, without the fix for this defect, how can someone proactively avoid running into it?

A:

Actually, the SNMP Crash was happening due to the buffer overflow caused by some Microsoft specific deprecated logging API which is now replaced by a new one which has more error handling and is less vulnerable. This was fixed as part of CSCsr91804.

Coming to your question, we do not have a way to tell how many bytes a trigger takes since it can change according to the triggers defined. But one can always assume that the size of the trigger is the number of characters used to define the triggers plus the number of characters used as separator for forming the triggers string (assuming that a byte is a single character, Unicode not supported)

Let me know if you need any further clarification.

Regards,

Michael.

1 REPLY
Cisco Employee

Re: UCCX 7.0 Release Notes - Question

Hi Steven

This note is related to CSCsr91804 - SNMP process terminates on CRS server. This defect has the following release notes:

Symptom:

The SNMP Service does not respond to the SNMP queries. The SNMP Service may have crashed and subsequently does not start again.

Conditions:

The SNMP Service on Windows crashes and does not start subsequently in UCCX 7.0(1), when the user creates and associates a lot of triggers with an application.

Workaround:

The User of the application should ensure that the size of triggers that are created and associated with a single application in the UCCX should not exceed 255 bytes.

UCCX 7.0(1)SR1 includes a fix for this issue.

Further Problem Description:

Currently the logging API used in the SNMP defines the maximum size of a log message to be 255 bytes, and if it tries to write beyond that, the SNMP service crashes. This includes any text included as part of the log message.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsr91804

Here's the Q and A based on your post, posed to the developer who worked on CSCsr91804:

Q:

Regarding CSCsr91804 - is there a way to tell how many bytes a single trigger take in the first place? In other words, without the fix for this defect, how can someone proactively avoid running into it?

A:

Actually, the SNMP Crash was happening due to the buffer overflow caused by some Microsoft specific deprecated logging API which is now replaced by a new one which has more error handling and is less vulnerable. This was fixed as part of CSCsr91804.

Coming to your question, we do not have a way to tell how many bytes a trigger takes since it can change according to the triggers defined. But one can always assume that the size of the trigger is the number of characters used to define the triggers plus the number of characters used as separator for forming the triggers string (assuming that a byte is a single character, Unicode not supported)

Let me know if you need any further clarification.

Regards,

Michael.

269
Views
0
Helpful
1
Replies
CreatePlease to create content