Snmp seems not to work as expected

Scriptwriter · July 21, 2024, 9:28am

im used long time the snmp binding for getting/setting values on my switch. But since the update to oh 4.2.0 (docker installation) i have problems to do that. Other bindings are working fine.
error:

2024-07-21 11:19:23.997 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
2024-07-21 11:19:25.499 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=593742335, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null]] and got error: Invalid argument

this i have seen too:

2024-07-21 13:46:24.741 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
org.snmp4j.MessageException: Invalid argument
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:655) ~[?:?]
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.net.SocketException: Invalid argument
	at sun.nio.ch.DatagramChannelImpl.send0(Native Method) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853) ~[?:?]
	at sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218) ~[?:?]
	at java.net.DatagramSocket.send(DatagramSocket.java:664) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:128) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:46) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:270) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:632) ~[?:?]
	... 11 more

config for one of the identical cahannels:

UID: snmp:target:a9df1fc2
label: POE_Switch
thingTypeUID: snmp:target
configuration:
  retries: 2
  hostname: 192.168.2.250
  protocol: v2c
  port: 161
  refresh: 60
  community: icannottellyou
  timeout: 1500
location: Keller
channels:
  - id: accesspoint1
    channelTypeUID: snmp:switch
    label: accesspoint1
    configuration:
      mode: READ
      offvalue: "2"
      oid: .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
      datatype: INT32
      onvalue: "1"

here the command which i can do manual:

snmpwalk -v2c -c icannottellyou 192.168.2.250 .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
iso.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = INTEGER: 1

could you give me a hint please, what i have to change that it is running under 4.2.0 as before?

J-N-K · July 21, 2024, 6:26pm

Can you try editing the YAML and change "2" to 2 and save the thing?

Scriptwriter · July 21, 2024, 6:41pm

Hi Jan,
i changed it in yaml and pressed save. after that in log:

2024-07-21 20:37:21.596 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=593742898, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null]] and got error: Invalid argument
2024-07-21 20:37:32.085 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - can't process command OFF to snmp:target:a9df1fc2:accesspoint1: no writable channel found

if im looking later again to the yaml it shows:

  - id: accesspoint1
    channelTypeUID: snmp:switch
    label: accesspoint1
    configuration:
      mode: READ
      offvalue: "2.0"
      oid: .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
      datatype: INT32
      onvalue: "1.0"

so from my guessings it is not really possible to save an
offvalue: 2

J-N-K · July 21, 2024, 6:44pm

I’ll check that.

Scriptwriter · July 21, 2024, 6:46pm

i did a mistake, retried it justr now:

2024-07-21 20:43:07.861 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=593742907, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 2]] and got error: Invalid argument
2024-07-21 20:43:11.546 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command ON to snmp:target:a9df1fc2:accesspoint1
2024-07-21 20:43:13.046 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=593742908, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 1]] and got error: Invalid argument

because i had only REad MODE IN.
maybe the new errormessageshows you something more

  - id: accesspoint1
    channelTypeUID: snmp:switch
    label: accesspoint1
    configuration:
      mode: READ_WRITE
      offvalue: "2.0"
      oid: .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
      datatype: INT32
      onvalue: "1.0"

this is what config is now

J-N-K · July 21, 2024, 7:16pm

Plase change that back to "2". I created a thing:

UID: snmp:target:a11a87ccf4
label: SNMP Ziel
thingTypeUID: snmp:target
configuration:
  retries: 2
  hostname: 127.0.0.1
  protocol: v1
  port: 161
  refresh: 60
  community: public
  timeout: 1500
channels:
  - id: testswitch
    channelTypeUID: snmp:switch
    label: testswitch
    description: ""
    configuration:
      mode: WRITE
      offvalue: "5"
      oid: .1.2.3.4.5.6
      datatype: INT32
      onvalue: "2"

and the result is

21:15:00.453 [TRACE] [binding.snmp.internal.SnmpServiceImpl] - send SET[requestID=1143747847, errorStatus=Success(0), errorIndex=0, VBS[1.2.3.4.5.6 = 2]] to CommunityTarget[address=127.0.0.1/161,version=0,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=public,preferredTransports=null]

which looks good to me.

Scriptwriter · July 21, 2024, 7:24pm

