Source Address of agent-originated trap (again)

Hi Thomas/Wes/all:

I submitted this as a comment last May (7th).  Since then, I've been getting some requests for the updates we made to code here, and I've been tracking a few bugs which *may* have addressed this behavior (but I don't think so).  Here goes again--if you want me to follow up on it (or shut up about it), just say the word.

In 5.4, we were having trouble getting proper local addressing (agent-local) of outgoing coldstart and resource monitoring V1 traps.  From the private responses I got to my mail, so were a number of other folks.

There are two issues here.  

One is simply getting the "clientaddr" directive (in the snmp.conf *for the agent's sent trap PDU*) to "take" on multihomed systems.  I think we made the same changes here that you made in patch #1775124.  However, if I get the gist of that patch, it will only affect the transport binding and, in essence, source address of the UDP packet itself.

There is also the matter of getting any agent address varbinds in the v1 trap PDU itself to be properly set.  I convinced myself that it would be overloading the intent of clientaddr to use the same parameter for this purpose.  I could see situations (e.g., firewall traversal) where one might want to set what's in the PDU payload, but not change the interface bindings or resulting UDP source addresses (or, indeed, not in general want to affect the clientaddr of real SNMP client applications running on the same agent system just to address this issue).

To this end, I implemented my own snmpd.conf directive ("agenttrapaddr"), which specifies a value to *only* set the in-PDU varbind value for this.  If it's specified as a DNS name, I do the lookup at each point of trap generation, etc.

I'd be happy to submit this as a patch, and given the slightest provocation, I will. Just wanted to make sure this didn't collide with other intent on the part of you folks maintaining the code.  I found a number of reports of this general situation over the years in the net-snmp archives, and wanted to make sure there wasn't some other way you intended to deal with this than yet-another-cheesy-snmpd-directive.

Thanks!
Wayne Tackabury
Mirror Image Internet

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users