On Tue, Mar 10, 2020 at 06:25:10PM +0100, Martijn van Duren wrote:
> So I did some last minute testing of my own and apparently I misread.
> A varbindlist means a new sequence of varbinds, while the code assumes
> a list of varbinds.
>
> Code below actually works and also gives the additional
So I did some last minute testing of my own and apparently I misread.
A varbindlist means a new sequence of varbinds, while the code assumes
a list of varbinds.
Code below actually works and also gives the additional varbinds to
the trap handle "command".
Now actually asking for OKs. :-)
On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote:
> On 3/10/20 10:21 AM, Jan Klemkow wrote:
> > On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> >> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> >> varbindlist.
> >>
> >> Could you test
On 3/10/20 10:21 AM, Jan Klemkow wrote:
> On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
>> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
>> varbindlist.
>>
>> Could you test the diff below?
>
> Is also OK for me and the current call path seems to be
On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> varbindlist.
>
> Could you test the diff below?
Is also OK for me and the current call path seems to be clean.
But, shouldn't we set iter to NULL anyway?
Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
varbindlist.
Could you test the diff below?
martijn@
On 3/9/20 11:38 PM, Jan Klemkow wrote:
> Hi,
>
> The following diff fixes the use of the uninitialized pointer iter
> in trapcmd_exec().
>
> iter is just initialized in
Hi,
The following diff fixes the use of the uninitialized pointer iter
in trapcmd_exec().
iter is just initialized in traphandler_parse() if vers is SNMP_V2. In
all other cases iter stays uninitialized and may dereferenced in
trapcmd_exec().
OK?
bye,
Jan
Index: traphandler.c
