SNMP Binding - Not Getting Data From Target

knebb · May 25, 2020, 6:18am

Hi,

well, I went to increase debug level according to documentation. Which is itself really troublesome. Simply setting log level to DEBUG does no seem to be possible. Instead I had to use the Karaf console. And set the loglevel. I hope I did it in the right way (as I was just using the provided example):
log:set TRACE org.openhab.binding.snmp
(Just a side note: after this command I was not able to leave the consoel by exit, I had to kill the ssh connection.)
I restarted the binding (sufficient? or full oepnhab restart needed?):
ssh openhab@localhost -p8101 'bundle:restart org.openhab.binding.snmp'

Looks like I have been successful so far:

root@openhab:~# ssh openhab@localhost -p8101 'log:get org.openhab.binding.snmp'
Password authentication
Password:
TRACE

Now when checking openhab.log there is no difference in logging:

2020-05-25 08:02:36.464 [WARN ] [inding.snmp.internal.SnmpServiceImpl] - could not open SNMP instance on port 162: Keine Berechtigung (Bind failed)
2020-05-25 08:02:36.491 [WARN ] [inding.snmp.internal.SnmpServiceImpl] - could not open SNMP instance on port 162: Keine Berechtigung (Bind failed)
2020-05-25 08:02:36.580 [WARN ] [inding.snmp.internal.SnmpServiceImpl] - SNMP service not initialized, can't send GET[requestID=0, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.31.1.1.1.6.2 = Null]] to CommunityTarget[address=192.168.22.254/161,version=1,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=1234,preferredTransports=null]
2020-05-25 08:02:36.592 [WARN ] [inding.snmp.internal.SnmpServiceImpl] - SNMP service not initialized, can't send GET[requestID=0, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.31.1.1.1.6.2 = Null]] to CommunityTarget[address=192.168.22.254/161,version=1,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=1234,preferredTransports=null]

In eventlog I see some further details but the do not tell me anything either:

2020-05-25 08:00:00.935 [hingStatusInfoChangedEvent] - 'snmp:target:router' changed from ONLINE to UNINITIALIZED
2020-05-25 08:00:01.009 [hingStatusInfoChangedEvent] - 'snmp:target:router' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2020-05-25 08:00:01.387 [hingStatusInfoChangedEvent] - 'snmp:target:router' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2020-05-25 08:00:01.435 [hingStatusInfoChangedEvent] - 'snmp:target:router' changed from INITIALIZING to UNKNOWN
2020-05-25 08:00:01.442 [hingStatusInfoChangedEvent] - 'snmp:target:router' changed from UNKNOWN to ONLINE

As I was unsure about my logging I restarted the system completely. And no change, still the same error, still no further details.

Thanks for your patience but I am close to give up. Or are there any further ideas?

/KNEBB

anonymous.one · May 25, 2020, 2:06pm

Well that is disappointing to see the increase of the logging didn’t provide any insights.

I did however copy over your Thing/Item definitions into my environment and after changing the IP/community string my OH doesn’t exhibit the same behaviour but the value is left at 0 vs the value I see when I perform a snmp walk. Looks like I am running OH 2.5.5.

Some things I thought of to test out:
When was the last full restart of OH?
Last restart of the OS?
It could be possible the snmp binding didn’t download into OH correctly, a uninstall of the binding and a reinstall may fix the issue?
Try a string value of your device, like the hostname to see if that provides a better result?

Also out of curiosity what kind of router is hosting this SNMP? This seems like a rule/ACL blocking the SNMP, but it should also refuse your snmpwalk from the same device running OH.

knebb · May 25, 2020, 7:31pm

Did a full restart of OS (including OH of course) twice these days. Using 2.5.5-1 currently:

root@openhab:~# dpkg -l| grep openhab
ii  openhab2                              2.5.5-1                             all          openhab2

I will try to install the binding again and see if it changes as well as using a string instead- I will keep you guys updated.

[Update]
Removing the snmp binding through paperUI and reinstalling it had exactly… NO… effect on the symptoms.

However, guys, thanks for you patience. For some reason this binding is somehow … difficult. I might need to give up on it…

/KNEBB

knebb · May 25, 2020, 7:36pm

Might be @J-N-K might have a hint about my issue?

knebb · May 25, 2020, 7:48pm

Just to make sure it is not related to the (unneeded( bind port 161 I changed it.

Well, attaching to the port (>1024) works now and I do not get any errors!
Damn! Was it soooo easy?

2020-05-25 21:45:21.555 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - initialized SNMP at 0.0.0.0/1162
2020-05-25 21:46:21.361 [TRACE] [inding.snmp.internal.SnmpServiceImpl] - send GET[requestID=778318719, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.31.1.1.1.6.2 = Null]] to CommunityTarget[address=192.168.22.254/161,version=1,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=1234,preferredTransports=null]
2020-05-25 21:46:21.412 [TRACE] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:router received RESPONSE[requestID=778318719, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.31.1.1.1.6.2 = 77994]]

knebb · May 25, 2020, 7:58pm

Ok, that’s it!

The snmp binding complains about the 162 port which is not needed in my environment.

But it looks like it has to be initialized as mandantory.

So I changed the binding configuration to a port above 1024 in PaperUI. Since then it simply worked!

This was the error message I ignored but which was important:

2020-05-25 08:02:36.491 [WARN ] [inding.snmp.internal.SnmpServiceImpl] - could not open SNMP instance on port 162: Keine Berechtigung (Bind failed)

Now my binding is listening (for nothing) on port 1162 and the rest seems to work really nice!

THANKS to ALL (@anonymous.one and @rossko57 @Andrew_Rowe ) who tried to help, I learned really a lot!

/KNEBB

J-N-K · May 25, 2020, 8:01pm

Mhm. I‘ll check if we can find a better way.

anonymous.one · May 26, 2020, 3:11am

Glad you stuck with it and didn’t give up!

And what is odd, I looked back at the 1.x binding that I have running concurrently with the 2.x binding and have this in my service file:

# Listening Port (optional, defaults to '162')
port=1620

Which could be why I was not able to replicate your issue, I also don’t use traps to OH from the network devices and just set that to avoid logs being generated on the system and just continued to port the file over the years of using OH.