History | Log In     View a printable version of the current page.  
HQ 4.0 EE Release is Now Available | HQ 3.2.5-EE Maintenance Release is Now Available
Issue Details (XML | Word | Printable)

Key: HHQ-1025
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Doug MacEachern
Reporter: Chip Witt
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Hyperic HQ

Updated snmp4j.jar has broken agent SNMP trap receiver

Created: 08/Aug/07 03:08 PM   Updated: 18/Dec/07 10:08 AM
Component/s: Agent
Affects Version/s: 3.1.0, 3.0.5
Fix Version/s: 3.1.1, 3.1.4

Environment: Agent SNMP trap receiver. Last know to work in 3.0.3. Fails in 3.0.5 and 3.1.0 (since snmp4j.jar update).

Verify By: Chip Witt
3.0 Category: Agent
Last comment: 51 weeks, 1 day ago
Resolution Date: 29/Nov/07 07:05 AM


 Description  « Hide
_3.0.3-EE_Config_Check_Info_

agent.properties has the following:

snmpTrapReceiver.listenAddress=udp:0.0.0.0/1620

Running an `netstat -nau | grep 1620` yields:

udp 0 0 0.0.0.0:1620 0.0.0.0:*

With DEBUG logging, I get the following entry upon start-up of the agent:

2007-08-06 20:58:05,904 DEBUG [SNMPTrapReceiver] Listen address=udp:0.0.0.0/1620

_3.0.5-EE_On_

Same agent.properties entry, yet no expected output from netstat, and no errors in agent.log (even with DEBUG turned on). Bottom-line, no workie.


 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Doug MacEachern - 10/Aug/07 02:56 PM
Working as expected now, can't reproduce with 3.1.1 #444
Assigning to Chip to reproduce.

Chip Witt - 15/Oct/07 06:31 PM
Verified fixed in 3.1.1 GA.

Chip Witt - 13/Nov/07 07:42 AM
This was erroneously closed...I had tested against an earlier 3.1.0 build, not 3.1.1.

I cannot get the trap receiver port to open on my 3.1.1-EE-490 test box, even with the earlier fix of using the 3.0.3 version of snmp4j.jar.

John Sachs - 14/Nov/07 12:51 PM
Assign to Doug to investigate.

Chip Witt - 29/Nov/07 07:05 AM
This issue was indeed resolved. Re-verified as fixed in 3.1.1 and 3.1.4. Verification (and continued test) requires not only setting the appropriate property in the agent.properties file, but also following through with the creation of a net device against that agent, and turning on log tracking for that net device platform. Only then does the port specified in the configuration get opened.