Violating BER sequence

Telu-Siva-Karun · February 13, 2025, 9:27pm

Hi,
In our application for SNMP agent we are using jdk1.8.0_392(Amazon Corretto) and snmp4j libraries (snmp4j-2.8.18 & snmp4j-agent-2.7.9).

Configured agent wtih vacmAccessSecurityLevel as ‘authPriv’ and usmUserEntry with usmUserAuthProtocol : SHA256 and usmUserPrivProtocol : AES192.

Configured trap receipients/manager with snmpTargetAddrEntry details and started agent.

For every one minute we are sending heartbeat trap, but at receiver end (SilverCreek software) unable to see the details of that traps.

An error message “Error decoding packet information for trap received from [agent ip address]”. And at SilverCreek console seeing error as

TclSNMPContext::Eval()
Violating BER sequence and full SNMP packet dump
Expecting: 0x0f434b6f57c6a78f01e61abe0311a5efeed67d5b4b09fa510d0a8ca359867ce0
Received: 0x992fd0d9ccecb0d2c62a92c5bf048e13b2d1a2d0e3d36adb
USMSecurityModel::AuthIncomingMsg()

Kindly help me to fix this.

–
Thanks
Telu Siva Karun Kumar

AGENTPP · February 13, 2025, 9:29pm

Without having checked the packet dump. I am pretty sure that the trap receiver has not the proper authentication and privacy keys to successfully decrypt the trap.

Telu-Siva-Karun · February 14, 2025, 8:34am

Hi Frank,

Thank you for looking into this.

Using a device having support of SHA256 and AES195 securities, our application(south bound interface) is able to fetch data(via SNMPv3 get operation) and receive traps from that device. At receiver(SilverCreek software) side I verified with those securities and result is same.

Where as in our application from the agent(north bound interface) with same securities the sent trap is failing at receiver side with above errors.

Please find packet data captured at agent(our application) side as below:

Frame 6: 279 bytes on wire (2232 bits), 279 bytes captured (2232 bits)
Linux cooked capture v2
Internet Protocol Version 4, Src: 10.215.128.170, Dst: 10.90.102.40
User Datagram Protocol, Src Port: 7161, Dst Port: 16500
Simple Network Management Protocol
msgVersion: snmpv3 (3)
msgGlobalData
msgID: 19112
msgMaxSize: 65535
msgFlags: 03
… .0… = Reportable: Not set
… …1. = Encrypted: Set
… …1 = Authenticated: Set
msgSecurityModel: USM (3)
msgAuthoritativeEngineID: 8000236e04005056a54ede
msgAuthoritativeEngineBoots: 1
msgAuthoritativeEngineTime: 115
msgUserName: timepictra
msgAuthenticationParameters: 2ba5404cc6d125db60773ef3
[Expert Info (Error/Malformed): Error while verifying Message authenticity: Authenticator length wrong]
[Error while verifying Message authenticity: Authenticator length wrong]
[Severity level: Error]
[Group: Malformed]
msgPrivacyParameters: 6ded0f039a4768a3
msgData: encryptedPDU (1)
encryptedPDU [truncated]: 49bfbd4dd8388dc9203b52be9545e144e9702ec8f2cd6635d2143e9903a5662911bb7de486993a585af2ae6553c9841da091c7172feebf2f547716b3091c75522b168dfe98094f189c130d5995fc017cbd6135c8d2278a034555f6836dff3d1a000719b3fe56436b05ad1
Decrypted data not formatted as expected, wrong key?
[Expert Info (Warning/Malformed): Decrypted data not formatted as expected, wrong key?]
[Decrypted data not formatted as expected, wrong key?]
[Severity level: Warning]
[Group: Malformed]
Frame 7: 431 bytes on wire (3448 bits), 431 bytes captured (3448 bits)
Linux cooked capture v2
Internet Protocol Version 4, Src: 10.215.128.170, Dst: 10.90.102.40
User Datagram Protocol, Src Port: 7161, Dst Port: 16500
Simple Network Management Protocol
msgVersion: snmpv3 (3)
msgGlobalData
msgID: 19114
msgMaxSize: 65535
msgFlags: 03
… .0… = Reportable: Not set
… …1. = Encrypted: Set
… …1 = Authenticated: Set
msgSecurityModel: USM (3)
msgAuthoritativeEngineID: 8000236e04005056a54ede
msgAuthoritativeEngineBoots: 1
msgAuthoritativeEngineTime: 115
msgUserName: timepictra
msgAuthenticationParameters: 2b2ac75df5f3778a60070f24
[Expert Info (Error/Malformed): Error while verifying Message authenticity: Authenticator length wrong]
[Error while verifying Message authenticity: Authenticator length wrong]
[Severity level: Error]
[Group: Malformed]
msgPrivacyParameters: 6ded0f039a4768a5
msgData: encryptedPDU (1)
encryptedPDU [truncated]: 106557de80385570f029b03a3188d0a4fd313f8559a778b1bba9c56a68a2d8e733fada0d8857398c0db5134a5d7436c3533c49b83fccb0becc3e72a653a899524d7808ec68a75957d72a1ed3dddbfb01c491a96c44532ed62eb74904498d3a648fc8cbcfc1893ffbdc97b
Decrypted ScopedPDU [truncated]: 1ac29d6e7636891f301f01a5c579f744b88e3c41aa6d46ea484202268cee8e02b5df4b72609b232c475964c13d29f23f012c740125e13a8ad3ffe45c6794a871ccf2f1fcfd9d3586452f399b1390cfd1a42672ed9dd87a6ec1ef9971697e2c41b3cd05d4bc9ae9
BER Error: Sequence expected but class:UNIVERSAL(0) Primitive tag:26 was unexpected
[Expert Info (Warning/Malformed): BER Error: Sequence expected but class:UNIVERSAL(0) Primitive tag:26 was unexpected]
[BER Error: Sequence expected but class:UNIVERSAL(0) Primitive tag:26 was unexpected]
[Severity level: Warning]
[Group: Malformed]

Kindly suggest.
–
Thanks
Telu Siva Karun Kumar

jkatz · February 14, 2025, 9:30am

If this is the complete authentication parameters value, then it seems that the agent is configured with auth protocol MD5 or SHA1, as only these protocols produce 12 bytes output.

So I would suggest to first disable encryption on sender and set the receiver to MD5 or SHA1 authentication and if this works, then go to the desired authentication protocol on the sender side.

Telu-Siva-Karun · February 18, 2025, 9:09am

Hi Jochen Katz,

Agent with securities SHA and AES128, able to see trap details at receiver side. Where unable to view trap details when agent is configured with SHA256 and AES192 securities.

Used protocol id as AuthHMAC192SHA256.ID for SHA256 and PrivAES192.ID for AES92. The code for considering protocol OID’s are as below:

String authProtocol = “SHA256”;
String privProtocol = “AES192”;
OID privProtocolOid;
OID authProtocolOid;
if(authProtocol.equals(“MD5”))
authProtocolOid = AuthMD5.ID;
else if(authProtocol.equals(“SHA”))
authProtocolOid = AuthSHA.ID;
else if(authProtocol.equals(“SHA224”))
authProtocolOid = AuthHMAC128SHA224.ID;
else if(authProtocol.equals(“SHA256”))
authProtocolOid = AuthHMAC192SHA256.ID;
else if(authProtocol.equals(“SHA384”))
authProtocolOid = AuthHMAC256SHA384.ID;
else if(authProtocol.equals(“SHA512”))
authProtocolOid = AuthHMAC384SHA512.ID;
else if(authProtocol.equals(“-”))
authProtocolOid = null;
else
continue;

if(privProtocol.equals(“DES”))
privProtocolOid = PrivDES.ID;
else if(privProtocol.equals(“AES128”))
privProtocolOid = PrivAES128.ID;
else if(privProtocol.equals(“AES192”))
privProtocolOid = PrivAES192.ID;
else if(privProtocol.equals(“AES256”))
privProtocolOid = PrivAES256.ID;
else if(privProtocol.equals(“AES192C”))
privProtocolOid = PrivAES192With3DESKeyExtension.ID;
else if(privProtocol.equals(“AES256C”))
privProtocolOid = PrivAES256With3DESKeyExtension.ID;
else if(privProtocol.equals(“-”))
privProtocolOid = null;
else
continue;

In agent object, based on above protocol oid’s the USM are created as below:

protected void addUsmUser(USM usm) 
{
	Iterator<SnmpAgentConfig.UsmUserEntry> it = config.uUserEntries.iterator();
	logger.info("SIZE(addUsmUser) -> " + config.uUserEntries.size());
	while(it.hasNext())
	{
		SnmpAgentConfig.UsmUserEntry e = it.next();

		UsmUser user = new UsmUser(new OctetString(e.usmUserName),
               					   e.usmAuthProtocol,
               					   new OctetString(e.usmAuthKey),
               					   e.usmPrivProtocol,
               					   new OctetString(e.usmPrivKey));

		usm.addUser(user.getSecurityName(), usm.getLocalEngineID(), user);
	}
	logger.info("Finished populating USM-MIB");
}

One observation was, with same securities(SHA256 & AES192) configured on agent the get request were successful from receiver side.

Kindly suggest.

–
Thanks
Telu Siva Karun Kumar

AGENTPP · February 18, 2025, 10:25am

AES192 is not standardized. Have you considered that? There are at least two incompatible variants in the market.
Maybe you have to use the other one for those agents then?