TLS TCP Manager and Client

jdmarti1_rc · September 5, 2019, 6:31am

Howdy! Thanks for the add! I hope I can contribute, but have to ask forgiveness on “newb” level ahead of time.

I’m trying to add TLS over TCP for an inherited manager application which currently uses USM with DES. I’ve followed the example at [How to configure SNMP4J for TLS usage? - SNMP4J - AGENTPP](http://How to configure SNMP4J for TLS usage?)

and having some success with keystore and trustore operations and even getting a proper TLS handshake, but alas I’ve got to be missing something obvious as I get the following error on manager side dispatch:

5111 [TLSTM_0.0.0.0/7836] INFO org.snmp4j.MessageDispatcherImpl - Message from 127.0.0.1/55618 not dispatched, reason: statusInfo=noError, status=1602

In following what a 1602 is, I’ve only uncovered its a static constant stating:

SnmpConstants.SNMPv3_TSM_INVALID_CACHES;

This is where my newb igornance kicks in… Any and all help understanding what an invalid cache is most appreciated!

jdmarti1_rc · September 5, 2019, 6:41pm

Root problem seems to be DefaultTlsTmSecurityCallback does not have any SecurityNameMapping instances in securityNameMapping collection.

From example I’ve set security name within a CertifiedTarget and I’ve created a DefaultTlsTmSecurityCallback and set the callback to the TLSTM… but I’m not seeing how these assignments get translated into an instance of a SecurityNameMapping?

jdmarti1_rc · September 5, 2019, 6:41pm

When in doubt, follow the source!!! Found that I’m not properly passing the security name. Will fix and follow-up with this thread.

jdmarti1_rc · September 5, 2019, 7:33pm

Further information, I tried to add Secuirty Name Mapping when setting Security Callback into the TLSTSM, but when DefaultTlsTmSecurityCallback does it’s comparison in getSecurityName, I now have a SecurityNameMapping but still no fingerprint.

So I’m assuming I’m missing how I pull the certificate fingerprint when the manager server initializes TLSTM? And assuming it would be the fingerprint of the certificate from my keystore for the created alias/securityName?

AGENTPP · September 5, 2019, 7:49pm

Please use the CertifiedTaget constructor with server and client fingerprints. The server fingerprint will then be compared with the server’s certificate fingerprint.

jdmarti1_rc · September 5, 2019, 8:34pm

Awesome! Thanks and noticed your edit on the example too! Truly appreciated! If I could burden you again… Is there any interface that I can use when setting up the CertifiedTarget during instantiation of TLSTM that will return my server fingerprint? As of now, I’m only seeing the keystore accessed when I invoke listen?

jdmarti1_rc · September 5, 2019, 8:56pm

Tried

// use the CertifiedTaget constructor with server and client fingerprints
CertifiedTarget ct = new CertifiedTarget(address, securityName,
OctetString.fromHexString(“5E:0E:……”),
//Client fingerprint could be empty string (no check)
new OctetString());

But alas DefaultTlsTmSecurityCallback did not have a map entry. So I used:

CertifiedTarget ct = new CertifiedTarget(new OctetString(ipAddress));
securityCallback.addSecurityNameMapping(
OctetString.fromHexString(“5E:…”),
null,
null, securityName);

And the map entry was there and comparison worked. Is this an issue because I’m on snmp4j-2.7.0? I’m stuck using framework compliant with java 8 for now…

AGENTPP · September 5, 2019, 9:08pm

Please upgrade SNMP4J to 2.8.0 because it contains several TLS related (security) fixes.

jdmarti1_rc · September 6, 2019, 6:48am

Last issue was not giving a CertMappingType.SANDNSName in my addSecurityNameMapping create. Now getting the following which seems to be proper. I’ll continue trying to get the proper pdu requests into the transport and see if ye ole application will init!!

Sincere thanks for helping me work this through and your amazing snmp4j!

] with type SANDNSName and date null
43722 [TLSTM_0.0.0.0/7836] DEBUG org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback - Matched security name: localhost
43723 [TLSTM_0.0.0.0/7836] DEBUG org.snmp4j.transport.TLSTM - Received message from 127.0.0.1/56839 with length 68: 30:42:02:01:03:30:10:02:03:00:c1:de:02:03:00:80:00:04:01:07:02:01:04:04:00:30:29:04:05:80:00:00:00:06:04:00:a0:1e:02:04:3e:bc:b9:6c:02:01:00:02:01:00:30:10:30:0e:06:0a:2b:06:01:06:03:0a:02:01:01:00:05:00
43726 [TLSTM_0.0.0.0/7836] DEBUG org.snmp4j.mp.MPv3 - SNMPv3 header decoded: msgId=49630, msgMaxSize=32768, msgFlags=07, secModel=4