i changed it back to 2 for offvalue and 1 for on. But then it is as it was at the beginning. If im checking what the state at switch is then im seeing it was not changed.

snmpwalk -v2c -c xxxxxx 192.168.2.250 .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
iso.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = INTEGER: 1
root@dockerpi01:~# snmpwalk -v2c -c xxxxxx 192.168.2.250 .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
iso.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = INTEGER: 1

2024-07-21 21:20:25.241 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=593742948, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null]] and got error: Invalid argument
2024-07-21 21:21:23.744 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
org.snmp4j.MessageException: Invalid argument
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:655) ~[?:?]
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:128) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:46) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:270) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:632) ~[?:?]
2024-07-21 21:21:25.245 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=593742949, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null]] and got error: Invalid argument

former it was possible to switch off/on all my POE devices by this, which is now not possible.

i also tried it with V1 as you used but the same:

2024-07-21 21:28:21.049 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command OFF to snmp:target:a9df1fc2:accesspoint1
2024-07-21 21:28:22.549 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=593742957, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 2]] and got error: Invalid argument
2024-07-21 21:28:37.888 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command ON to snmp:target:a9df1fc2:accesspoint1
2024-07-21 21:28:39.389 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=593742958, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 1]] and got error: Invalid argument
2024-07-21 21:29:10.039 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
org.snmp4j.MessageException: Invalid argument
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:655) ~[?:?]
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:128) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:46) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:270) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:632) ~[?:?]
2024-07-21 21:29:11.539 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=593742959, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null]] and got error: Invalid argument

J-N-K · July 21, 2024, 7:31pm

Are you sure that INT32 is the correct data type?

Scriptwriter · July 21, 2024, 7:36pm

from my opinion i would say yes, because i did not changed this.

J-N-K · July 21, 2024, 7:55pm

Can you please set the binding to TRACE (you can do that by using the gear icon in the add-on page) and try again? I’m not able to reproduce that locally.

“Invalid argument” usually happens when either the target address is invalid or the data. But the data seems to be fine.

Scriptwriter · July 21, 2024, 8:01pm

2024-07-21 21:58:50.153 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : invoked activate: activate
2024-07-21 21:58:50.153 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : Set implementation object for component
2024-07-21 21:58:50.154 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : Changed state from satisfied to active
2024-07-21 21:58:50.184 [TRACE] [ding.snmp.internal.SnmpTargetHandler] - Determined 192.168.2.250/161 as address for 192.168.2.250 (thing snmp:target:a9df1fc2)
2024-07-21 21:58:50.194 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : ImmediateComponentHolder Finished configuring the dependency managers for component for pid binding.snmp 
2024-07-21 21:58:50.194 [TRACE] [ding.snmp.internal.SnmpTargetHandler] - Determined 192.168.2.250/161 as address for 192.168.2.250 (thing snmp:target:snmptest)
2024-07-21 21:58:50.187 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
org.snmp4j.MessageException: Invalid argument
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:655) ~[?:?]
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:128) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:46) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:270) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:632) ~[?:?]
2024-07-21 21:58:50.194 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : ImmediateComponentHolder Will not enable component for pid binding.snmp: holder enabled state: true, metadata enabled: true 
2024-07-21 21:58:50.206 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : ConfigurableComponentHolder configuration updated for pid binding.snmp with change count 7
2024-07-21 21:58:50.210 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : Querying state active
2024-07-21 21:58:50.211 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : Querying state active
2024-07-21 21:58:50.211 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : invoking modified: modified: parameters [org.apache.felix.scr.impl.helper.ReadOnlyDictionary]
2024-07-21 21:58:50.215 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - initialized SNMP at 127.0.1.1/8162
2024-07-21 21:58:50.216 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : invoked modified: modified
2024-07-21 21:58:50.217 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : No change in target property for dependency osgi.ds.satisfying.condition: currently registered: true
2024-07-21 21:58:50.218 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : Querying state active
2024-07-21 21:58:50.221 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : dm $000 tracking 4 SingleStatic modified {org.openhab.binding.snmp.internal.SnmpService}={port=8162, service.id=739, service.bundleid=288, service.scope=bundle, osgi.ds.satisfying.condition.target=(osgi.condition.id=true), service.pid=binding.snmp, component.name=org.openhab.binding.snmp.internal.SnmpServiceImpl, component.id=380} (enter)
2024-07-21 21:58:50.223 [DEBUG] [ing.snmp.internal.SnmpHandlerFactory] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpHandlerFactory(379)] : dm $000 tracking 4 SingleStatic modified {org.openhab.binding.snmp.internal.SnmpService}={port=8162, service.id=739, service.bundleid=288, service.scope=bundle, osgi.ds.satisfying.condition.target=(osgi.condition.id=true), service.pid=binding.snmp, component.name=org.openhab.binding.snmp.internal.SnmpServiceImpl, component.id=380} (exit)
2024-07-21 21:58:50.223 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : ImmediateComponentHolder Finished configuring the dependency managers for component for pid binding.snmp 
2024-07-21 21:58:50.224 [DEBUG] [inding.snmp.internal.SnmpServiceImpl] - bundle org.openhab.binding.snmp:4.2.0 (288)[org.openhab.binding.snmp.internal.SnmpServiceImpl(380)] : ImmediateComponentHolder Will not enable component for pid binding.snmp: holder enabled state: true, metadata enabled: true 
2024-07-21 21:59:20.394 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command OFF to snmp:target:a9df1fc2:accesspoint1
2024-07-21 21:59:21.895 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=605886165, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 2]] and got error: Invalid argument

