cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
444
Views
0
Helpful
1
Replies

UCCX 7.0 Release Notes - Question

Steven Griffin
Level 4
Level 4

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

Michael Owuor
Cisco Employee
Cisco Employee

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.

View solution in original post

1 Reply 1

Michael Owuor
Cisco Employee
Cisco Employee

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: