Thank you for the response. I understand your position and, of course, the
final decision is yours. I'll just make a little argument to see what you
think.
1) This happens in the real world. We've had a few devices which exhibit this
behavior. But making the decision not to support it in the low level code,
it's impossible to accommodate these real world conditions without maintaining
source code change.
2) Other packages seem to handle it. I don't have the specifics right now.
MRTG handles it, for instance. And I'm pretty sure Net-SNMP. I can go back
and check these if you like.
I guess a counter argument could be that you don't have a lot of demand so it
must not happen all that much.
I can't think of a hook that would make maintenance any easier. The source
code change is quite simple. In v1 message processing, MPv1,
prepareDataElements, look ahead in the message to get the PDU type and pass it
to createPDU. In createPDU, if the PDU type is the v2 Trap, create a v2 PDU
instead of a v1 PDU.
MPv1.java
public int prepareDataElements(MessageDispatcher messageDispatcher,
...
// Look ahead to the PDU type
wholeMsg.mark(64);
MutableByte pduType = new MutableByte();
int length2 = BER.decodeHeader(wholeMsg, pduType);
// vxPDU to allow a v2 trap PDU in a v1 message
PDU vxPDU = createPDU(pduType.getValue());
pdu.setPdu(vxPDU);
// Move back to the beginning of the PDU
wholeMsg.reset();
vxPDU.decodeBER(wholeMsg);
...
public PDU createPDU(byte pduType) {
if(pduType == PDU.TRAP) { // Allow for V2 Trap PDU in V1 message
logger.debug("Create v2 PDU");
return new PDU();
}
else {
logger.debug("Create v1 PDU");
return new PDUv1();
}
}
If you are willing to consider it, perhaps a configuration item could be used.
The default would be full conformance. Enabling the configuration item would
allow this non-conforming condition, using if statements on the configuration
item in the code above for looking ahead.
Thank you,
Jerome
From: snmp4j-boun...@agentpp.org [snmp4j-boun...@agentpp.org] on behalf of
Frank Fock [f...@agentpp.com]
Sent: Monday, November 26, 2012 5:12 PM
To: snmp4j@agentpp.org
Subject: Re: [SNMP4J] v2 PDU in v1 message
Hello Jerome,
I will not add code to SNMP4J that violates the SNMP standards.
If you need such code, you are free to change it in your version.
Nevertheless, if some hook methods would help you to
clarly separate your code from the SNMP4J code, I am willing
to add such hook methods.
Best regards,
Frank
Am 26.11.2012 18:20, schrieb Jerome Callaghan:
> Hello,
>
> We have some devices which send traps in a v2 PDU but in a v1 message.
> snmp4j discards these. I've come up with a source code change which looks
> ahead in v1 message processing to see if it's a v2 PDU and creates a v2 PDU
> instead of a v1 PDU if so. I've tested and it's working well. Is there
> someone to talk to about getting this into the source baseline for snmp4j?
>
> Thank you,
> Jerome
>
> ___
> SNMP4J mailing list
> SNMP4J@agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j