On mån, 2007-01-22 at 09:50 +0000, Dave Shield wrote:
> On 21/01/07, Magnus Fromreide <[EMAIL PROTECTED]> wrote:
> > AgentX:
> > Is an agentx master agent a proxy in the sense of RFC 2576/3584?
>
> Not really.
> The main definition of a "proxy forwarder" is given in RFC 3413, section 1.5.
> The critical aspect of that is that the forwarding application works with
> *complete* PDUs - it doesn't unpick an incoming request into two or more
> sub-requests, or stitch together several sub-responses into a single outgoing
> response.
>
> From that perspective, our "proxy" implementation isn't strictly proxy
> forwarding at all.
Agreed.
> The CoExistence RFCs are also talking about different versions of SNMP.
> The AgentX protocol isn't quite SNMP - altough there are obvious similarities.
>
> I'll admit to using the spirit of RFC 2576 when it came to
> implementing the original AgentX support, but I'm not sure it's directly
> applicable.
Yes. I have to admit that I am looking for more rather than less of 2576
in the handling of AgentX PDUs. I would for instance like to have the
possibility to affect the address in sent SNMPv1 Trap PDUs from the
subagent - a typical example where this would be beneficial is when you
use "agentx" as DESTINATION of the snmptrapd.conf "forward" directive.
> > If one look in RFC 2741 7.1.10 point 3 then it refers to RFC
> > 2089, but I am uncertain about the meaning of that.
>
> That seems to be referring to how a *sub*agent should deal with a request
> to send a notification, when that notification is provided in SNMPv1 form.
> I'd suggest that this is more to do with the handling of internal APIs, rather
> than proxying as such.
I do not agree here.
The first paragraph of 7.1.10 is about subagent handling but then the
second paragraph starts talking about how a master agent should perform
and in point 3 there is references to generating SNMPv1 Trap PDUs,
something a subagent doesn't do by definition, it only generate AgentX
Notify-PDUs.
> > Another question is if one should update the proxy handling to
> > follow the recommendations of RFC 2576 or 3584 instead.
>
> Yes.
Thanks.
> > This do make a functional difference as the handling of varbinds
> > containing Counter64 values is changed between 2089 and
> > 2576/3584. Currently net-snmp seems to implement the 2089 rules.
>
> Can you clarify, please.
> I've had a quick skim through 2089 & 3584, and can't immediately spot
> what the difference might be. I'm probably missing something screamingly
> obvious - please enlighten me.
2089 3.3 point 1.
If any of the varBinds in the varBindList has an SNMPv2 syntax
of Counter64, then such varBinds are implicitly considered to be
not in view, and so they are removed from the varBindList to be
sent with the SNMPv1 trap.
2576 3.2 point 6
3584 3.2 point 6 (References are renumbered, otherwise similar)
...
Note, however, that if the SNMPv2 variable-bindings contain any
objects whose type is Counter64, the translation to SNMPv1
notification parameters cannot be performed. In this case, the
notification cannot be encoded in an SNMPv1 packet (and so the
notification cannot be sent using SNMPv1, see section 4.1.3 and
section 4.2).
Thus a 2089 proxy removes values of type Counter64 from a v2->v1 trap
conversion while a 2576/3584 proxy doesn't retransmit v2->v1 traps
containing Counter64's
> > Proxy:
> > If a proxy as per RFC 2089/2576/3584 receives an
> > NOTIFICATION-PDU where snmpTrapOID.0 = ccitt.1 then the
> > enterprise field of an outgoing TRAP-PDU should contain what?
> > Additionally the same question but with iso.1 and
> > joint-iso-ccitt.1 is interesting as well.
>
> Juergen is clearly correct in saying that RFC 3584 doesn't cover this
> situation, and it should ideally be clarified.. But I'd have to ask whether
> this is ever likely to happen. (The trap, not the clarification!)
> The higher-levels of the .ccitt, .iso and .joint-iso-ccitt trees are
> administered
> by the relevant international bodies, who are the only people who could
> legitimately define an OID of this form. And I would be amazed if any
> standard NOTIFICATION TYPE object was ever defined with such an OID.
>
> So the only time this situation would occur would be following an abuse of
> the OID structure - someone defining MIB objects that they had no call to
> touch. In which case, they deserve all that's coming to them!
I agree to this - the reason I detected it was due to giving bad
parameters to an application of mine :-)
>
> > The current net-snmp handling of this case seems to be SIGSEGV,
> > so I suppose something have to be done.
>
> Crashing out is not a good idea, no!
> At the very least, I'd be inclined to log an error and discard the trap.
Mmm.
> Dave
>
> PS: Has anyone ever suggested to you that you've got a warped mind? :-)
Not quite that up front, but I suppose that the fact that I twiddle with
net-snmp for fun is suggesting something.
/MF
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