im seeing
192.168.2.250/161 as address for 192.168.2.250 (thing snmp:target:a9df1fc2
shouldnt it be 192.168.2.250:161 ?

i did same time also an tcpdump -i eth0 udp and ip host 192.168.2.250 which told me that nothing is sent on network if im changing the switch for accesspoint1-item

J-N-K · July 21, 2024, 8:15pm

No, that’s fine. Did you set the channel to READ, WRITE or READWRITE? I’m a bit astonished to see refresh calls in the log, a write-only channel should not show that.

You can also try setting log:set DEBUG org.snmp4j and see if there is some more information. To me it looks more like a network issue. Do you issue the snmpwalk command from the same machine?

Scriptwriter · July 22, 2024, 8:20am

i set it now via Karaf Console, but it does not tell more:

2024-07-22 10:13:46.978 [INFO ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
org.snmp4j.MessageException: Invalid argument
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:655) ~[?:?]
	at org.snmp4j.Snmp.sendMessage(Snmp.java:1074) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1044) ~[?:?]
	at org.snmp4j.Snmp.send(Snmp.java:1031) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpServiceImpl.send(SnmpServiceImpl.java:179) ~[?:?]
	at org.openhab.binding.snmp.internal.SnmpTargetHandler.refresh(SnmpTargetHandler.java:598) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.net.SocketException: Invalid argument
	at sun.nio.ch.DatagramChannelImpl.send0(Native Method) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821) ~[?:?]
	at sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853) ~[?:?]
	at sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218) ~[?:?]
	at java.net.DatagramSocket.send(DatagramSocket.java:664) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:128) ~[?:?]
	at org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(DefaultUdpTransportMapping.java:46) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:270) ~[?:?]
	at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:632) ~[?:?]
	... 11 more
2024-07-22 10:13:48.479 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested GET[requestID=488349008, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.5 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.4 = Null; 1.3.6.1.4.1.4526.11.16.1.1.1.3.1.3 = Null]] and got error: Invalid argument
2024-07-22 10:13:54.430 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command ON to snmp:target:a9df1fc2:accesspoint1
2024-07-22 10:13:55.930 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=488349009, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 1]] and got error: Invalid argument
2024-07-22 10:14:03.063 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU while processing command OFF to snmp:target:a9df1fc2:accesspoint1
2024-07-22 10:14:04.564 [WARN ] [ding.snmp.internal.SnmpTargetHandler] - snmp:target:a9df1fc2 requested SET[requestID=488349010, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = 2]] and got error: Invalid argument

the network-switch has the actual state of the POE-Port. Thats why im using READ_WRITE, which was no problem until the old version. So if someone would change the state by whatever tool on the networkswitch it would show the state on openhap too from reading. Some rules are switching normally the state of poe-devices if persons are near the area where the accesspoint is or if noone at home then it shuts them all down to save energy. For that it writes the states to switch.

also the state of the snmp device does not come any more to green:

yes, the snmpwalk command was entered on my raspi where the docker container from openhab runs on (but not from inside the container)

J-N-K · July 22, 2024, 8:29am

