Hi Jerome,
I will try to implement a configurable "workaround" which will be
disabled by default.
Best regards,
Frank
Am 28.11.2012 15:19, schrieb Jerome Callaghan:
> 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-bounces at agentpp.org [snmp4j-bounces at agentpp.org] on behalf of Frank Fock [fock at agentpp.com]
> Sent: Monday, November 26, 2012 5:12 PM
> To: snmp4j at 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 at 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 at 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