On 2021/06/20 22:31, Martijn van Duren wrote:
> On Fri, 2021-06-11 at 16:13 +0200, Martijn van Duren wrote:
> > any takers?
> >
> > On Fri, 2021-06-04 at 22:11 +0200, Martijn van Duren wrote:
> > > ping
> > >
> > > On Fri, 2021-05-28 at 08:19 +0200, Martijn van Duren wrote:
> > > > As the original comment said:
> > > > /*
> > > > * This should probably go into parsevarbinds, but that's for a
> > > > * next refactor
> > > > */
> > > >
> > > > This moves the pdu parsing of traps into parsevarbinds.
> > > > Added bonus, we can now see the packets in debugging mode:
> > > > startup
> > > > snmpe: listening on udp 127.0.0.1:162
> > > > ktable_new: new ktable for rtableid 0
> > > > snmpe_parse: 127.0.0.1:162: SNMPv2 'public' pdutype SNMPv2-Trap request
> > > > 1329591927
> > > > snmpe_parse: 127.0.0.1:162: SNMPv1 'public' pdutype Trap request 0
> > > >
> > > > OK?
> > > >
> > > > martijn@
> > > >
> Somehow this one survived the tightened security mayhem with only a few
> offset warnings. Still looking for OKs.
I don't know snmpd well enough to give a considered OK for this
(and don't use snmpd's trap handler, figure that if I'm going to
need to call net-snmp code to translate the numeric oid anyway
I might as well use their trapd), it does seem generally neater
to me
> @@ -460,7 +457,14 @@ snmpe_parsevarbinds(struct snmp_message
> struct ber_element *pvarbind = NULL, *end;
> char buf[BUFSIZ];
> struct ber_oid o;
> - int i;
> + int i = 1;
> +
> + if (msg->sm_pdutype == SNMP_C_TRAP ||
> + msg->sm_pdutype == SNMP_C_TRAPV2) {
> + if (traphandler_parse(msg) == -1)
> + goto varfail;
> + return 0;
> + }
>
> msg->sm_errstr = "invalid varbind element";
>
> @@ -468,7 +472,7 @@ snmpe_parsevarbinds(struct snmp_message
> msg->sm_varbindresp = NULL;
> end = NULL;
>
> - for (i = 1; varbind != NULL && i < SNMPD_MAXVARBIND;
> + for (; varbind != NULL && i < SNMPD_MAXVARBIND;
> varbind = varbind->be_next, i++) {
> if (ober_scanf_elements(varbind, "{oeS$}", &o, &value) == -1) {
> stats->snmp_inasnparseerrs++;
not sure moving the initializer for i here is an improvement though,
seems better to have the loop more self-contained?
