snmpwalk is working, but cacti no

[LeonM]

I have done a tunnel from windows (using PsExec and plink) to linux server on localhost on port 9090. I'm using on windows the net-snmp suite.

If i make a request in linux using the snmpwalk like this

Code: Select all

# snmpwalk -v 1 -c public tcp:127.0.0.1:9090 | grep plink.exe

HOST-RESOURCES-MIB::hrSWRunName.1304 = STRING: "plink.exe"

is working...


In cacti interface when i put like in a tutorial from how to page




it's there some settings that i must do to accept the hostname field the tcp:ip:port ?

Thank you


LATER: if is hekping i have this config on linux

Date Mon, 23 Sep 2013 14:30:58 +0200
Cacti Version 0.8.7i
Cacti OS unix
SNMP Version NET-SNMP version: 5.4.3
RRDTool Version RRDTool 1.4.x

[paulgevers]

Increasing the debugging level and looking in the log files probably tells you what is going wrong.

[gandalf]

It may happen, that the php snmp function we use for the web service do not like the tcp:xxx.xxx.xxx.xxx:9090 notation. Never checked that. Do other hosts have a similar problem?
R.

[tylerc]

Is there a reason you need to use TCP for SNMP? SNMP is usually delivered over UDP for a variety of reasons, the most important being that this is what the RFC specifies. Therefore, many applications (and possibly Cacti, in this case) are guaranteed to understand and use UDP port 161/162 as long as they are standards-compliant. Altering the port numbers offers no advantage as UDP 161/162 are in the well-known ports range and defined by an RFC (thus no other applications should be using those ports). If you are changing them for "security" reasons, then this is merely security through obscurity (which is not really security). A better security approach is to implement only SNMPv3 and implement access lists for all SNMP-aware devices, including the collector/NMS.

The port numbers can typically be changed in most instances; the transport protocol can also be changed in fewer instances. Because Cacti works on UDP ports 161/162, it is RFC-compliant. To force Cacti to listen and/or connect to other ports or transport protocols would cause it to work outside of the RFC.

Additionally, SNMP doesn't really like being tunneled or port translated or anything like that. If you can avoid tunneling your SNMP traffic, that would be better.

In other words:

• Maintain RFC compliance
  • Use UDP
  • Use ports 161/162
• Implement better security policies
  • SNMPv3
  • Access control lists
• Don't do crazy things (like tunneling SNMP)

If the above things are impossible, you may need to look at the PHP code and PHP's implementation of SNMP. You can probably hack it to suit your needs until a more extensible solution is offered by the Cacti developers in a future release/patch.

[LeonM]

Sorry for the late reply, but i have been gone in a long trip.

The reason i want to do this, is because it seem the only solution to resolve the distance.

Practically the basic example is:

(Linux Cacti Server)---(LAN)---(Windows SNMP Client)

And what i try to achieve is:

(Windows SNMP Client)--(modem/Firewall)---(Internet)---(Firewall)---(Linux Cacti Server)---(LAN)---(Windows SNMP Client)

Linux Cacti Server, is a Ubuntu 12.04 LTS, and it keeps the records of his own SNMP client, the clients in the local network, and now must keep the track of all the Windows SNMP Clients outside the network in WAN. For the WAN because of the firewalls and the dynamic ip's a tunnel it's a must

If anyone has a better idea to achieve this, it will be greatly appreciated.

[Sven10000]

Hello,

Gandalf ask: "Do other hosts have a similar problem?"

Yes, I've the same problem and I can't resolve this with an other environment or changing the Networkdesign
I need a solution - please and thank you

Greetings Sven