Fluent interface - OID missing in PDU

SNMP4J
1

PDU pdu = targetBuilder.pdu().type(PDU.GETNEXT).oids(oids).contextName(contextName).build();

The packet has reached the target but is missing the OID that is sent. Hence , the response payload is empty.
Do we have a sample case that can be run using Fluent interface.
Can we also use Fluent for SET. Can you please point me to examples for set.

2

can you please let me know if I can use the repository from SMI PRO and send object names as strings instead of OIDs for fluent interface

3

Yes, sure. That is no problem. Simply create the OIDs for the PDU using the String constructor.

1 Like
4

If the PDU sent, does not contain any VariableBinding then the oids parameter is and empty String array in your code.
Using the fluent interface for SET PDUs is no problem.You simply use the vbs or vb method to add the VariableBindings to the PDU then.

1 Like
5

Frank
Can you please help me out here.
OIDs are still missing as per the tcpdump below and response payload is empty.

OIDs are assigned just before the call as below:
Target<?> userTarget = targetBuilder
.user(securityName, targetEngineID)
.auth(null) //noauthnopriv
.priv(null)
.done()
.timeout(500).retries(1)
.build();
oids[0] = “1.3.6.1.4.1.1751.2.117.1.1.3.0”;
oids[1] = “application4gAdministrativeState”;
PDU pdu = targetBuilder.pdu().type(PDU.GET).oids(oids).contextName(contextName).build();

tcpdump :

00:07:01.236629 IP fgwdevgen92.35400 > 192.168.0.23.snmp: F=r U="" E= C="" GetRequest(11)
00:07:01.236801 IP fgwdevgen92.35400 > 192.168.0.23.snmp: F=r U="" E= C="" GetRequest(11)
00:07:01.237134 IP 192.168.0.23.snmp > fgwdevgen92.35400: F= U="" E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C="" Report(28) S:snmpUsmMIB.usmMIBObjects.usmStats.usmStatsUnknownEngineIDs.0=55
00:07:01.237217 IP 192.168.0.23.snmp > fgwdevgen92.35400: F= U="" E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C="" Report(28) S:snmpUsmMIB.usmMIBObjects.usmStats.usmStatsUnknownEngineIDs.0=55
00:07:01.248959 IP fgwdevgen92.35400 > 192.168.0.23.snmp: F=r U=“FMS” E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C=“FMS” GetRequest(14)
00:07:01.248963 IP fgwdevgen92.35400 > 192.168.0.23.snmp: F=r U=“FMS” E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C=“FMS” GetRequest(14)
00:07:01.249214 IP 192.168.0.23.snmp > fgwdevgen92.35400: F= U=“FMS” E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C=“FMS” GetResponse(14)
00:07:01.249219 IP 192.168.0.23.snmp > fgwdevgen92.35400: F= U=“FMS” E=_80_00_1f_88_80_bc_82_f5_55_3a_23_64_61_00_00_00_00 C=“FMS” GetResponse(14)

6

Are you sure, that you are observing the payload SNMPv3 communication? It seems that the tcpdump is about engine ID discovery (where an empty PDU is exchanged to get the authoritative engine ID).
But because you specified already the (wrong) target engine ID (thus the authoritative engine ID for GET requests), but the agent does not recognise it, the discovery and the communication fails.

7

Target address is correct and the PDU is responded by the device and has reached the fluent code as below.
Payload is empty.

Target address udp:192.168.0.23/161
Received: RESPONSE[{contextEngineID=80:00:1f:88:80:bc:82:f5:55:3a:23:64:61:00:00:00:00, contextName=FMS}, requestID=2109312842, errorStatus=0, errorIndex=0, VBS[]]
Payload: []

8

But why is there an unknownEngineID report in the tcpdump then?
I assume, that there is probably an error in the agent‘s PDU report/error handling.
I still think the authoritative engine ID is wrong.

9

The authoritative engineid on the device:
AuthoritativeEngineID = 0x000006D787FE9B8F00000000

(EnterpriseId+ip) - as per std

This Engine id is not being sent by the fluent code after discovery

byte[] targetEngineID = snmp.discoverAuthoritativeEngineID(targetAddress, 1000);

Does the above API learn the engineId from the target or uses its std for Engine Id formation? Am I missing something here?

10

Are you sure? Was the discovery successful?

If specified, the engine ID from the .user(securityName, targetEngineID) call is being used (if the engine ID has not been removed from the MPv3 engine ID cache (indexed by target) meanwhile).

In any case, if the agent returns an empty response PDU, the problem is with the agent.