jdmarti1_rc · September 6, 2019, 6:48am

FYI… tried with 2.8.0 release and alas all the same behaviors. Now that I’m past the cert comparison, now I’m receiving:

77238 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback - Getting security name for peer certificate chain: [[
…
77238 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback - Matching peer cert fingerprint
…
with type null and date null
java.lang.NullPointerException
77250 [TLSTM_0.0.0.0/7835] WARN org.snmp4j.transport.TLSTM - NullPointerException within select()?
77250 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.TLSTM - Worker task finished: org.snmp4j.transport.TLSTM$ServerThread
at org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback.mapCertToTSN(DefaultTlsTmSecurityCallback.java:99)
at org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback.getSecurityName(DefaultTlsTmSecurityCallback.java:77)
at org.snmp4j.transport.tls.DefaultTlsTmSecurityCallback.getSecurityName(DefaultTlsTmSecurityCallback.java:48)
at org.snmp4j.transport.TLSTM$SocketEntry.checkTransportStateReference(TLSTM.java:777)
at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1521)
at org.snmp4j.transport.TLSTM$ServerThread.run(TLSTM.java:1310)
at java.lang.Thread.run(Thread.java:748)

It’s getting obvious to me at least how newb on this I am… I’ve got to be missing something obvious…

AGENTPP · September 6, 2019, 7:55am

You need to specify a mapping type and mapping data for the cert-to-tls-security-name mapping. Both values are null, that’s why you get the NPE.

jdmarti1_rc · September 12, 2019, 9:43pm

Howdy! Almost there… I promise

After figuring out I had to explicitly set the context Engine ID on a Scoped PDU request, I now have my getBulk request processing on the manager side. However, it’s a balancing act that I cannot find for how many repetitions on a given oid I can perform without manager or trap client giving MPv3 parse error or a MessageDispatcherImpl - java.io.IOException: Unexpected end of input stream at position 1

IE:
Request one for 600 reps on OID xxxx allows request to be processed on manager side but then client receives response:

540 [TLSTM_192.168.17.9/0] DEBUG org.snmp4j.transport.TLSTM - Received message from 127.0.0.1/7835 with length 16385: 30:82:42:38:…
543 [TLSTM_192.168.17.9/0] WARN org.snmp4j.mp.MPv3 - MPv3 parse error: The encoded length 16952 exceeds the number of bytes left in input at position 4 which actually is 16385
java.io.IOException: The encoded length 16952 exceeds the number of bytes left in input at position 4 which actually is 16385
at org.snmp4j.asn1.BER.checkLength(BER.java:1005)
at org.snmp4j.asn1.BER.decodeLength(BER.java:611)
at org.snmp4j.asn1.BER.decodeHeader(BER.java:650)
at org.snmp4j.asn1.BER.decodeHeader(BER.java:677)
at org.snmp4j.mp.MPv3.prepareDataElements(MPv3.java:1117)
at org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.java:278)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:390)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:350)
at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
at org.snmp4j.transport.TLSTM$ServerThread.dispatchMessage(TLSTM.java:1578)
at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1522)
at org.snmp4j.transport.TLSTM$ServerThread.run(TLSTM.java:1310)
at java.lang.Thread.run(Thread.java:748)
545 [TLSTM_192.168.17.9/0] INFO org.snmp4j.MessageDispatcherImpl - Message from 127.0.0.1/7835 not dispatched, reason: statusInfo=noError, status=-1408

If I bring the 600 any lower then manager gives:

954241 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.TLSTM - Running delegated task on SocketEntry[peerAddress=127.0.0.1/55753,socket=Socket[addr=127.0.0.1/127.0.0.1,port=55753,localport=7835],lastUse=Mon Jan 19 12:38:03 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=117 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=1 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]: Status = OK HandshakeStatus = NOT_HANDSHAKING
bytesConsumed = 37 bytesProduced = 1
954241 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.TLSTM - Reading inappBuffer=java.nio.HeapByteBuffer[pos=0 lim=1 cap=32768]
954241 [TLSTM_0.0.0.0/7835] DEBUG org.snmp4j.transport.TLSTM - Received message from 127.0.0.1/55753 with length 1: 30
java.io.IOException: Unexpected end of input stream at position 1
954241 [TLSTM_0.0.0.0/7835] WARN org.snmp4j.MessageDispatcherImpl - java.io.IOException: Unexpected end of input stream at position 1
at org.snmp4j.asn1.BERInputStream.read(BERInputStream.java:59)
at org.snmp4j.asn1.BER.decodeLength(BER.java:585)
at org.snmp4j.asn1.BER.decodeHeader(BER.java:650)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:370)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:350)
at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
at org.snmp4j.transport.TLSTM$ServerThread.dispatchMessage(TLSTM.java:1578)
at org.snmp4j.transport.TLSTM$ServerThread.readMessage(TLSTM.java:1522)
at org.snmp4j.transport.TLSTM$ServerThread.run(TLSTM.java:1310)
at java.lang.Thread.run(Thread.java:748)

