Unexpected consequences of setting clientaddr in snmp.conf

[Paul Thornton]

Hi all,

I've been a long-time user of Net-SNMP, and have just moved a load of
our monitoring scripts from one server running version 5.4.2.1 to a
newer one running 5.5.4. I'm doing all SNMP over v4 UDP.

The snmp.conf files on both machines are the same, and contain a
"clientaddr" directive.

The effect of setting clientaddr seems to have changed between these two
versions. Not only does it set the source IP address of the packet, it
also sets the source port to 161 (or whatever you have set in
defaultport in snmp.conf).

Of course, this has two undesirable side effects:
- You can't run snmpd on port 161 on the server that is doing the polling.
- You have to run any polling process as root so it can bind to local
port 161.

I have had a quick look at snmpUDPDomain.c differences between these two
versions; the line that seems to have changed is in
netsnmp_udp_transport() - line 674 of the 5.4.2.1 source is:
client_addr.sin_port = 0

This is removed in the 5.5.4 source. As I expected, putting it back in
resolves the problem as a high-numbered source port is chosen instead.

I don't know what the reasons for the change were, but I think this is a
bug that wants to be fixed; I've not looked in TCP or v6 transports but
it may be present there too.

Regards,

Paul.

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

[andrew....@gmail.com]

As an FYI to anyone whose access to Net-SNMP is limited to one that exhibits this problem, I found that one can work around this by explicitly appending a port of "0" to the clientaddr's hostname in the snmp.conf file. My motivation came directly from Paul Thornton's description of a working patch.

For example:

<pre><code> clientaddr 192.168.1.1:0</code></pre>

The ":0" should cause the client to choose an open port from from the ephemeral port range much the same way the patch did the same thing.

--------
regards,
Andrew Helsley