Looking at the place where it fails (DatagramChannelImpl.java:901) it is clear that there is an issue with the network address. Can you try sending from inside the container? Could it be that something else in the docker image/configuration changed during the upgrade?

Scriptwriter · July 22, 2024, 8:42am

the ame result from inside container:

docker exec -it openhab-openhab-1 snmpwalk -v2c -c xxxxxxx 192.168.2.250 .1.3.6.1.4.1.4526.11.16.1.1.1.3.1.2
iso.3.6.1.4.1.4526.11.16.1.1.1.3.1.2 = INTEGER: 1

nothing was changed. snmpwalk is communicating with the switch without problems, the switchfirmware was not updated since longer time.
remember, that tcpdump yesterday did not show any network traffic on udp161, so from my opinion snmp4j thinks something in parameters is not valid and does not try to send network packages to networkswitch

J-N-K · July 22, 2024, 8:59am

It’s not SNMP4J but the Java UDP implementation. It would be interesting to see what is actually passed to DatagramChannelImp.send, but unfortunately there is no logging. Can you try installing openhab without docker (only install snmp, create only the one thing)? We have seen so many issues with docker installations and networking that it wouldn’t surprise me if the root cause is something related to the docker networking.

Scriptwriter · July 22, 2024, 9:09am

unfortunatly i cannot install it without docker. Bus i upgraded since years all minor and major versions until 4.1.2 i can confirm it was running without problems. 4.1.3 im not sure because i was then longer on holiday and 4.2.0 the problem appeard. is there any chance to log such as your logs from your try yesterday?

Scriptwriter · July 22, 2024, 12:04pm

Hi @J-N-K
i got the solution by some googlings of parts of the errormessages. It forced me to some articles which all told me about problems to bind some sockets.

I remembered that snmp-addon has also a listener for receiving traps.
under addons->snmp->settings i had port 8161 in there which possibly was already used and not bindable. So i disabled the listener by Port “0” and all again was working again!

Thank you very much for giving the hint.
Maybe it would be good for future to add en errormessage if binding of traplistener-port is not possible.

J-N-K · July 22, 2024, 6:14pm

That’s interesting. I just tried port 161 (privileged port):

19:57:56.064 [WARN ] [binding.snmp.internal.SnmpServiceImpl] - could not open SNMP instance on port 161: Permission denied

and sending a command to a switch channel results in

20:00:05.384 [WARN ] [binding.snmp.internal.SnmpServiceImpl] - SNMP service not initialized, can't send SET[requestID=0, errorStatus=Success(0), errorIndex=0, VBS[1.2.3.4.5.6 = 2]] to CommunityTarget[address=192.168.0.1/161,version=1,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=public,preferredTransports=null]
20:00:06.196 [WARN ] [binding.snmp.internal.SnmpServiceImpl] - SNMP service not initialized, can't send GET[requestID=0, errorStatus=Success(0), errorIndex=0, VBS[1.2.3.4.5.6 = Null]] to CommunityTarget[address=192.168.0.1/161,version=1,timeout=1500,retries=2,securityLevel=1,securityModel=1,securityName=public,preferredTransports=null]

I didn’t manage to block a port, but I would expect it to behave the same. It may be OS dependent, though (I’m on MacOS).

soylent81 · August 2, 2024, 2:35pm

Hi,

after migrating to 4.2.0 I’ve got the same issues with the SNMP-binding. The problem seems to be TRAP related. I’m listening to UP/DOWN changes on certain ports and after installing 4.2.0 it stopped working. I get the same stacktrace with the inital [ding.snmp.internal.SnmpTargetHandler] - Could not send PDU
exception.

I’m not sure if this is a bug in the binding itself or maybe the snmp4j dependency.

My channels are configured the following way and have worked that way for months:

  - id: port_01_linkstatus
    channelTypeUID: snmp:switch
    label: Port 01 Link Status
    configuration:
      mode: TRAP
      offvalue: "2"
      oid: 1.3.6.1.2.1.2.2.1.8.1
      datatype: INT32
      onvalue: "1"

i’ve tried to change onvalue to 1 instead of “1”, but after re-opening the yaml it changed to “1.0”. None of these seem to work unfortunately.

I’m using the configuration as mentioned in the binding documentation (iptables preroute from 162 to 8162).

Any suggestions?