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-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
--
---
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
