Clientaddr .doesn't change agent addr varbind in trap PDU

Hi...I've encountered a situation, and before I go on too long, let me say I have a mod I've made to the agent_trap module here to fix it, and I'm more than happy to provide that "fix" (such as it is).

Leaving alone the operationally suboptimal aspects of using V1 TRAPs, we have a situation where we have traps being issued from managed elements which are multihomed, both externally and with respect to an internal loopback network configured on them. We need to "pin" the issuing addr so that it reflects the address which will properly reverse-DNS-map back at the trap display console at the management headend.

So, I noticed that some time ago, a similar issue was supposedly addressed by directing (s)he who had that issue to use the "[snmp] clientaddr ww.xx.yy.zz" config line in the snmpd.conf.

This works to change the source address on the *UDP packet* with the TRAP PDU payload. Problem is, there's a varbind for the agent addr in a V1 PDU, and *that's* what we need to change. In fact, making the change to the UDP source addr *breaks* our deployment because it changes the origin address on proxied GET requests, which is causing havoc with proxy targets which are tightly wrapped to only accept requests from the localhost address.

This is apparent if you look around line 774 of agent_trap.c--this varbind is unconditionally set to the results of get_myaddr().

This would also be a problem for *anybody* trying to issue traps out of a RFC1918 private address space across a NAT gateway. While external baggage would have to be around to figure out what the address *should* be in the PDU (some sort of custom package install param, for example), you can see where the results of get_myaddr() aren't going to be appropriate for in-PDU embeddeding beyond the NAT perimeter. (this is the classic "middlebox" problem for application protocols with local host addresses in their payload).

To address this, I actually added a new config parameter: 'agentrapaddr', which is *only* used for assignment of this address. Point is, I didn't change the address for the packet itself (the effect of "clientaddr"), only that for the varbind internally. If *that* is found--the associated datastore item--when the TRAP PDU is being assembled and v1-ified here, I attempt to do a map of the address in case it was specified as a DNS address (using a new system function 'get_thisAddr()' which is the analog for "get_myAddr()"), get the IP addr that way, and use get_myAddr() if that fails or there was no trapagentaddr defined in snmpd.conf.

This approach is submitted for your approval, and I'd be happy to submit my sources, with their changes as obvious as you might expect, for integration into the 5.4 trunk if you like. Please advise as to process there if so (e.g., issuing a formal bug report with the diff listing as a part of the commentary?). I'm totally cool with modifying my approach to meet the review and best practices for these techniques in the SNMP agent code if I missed it, so long as the effect I'm after can be achieved.

Thanks!
Wayne Tackabury
Mirror Image Internet


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users