Running on a windows box right now, so don’t have any jumbo frame issues like I would have on linux with very large bulk rep requests and if I go back to UDP transport, no issues…

Thanks for your help and considerations!

AGENTPP · September 12, 2019, 10:19pm

What you encounter is probably an incorrectly executed TLS packet fragmentation. A TLS packet is fragmented into 16KByte (16384 bytes) data transmissions. In your case, the total data length 16389 (16385+4) exceeds the 16384 byte fragment limit and therefore the fragmentation is not detected by the TLSTM (and no merge/reassembling takes place)

What TLS stack is used by the command responder you are using? What TLS version are you using?

jdmarti1_rc · September 14, 2019, 7:44pm

Was able to find and set

System.setProperty(SnmpConfigurator.P_TLS_VERSION, “TLSv1.2”);

Made sure that my Auth Protocol is AuthHMAC256SHA384 and now I’m successful with my first getBulk and response. No fragmentation issues!!! Thanks for the nudge! I’ve finally got my new TLS Transport working with my legacy app!!! You and your framework are amazing and sincerely appreciate your help!!!

jdmarti1_rc · September 14, 2019, 7:44pm

Sincere thanks for your reply. Using SNMP4J 2.8.0. When initialized, logs showing TLSTM - Configured SSL engine, enabled protocols are [TLSv1] and due to java 8 + 2.8.0 this is TLS-TCP not DTLS.

jdmarti1_rc · November 6, 2019, 10:17pm

Your TLS pest again…

When a client connects, I receive it’s org.snmp4j.transport.TransportStateEvent and store the peer address so I can send TLS/TCP based ‘broadcasts’ back to all connected clients. In the non TLS implementation, I simply stored a new instance of org.snmp4j.UserTarget

    UserTarget target = new UserTarget();
    target.setAddress(address);
    target.setVersion(SnmpConstants.version3);
    target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
    target.setSecurityName(new OctetString(userName));

With TLS I tried using TLSTargetFactory in the same manner

TLSTargetFactory.create(SnmpFactory.getAddress(Transport.TLS, peerAddress.toString()),
V3Security.instance().getSecurityName(), SNMPv3.RETRIES, SNMPv3.DISCOVERY_TIMEOUT,
V3Security.instance().getLocalEngineID())

When that Abstract Target is later invoked with

snmp.send(pdu, trapTarget);

The following trace occurs:

06 Nov 2019 16:05:15,943 [org.snmp4j.Snmp:] DEBUG - Fire process PDU event: CommandResponderEvent[securityModel=4, securityLevel=3, maxSizeResponsePDU=32743, pduHandle=PduHandle[470560328], stateReference=StateReference[msgID=6292881,pduHandle=null,securityEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,securityModel=org.snmp4j.security.TSM@7546dc9e,securityName=localhost,securityLevel=3,contextEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,contextName=,retryMsgIDs=null], pdu=SET[{contextEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30, contextName=}, requestID=470560328, errorStatus=0, errorIndex=0, VBS[1.3.6.1.4.1.8419.20.1.2.8.0 = TRUE; 1.3.6.1.4.1.8419.20.1.2.10.0 = jdmarti1]], messageProcessingModel=3, securityName=localhost, processed=false, peerAddress=127.0.0.1/63616, transportMapping=mil.navy.e6b.block1.sysman.snmp.transport.ServerTLSTransportMapping@397347b3, tmStateReference=null]
06 Nov 2019 16:05:15,943 [mil.navy.e6b.block1.sysman.manager.handler.manager.SetCB:] INFO - reset Sysman initiated by jdmarti1
06 Nov 2019 16:05:15,944 [org.snmp4j.mp.MPv3:] DEBUG - Removed cache entry: StateReference[msgID=6292881,pduHandle=null,securityEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,securityModel=org.snmp4j.security.TSM@7546dc9e,securityName=localhost,securityLevel=3,contextEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,contextName=,retryMsgIDs=null]
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - Looking up connection for destination ‘127.0.0.1/63616’ returned: SocketEntry[peerAddress=127.0.0.1/63616,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63616,localport=7835],lastUse=Mon Jan 19 12:12:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - {127.0.0.1/63810=SocketEntry[peerAddress=127.0.0.1/63810,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63810,localport=7835],lastUse=Mon Jan 19 12:04:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null], 127.0.0.1/63619=SocketEntry[peerAddress=127.0.0.1/63619,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63619,localport=7835],lastUse=Mon Jan 19 11:58:14 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null], 127.0.0.1/63616=SocketEntry[peerAddress=127.0.0.1/63616,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63616,localport=7835],lastUse=Mon Jan 19 12:12:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]}
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - Waking up selector for new message
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - Adding operation 4 for: SocketEntry[peerAddress=127.0.0.1/63616,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63616,localport=7835],lastUse=Mon Jan 19 12:12:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - Key is writable
06 Nov 2019 16:05:15,944 [org.snmp4j.transport.TLSTM:] DEBUG - Sending message with length 116 to 127.0.0.1/63616: 30:72:02:01:03:30:10:02:03:60:05:91:02:03:00:80:00:04:01:03:02:01:04:04:00:30:59:04:15:80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30:04:00:a2:3e:02:04:1c:0c:2e:48:02:01:00:02:01:ff:30:30:30:14:06:0c:2b:06:01:04:01:c1:63:14:01:02:08:00:04:04:54:52:55:45:30:18:06:0c:2b:06:01:04:01:c1:63:14:01:02:0a:00:04:08:6a:64:6d:61:72:74:69:31
06 Nov 2019 16:05:15,945 [org.snmp4j.transport.TLSTM:] DEBUG - Writing TLS outNetBuffer(PAYLOAD): java.nio.HeapByteBuffer[pos=0 lim=197 cap=32768]
06 Nov 2019 16:05:15,945 [org.snmp4j.transport.TLSTM:] DEBUG - Wrote TLS 197 bytes from outNetBuffer(PAYLOAD)
06 Nov 2019 16:05:15,945 [org.snmp4j.transport.TLSTM:] DEBUG - Payload sent completely
06 Nov 2019 16:05:15,945 [org.snmp4j.transport.TLSTM:] DEBUG - Key is writable
06 Nov 2019 16:05:17,496 [org.snmp4j.mp.MPv3:] DEBUG - Adding cache entry: StateReference[msgID=6253355,pduHandle=PduHandle[660356043],securityEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,securityModel=org.snmp4j.security.TSM@7546dc9e,securityName=sysmanManagerTLSSN,securityLevel=3,contextEngineID=80:00:13:70:04:6d:61:6e:61:67:65:72:2d:44:4c:50:30:31:35:36:30,contextName=,retryMsgIDs=null]
java.io.IOException: Transport state reference does not match existing reference for this session/target
at org.snmp4j.transport.TLSTM$ServerThread.sendMessage(TLSTM.java:1230)
at org.snmp4j.transport.TLSTM.sendMessage(TLSTM.java:477)
at org.snmp4j.transport.TLSTM.sendMessage(TLSTM.java:69)
at org.snmp4j.MessageDispatcherImpl.sendMessage(MessageDispatcherImpl.java:203)
at org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:522)
at org.snmp4j.Snmp.sendMessage(Snmp.java:1087)
at org.snmp4j.Snmp.send(Snmp.java:968)
at org.snmp4j.Snmp.send(Snmp.java:961)
at org.snmp4j.Snmp.send(Snmp.java:926)
at mil.navy.e6b.block1.sysman.snmp.SNMP.trap(SNMP.java:395)
at mil.navy.e6b.block1.sysman.snmp.SNMP.broadcast(SNMP.java:430)
at mil.navy.e6b.block1.sysman.manager.task.ClientUpdateTask.sendToStatusClients(ClientUpdateTask.java:85)
at mil.navy.e6b.block1.sysman.manager.task.ClientUpdateTask.run(ClientUpdateTask.java:464)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
06 Nov 2019 16:05:17,496 [org.snmp4j.transport.TLSTM:] DEBUG - Looking up connection for destination ‘127.0.0.1/63616’ returned: SocketEntry[peerAddress=127.0.0.1/63616,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63616,localport=7835],lastUse=Mon Jan 19 12:12:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
06 Nov 2019 16:05:17,496 [org.snmp4j.transport.TLSTM:] DEBUG - {127.0.0.1/63810=SocketEntry[peerAddress=127.0.0.1/63810,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63810,localport=7835],lastUse=Mon Jan 19 12:04:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null], 127.0.0.1/63619=SocketEntry[peerAddress=127.0.0.1/63619,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63619,localport=7835],lastUse=Mon Jan 19 11:58:14 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null], 127.0.0.1/63616=SocketEntry[peerAddress=127.0.0.1/63616,socket=Socket[addr=127.0.0.1/127.0.0.1,port=63616,localport=7835],lastUse=Mon Jan 19 12:12:41 CST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]}
06 Nov 2019 16:05:17,496 [org.snmp4j.transport.TLSTM:] ERROR - TransportStateReferences refNew=TransportStateReference[transport=mil.navy.e6b.block1.sysman.snmp.transport.ServerTLSTransportMapping@397347b3, address=127.0.0.1/63616, securityName=sysmanManagerTLSSN, requestedSecurityLevel=authPriv, transportSecurityLevel=undefined, sameSecurity=false, sessionID=null, certifiedIdentity=null],refOld=TransportStateReference[transport=mil.navy.e6b.block1.sysman.snmp.transport.ServerTLSTransportMapping@397347b3, address=127.0.0.1/63616, securityName=localhost, requestedSecurityLevel=authPriv, transportSecurityLevel=authPriv, sameSecurity=true, sessionID=1, certifiedIdentity=null] do not match, message dropped
06 Nov 2019 16:05:17,496 [mil.navy.e6b.block1.sysman.snmp.SNMPv3:] FATAL - Exception sending trap - org.snmp4j.MessageException: Transport state reference does not match existing reference for this session/target

How do I create or retrieve a proper “callback” target for a connected client from a received org.snmp4j.transport.TransportStateEvent?

AGENTPP · November 6, 2019, 11:00pm

Interesting use case, indeed! But why are you using SNMP4J-Agent to implement your command responder?

The answer to your question is quite simple:

If you send a RESPONSE PDU, you need to include the TransportStateReference instance that you got from the TLSTM while receiving the command (request) message.

You can use TLSTM.sendMessage(Address address, byte[] message, TransportStateReference tmStateReference) for that.

Hope this helps.

Best regards,
Frank

jdmarti1_rc · November 7, 2019, 9:24pm

Sir… sorry… but I’m guessing because I’m stuck on 2.80 I not seeing what you have suggested??

When I get the CommandResponderEvent I attempt to get TLSTM from CommandResponderEvent getTransportMapping, but there is no exposed method to get TransportStateReference?? I then tried getTmStateReference on CommandResponderEvent and alas it’s null.

To clarify a point, the app is creating a new instance of PDU with VariableBindings from a Collection of ManagedObjects. It is this pdu that I’m trying to send, unsolicited, back to a client from it’s ‘stored callback reference’.

In the for what it’s worth department, I have no issues with a response initiated directly from a request’s CommandResponderEvent. Those are handled and then use the request’s CommandResponderEvent MessageDispatcher.dispatcher.returnResponsePdu…

Also another ‘issue’ I ran into is even if I was able to get the clients TransportStateReference, I was unable to decompose the PDU into a byte for the listed TLSTM.sendMessage method signature… which is TLSTM.sendMessage(TcpAddress address, byte[] message, TransportStateReference tmStateReference) throws IOException

jdmarti1_rc · November 7, 2019, 9:24pm

Sincere thanks for the reply! I’ll get digging in the code and see how I can get the TransportStateReference from the original request.

The short one to a long answer, is our original “Sysman” designer and implementation guru created a home made system manager, that uses snmp4/j, not only for all snmp originating agent connections (all network elements, os’s), as you would normally except, but he also used your framework to implement the underlying transport for all our user facing GUI applications.

A typical Sysman “Manager” Server, not only has many multiples of Daemon Threads running DefaultUDPTransportMapping which are pollers for the snmp agents on our OS, and other elements, we also run DefaultTcpTransportMapping for our user GUI. It is this mapping that I’m trying to ‘lock’ down with TLS…

For certain, IMHO, we are certainly using your classes in several ‘unorthodox’ ways… but it has been serving us and our customer very well since at least version 1.9!!

AGENTPP · November 7, 2019, 9:50pm

Congratulations - You found dead code! The CommandResponderEvent.getTmStateReference() will always return null. (This will be fixed in the next release and will basically implement the workaround below in that getter method)

There is another way to get the TransportStateReference:

Use CommandResponderEvent.getStateReference() to get the standard stateReference.
Then use that stateReference.getSecurityStateReference() to the the securityStateReference.
Then cast that securityStateReference to TsmSecurityStateReference and call its getTmStateReference() method.

I am curious if your special use cases will work with the SNMP-TLS of TLSTM. It could succeed, but I am not sure that it will…