Re: Net-SNMP 5.8 compatibility issue

[Simon Chamlian]

The incompatibility started when I upgraded OpenSSL.

Since I am compiling NET-SNMP within yocto, I cannot do 'make install'.



On Mon, Aug 31, 2020 at 11:18 AM Wes Hardaker <
harda...@users.sourceforge.net> wrote:

> Simon Chamlian  writes:
>
> > There seems to be a compatibility issue between net-snmp and the crypto
> > library.
>
> Was that a self-built Net-SNMP 5.8?  And it was built recently after the
> system upgraded to the newer libcrypto?
>
> And did you try a 'make install' to see if the installation works or is
> that running in the agent directory itself with the libtool wrapper script?
> --
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 compatibility issue

[Wes Hardaker via Net-snmp-coders]

Simon Chamlian  writes:

> There seems to be a compatibility issue between net-snmp and the crypto
> library.

Was that a self-built Net-SNMP 5.8?  And it was built recently after the
system upgraded to the newer libcrypto?

And did you try a 'make install' to see if the installation works or is
that running in the agent directory itself with the libtool wrapper script?
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 core dump

[Bart Van Assche]

On 2020-05-26 10:49, David Moriconi (dmoricon) via Net-snmp-coders wrote:
> The Net-SNMP daemon crashed with the following error (full backtrace can
> be found below):
> 
> Error in `/usr/local/netsnmp/netsnmp_base/sbin/snmpd': malloc():
> smallbin double linked list corrupted: 0x56546e6a9840
> 
> We are using Net-SNMP 5.8 built from revision rev2c837e1 of V5-8-patches
> branch.  We have an AgentX subagent connected to the daemon.
> Unfortunately, we do not know what operation causes the crash. I was
> wondering if this was a known issue and by any chance already fixed.

Please provide a way to reproduce this crash or reproduce it under
Valgrind and provide the Valgrind output.

Thanks,

Bart.


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: NET-SNMP-5.8

[Bart Van Assche]

On 2019-12-30 02:39, Seyfullah BECERİKLİ wrote:
> We have some issues installing net-snmp-5.8 version. Do you have any
> specific installation guide for it?

Hi Seyfullah,

How about installing v5.8.1.pre1 instead of v5.8? A large number of bugs
has been fixed in v5.8.1.pre1. That version is available at
https://github.com/net-snmp/net-snmp/archive/V5-8-patches.zip.

Bart.


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 - Having both snmp v2 and v3 available.

[Simon Chamlian]

I got it working.

Since I was compiling under Yocto, the cache wasn't cleared.

Thanks,
S


On Tue, Sep 11, 2018 at 11:17 AM, Wes Hardaker <
harda...@users.sourceforge.net> wrote:

> Simon Chamlian  writes:
>
> > I am not seeing and compilation errors. It compiles fine but v2 does
> > not work:
>
> Very odd.  What options did you compile with (IE, configure options...
> run ./config.status --version to find out, or 'net-snmp-config
> --configure-options'.
>
> You might also run snmpd with -Dvacm to get debugging output for the
> authorization code.
> --
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 - Having both snmp v2 and v3 available.

[Wes Hardaker via Net-snmp-coders]

Simon Chamlian  writes:

> I am not seeing and compilation errors. It compiles fine but v2 does
> not work:

Very odd.  What options did you compile with (IE, configure options...
run ./config.status --version to find out, or 'net-snmp-config 
--configure-options'.

You might also run snmpd with -Dvacm to get debugging output for the
authorization code.
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net


___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 - Having both snmp v2 and v3 available.

[Simon Chamlian]

I am not seeing and compilation errors. It compiles fine but v2 does not
work:


*with 5.7.3*
$ snmpset -v 3 -u Simon -a MD5 -A Simon-00 -l authNoPriv 172.27.43.15
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 i 1
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 = INTEGER: true(1)

$ snmpget -v 2c -c public 172.27.43.15
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 = INTEGER: true(1)


*with 5.8 (another machine)*
$ snmpset -v 3 -u Simon -a MD5 -A Simon-00 -l authNoPriv 172.27.43.2
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 i 1
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 = INTEGER: true(1)

$ snmpget -v 2c -c public 172.27.43.2
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0
MPBC-1RU-MIB::mpbc1RUAckTrapCriticalEnable.0 = No Such Object available on
this agent at this OID


both have the same snmpd.conf :

createUser Simon  MD5 "Simon-00"
rwuser Simon

rocommunity  public
rwcommunity  private


and same code.

I launch the agent using:

snmpd -c /home/simon/snmpd.conf -Lf /tmp/snmpd_log.txt







But when I run it, from my MIB browser, I can communicate only using snmpv3.

When trying to get data using v2, it simply

On Fri, Aug 31, 2018 at 11:33 AM, Wes Hardaker <
harda...@users.sourceforge.net> wrote:

> Simon Chamlian  writes:
>
> > With snmp 5.7.3 I used to have the agent handling both v2 and v3.
> >
> > With 5.8, only v3 seems to be available.
>
> No, they should both work.  Can you be more specific about how you
> compiled it and what errors you're seeing?
> --
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8 - Having both snmp v2 and v3 available.

[Wes Hardaker via Net-snmp-coders]

Simon Chamlian  writes:

> With snmp 5.7.3 I used to have the agent handling both v2 and v3.
> 
> With 5.8, only v3 seems to be available.

No, they should both work.  Can you be more specific about how you
compiled it and what errors you're seeing?
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc4 available for testing

[Bart Van Assche]

On 07/02/18 06:46, Robert Story wrote:
> On Fri, 29 Jun 2018 13:38:27 -0700 Bart wrote:
> BVA> Can you explain why you have ignored all nine patches that I
> BVA> posted one week ago? Had you noticed that one of these patches
> BVA> is a build fix? See also
> BVA> https://sourceforge.net/p/net-snmp/mailman/message/36349380/.
> 
> I did not ignore the patches. I looked at all of them. None of them
> met the criteria for inclusion during the RC phase of a release.
> Display fixes? Debug messages? Totally inappropriate during RC
> phase. As for the build fix, there were no supporting votes, and if
> this truly breaks the build, why didn't that come up when testing
> the last RC release?

Hello Robert,

Please have another look at these patches, and at least at the patch
that fixes the MSVC build. It has been a very long time since a Net-SNMP
version was released and I think that it would be bad for the reputation
of the Net-SNMP project if the 5.8 release wouldn't build on one of the
supported platforms.

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc4 available for testing

[Robert Story]

On Fri, 29 Jun 2018 13:38:27 -0700 Bart wrote:
BVA> Can you explain why you have ignored all nine patches that I
BVA> posted one week ago? Had you noticed that one of these patches
BVA> is a build fix? See also
BVA> https://sourceforge.net/p/net-snmp/mailman/message/36349380/.

I did not ignore the patches. I looked at all of them. None of them
met the criteria for inclusion during the RC phase of a release.
Display fixes? Debug messages? Totally inappropriate during RC
phase. As for the build fix, there were no supporting votes, and if
this truly breaks the build, why didn't that come up when testing
the last RC release?

Robert

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc4 available for testing

[Bart Van Assche]

On 06/28/18 16:06, Robert Story wrote:


Net-SNMP 5.8.rc4 is now available for testing at

   
https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-release-candidates/


Below is a summary of the change in 5.8.rc4. Please see the CHANGES
file for a more detailed list of specific bugs/patches that have
been fixed/applied, and the ChangeLog file for a comprehensive
listing of all changes made to the code.

*5.8.rc4*
 snmpd:
   - SNMP-TARGET-MIB: Fix snmpTargetAddrTAddress

Hopefully this will be the last RC for 5.8.


Hello Robert,

Can you explain why you have ignored all nine patches that I posted one 
week ago? Had you noticed that one of these patches is a build fix? See 
also https://sourceforge.net/p/net-snmp/mailman/message/36349380/.


Thanks,

Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: net-snmp 5.8: "unknown snmp version 193" from agentx subagent

[Bill Fenner]

Oops, it turns out that the reason that it works is because the agentx
session is in the session list that is always iterated over, so, this fix
is wrong: we should just silently ignore agentx sessions in this code.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: net-snmp 5.8: "unknown snmp version 193" from agentx subagent

[Bill Fenner]

On Wed, Mar 21, 2018 at 10:58 AM Bill Fenner  wrote:

> The new code in net-snmp 5.8 that tries to account for v1 or v2 trap
> sessions logs an error from an agentx subagent, since the agentx code
> registers the session as being AGENTX_VERSION_1.  This constant is only
> defined in the agentx code, so agent_trap.c doesn't know what it is.
>
> ...
>


> 3. Teach agent_trap.c about AGENTX_VERSION_ numbers.  I don't think anyone
> wants to do this, since otherwise the agentx code is encapsulated in
> mibgroup/agentx/
>

I don't know how I missed this, but it turns out agent_trap.c explicitly
knows about agentx, so my theory about this being a problem is kersplut.
This means that the fix is:

@@ -171,6 +171,9 @@ _trap_version_incr(int version)
 #ifndef NETSNMP_DISABLE_SNMPV2C
 case SNMP_VERSION_2c:
 #endif
+#ifdef USING_AGENTX_PROTOCOL_MODULE
+case AGENTX_VERSION_1:
+#endif
 case SNMP_VERSION_3:
 ++_v2_sessions;
 break;
@@ -195,6 +198,9 @@ _trap_version_decr(int version)
 #ifndef NETSNMP_DISABLE_SNMPV2C
 case SNMP_VERSION_2c:
 #endif
+#ifdef USING_AGENTX_PROTOCOL_MODULE
+case AGENTX_VERSION_1:
+#endif
 case SNMP_VERSION_3:
 if (--_v2_sessions < 0) {
 snmp_log(LOG_ERR,"v2 session count < 0! fixed.\n");

T113agentxtrap_simple tests the agentx trap sending code path, and the
traps work, so my earlier reading of the code that made me think that this
could break agentx traps was wrong.  This is just cosmetic (you can see the
"unknown snmp version 193" message in the T113 log file).  I'll commit the
fix after 5.8.

  Bill
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc3 available for testing

[Wes Hardaker via Net-snmp-coders]

Robert Story  writes:

> With any luck, this will be the last release candidate

Yes please!  Thanks for all your work getting this out the door Robert.
I'd like to ask everyone (me too) to really really decide if a patch
you're proposing is truly a show stopper.  I'd also suggest that we plan
on a 5.8.1 in the not "too" distant future to cover new bugs we find, as
I believe we've already identified a number of important potential
changes.  Maybe 6 months out or so would be a good time frame for a .1
release.

-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc2 available for testing

[Stuart Henderson]

On 2018/05/19 10:26, Magnus Fromreide wrote:
> On Fri, May 18, 2018 at 08:46:40PM -0700, Bart Van Assche wrote:
> > On 05/18/18 18:05, Stuart Henderson wrote:
> > > On 2018/05/18 18:36, Robert Story wrote:
> > > >  snmplib:
> > > >- [BUG 2815]: Display UTF-8 characters again
> > > >- [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
> > > >  sprint_realloc_octet_string() embeds unprintable control 
> > > > characters
> > > >  or binary zeroes in its output. This behavior could cause 
> > > > truncated
> > > >  output in snmptrapd.")
> > > 
> > > I think there's a problem with this change, with rc2 I'm seeing frequent
> > > segfaults in walk/bulkwalk (one out of every 3 or 4 attempts to run it),
> > > these don't occur with rc1 and sprint_realloc_octet_string() is in the
> > > backtrace.
> > > 
> > > $ snmpwalk -v2c -c public 10.15.5.1
> > > <...snip...>
> > > SNMPv2-MIB::sysORDescr.3 = STRING: 
> > > iso.org.dod.internet.mgmt.mib_2.ipMIB.ipfMIB
> > > SNMPv2-MIB::sysORDescr.4 = STRING: iso.org.dod.internet.mgmt.mib_2.snmp
> > > SNMPv2-MIB::sysORDescr.5 = STRING: 
> > > iso.org.dod.internet.mgmt.mib_2.dot1dBridge
> > > SNMPv2-MIB::sysORDescr.6 = STRING: iso.org.dod.internet.mgmt.mib_2.host
> > > SNMPv2-MIB::sysORDescr.7 = STRING: iso.org.dod.internet.mgmt.mib_2.ifMIB
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > _libc_strlcpy (dst=0x15ddceaf3070 "", src=0x15de4bd9e000  > > access memory at address 0x15de4bd9e000>,
> > >  dsize=) at /usr/src/lib/libc/string/strlcpy.c:45
> > > 45  while (*src++)
> > > (gdb) bt
> > > #0  _libc_strlcpy (dst=0x15ddceaf3070 "",
> > >  src=0x15de4bd9e000  > > 0x15de4bd9e000>, dsize=)
> > >  at /usr/src/lib/libc/string/strlcpy.c:45
> > > #1  0x15de2f559fdc in sprint_realloc_octet_string 
> > > (buf=0x7f7e7220, buf_len=0x7f7e7218,
> > >  out_len=0x7f7e7210, allow_realloc=1, var=0x15de238e7800, 
> > > enums=0x0, hint=0x15de50e25274 "", units=0x0)
> > >  at mib.c:589
> > > #2  0x15de2f566028 in sprint_realloc_variable (buf=0x7f7e7220, 
> > > buf_len=0x7f7e7218,
> > >  out_len=0x7f7e7210, allow_realloc=1, objid=0x15de238e7830, 
> > > objidlen=11, variable=0x15de238e7800)
> > >  at mib.c:3581
> > > #3  0x15de2f56626d in fprint_variable (f=0x15dd9e658308 <__sF+152>, 
> > > objid=0x15de238e7830, objidlen=11,
> > >  variable=0x15de238e7800) at mib.c:3653
> > > #4  0x15de2f5661c5 in print_variable (objid=0x15de238e7830, 
> > > objidlen=11, variable=0x15de238e7800) at mib.c:3629
> > > #5  0x15db58a00fd1 in main (argc=3, argv=0x7f7e81f8) at 
> > > snmpwalk.c:338
> > 
> > With which operating system, compiler and C library did you encounter this?
> > There is no guarantee that the 'str' argument passed from that code path to
> > strlcpy() will be '\0'-terminated. I'm surprised to see a while (*src++)
> > loop in strlcpy() - I doubt that that is correct.
> 
> I think a while(*src++) in strlcpy is reasonable.
> 
> Strlcpy does after all return strlen(src) and that is hard to achive without
> such a loop.
> 
> If there is no guarantee that src is '\0'-terminated then strlcpy is the wrong
> function to use.

This is on OpenBSD (where strlcpy originated, actually). Our own libc,
clang 6.0 (same behaviour with -O0).

strlcpy is definitely only meant for C strings (i.e. \0-terminated).


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc2 available for testing

[Magnus Fromreide]

On Fri, May 18, 2018 at 08:46:40PM -0700, Bart Van Assche wrote:
> On 05/18/18 18:05, Stuart Henderson wrote:
> > On 2018/05/18 18:36, Robert Story wrote:
> > >  snmplib:
> > >- [BUG 2815]: Display UTF-8 characters again
> > >- [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
> > >  sprint_realloc_octet_string() embeds unprintable control 
> > > characters
> > >  or binary zeroes in its output. This behavior could cause 
> > > truncated
> > >  output in snmptrapd.")
> > 
> > I think there's a problem with this change, with rc2 I'm seeing frequent
> > segfaults in walk/bulkwalk (one out of every 3 or 4 attempts to run it),
> > these don't occur with rc1 and sprint_realloc_octet_string() is in the
> > backtrace.
> > 
> > $ snmpwalk -v2c -c public 10.15.5.1
> > <...snip...>
> > SNMPv2-MIB::sysORDescr.3 = STRING: 
> > iso.org.dod.internet.mgmt.mib_2.ipMIB.ipfMIB
> > SNMPv2-MIB::sysORDescr.4 = STRING: iso.org.dod.internet.mgmt.mib_2.snmp
> > SNMPv2-MIB::sysORDescr.5 = STRING: 
> > iso.org.dod.internet.mgmt.mib_2.dot1dBridge
> > SNMPv2-MIB::sysORDescr.6 = STRING: iso.org.dod.internet.mgmt.mib_2.host
> > SNMPv2-MIB::sysORDescr.7 = STRING: iso.org.dod.internet.mgmt.mib_2.ifMIB
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > _libc_strlcpy (dst=0x15ddceaf3070 "", src=0x15de4bd9e000  > access memory at address 0x15de4bd9e000>,
> >  dsize=) at /usr/src/lib/libc/string/strlcpy.c:45
> > 45  while (*src++)
> > (gdb) bt
> > #0  _libc_strlcpy (dst=0x15ddceaf3070 "",
> >  src=0x15de4bd9e000  > 0x15de4bd9e000>, dsize=)
> >  at /usr/src/lib/libc/string/strlcpy.c:45
> > #1  0x15de2f559fdc in sprint_realloc_octet_string (buf=0x7f7e7220, 
> > buf_len=0x7f7e7218,
> >  out_len=0x7f7e7210, allow_realloc=1, var=0x15de238e7800, 
> > enums=0x0, hint=0x15de50e25274 "", units=0x0)
> >  at mib.c:589
> > #2  0x15de2f566028 in sprint_realloc_variable (buf=0x7f7e7220, 
> > buf_len=0x7f7e7218,
> >  out_len=0x7f7e7210, allow_realloc=1, objid=0x15de238e7830, 
> > objidlen=11, variable=0x15de238e7800)
> >  at mib.c:3581
> > #3  0x15de2f56626d in fprint_variable (f=0x15dd9e658308 <__sF+152>, 
> > objid=0x15de238e7830, objidlen=11,
> >  variable=0x15de238e7800) at mib.c:3653
> > #4  0x15de2f5661c5 in print_variable (objid=0x15de238e7830, 
> > objidlen=11, variable=0x15de238e7800) at mib.c:3629
> > #5  0x15db58a00fd1 in main (argc=3, argv=0x7f7e81f8) at 
> > snmpwalk.c:338
> 
> With which operating system, compiler and C library did you encounter this?
> There is no guarantee that the 'str' argument passed from that code path to
> strlcpy() will be '\0'-terminated. I'm surprised to see a while (*src++)
> loop in strlcpy() - I doubt that that is correct.

I think a while(*src++) in strlcpy is reasonable.

Strlcpy does after all return strlen(src) and that is hard to achive without
such a loop.

If there is no guarantee that src is '\0'-terminated then strlcpy is the wrong
function to use.

/MF

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc2 available for testing

[Bart Van Assche]

On 05/18/18 18:05, Stuart Henderson wrote:

On 2018/05/18 18:36, Robert Story wrote:

 snmplib:
   - [BUG 2815]: Display UTF-8 characters again
   - [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
 sprint_realloc_octet_string() embeds unprintable control characters
 or binary zeroes in its output. This behavior could cause truncated
 output in snmptrapd.")


I think there's a problem with this change, with rc2 I'm seeing frequent
segfaults in walk/bulkwalk (one out of every 3 or 4 attempts to run it),
these don't occur with rc1 and sprint_realloc_octet_string() is in the
backtrace.

$ snmpwalk -v2c -c public 10.15.5.1
<...snip...>
SNMPv2-MIB::sysORDescr.3 = STRING: iso.org.dod.internet.mgmt.mib_2.ipMIB.ipfMIB
SNMPv2-MIB::sysORDescr.4 = STRING: iso.org.dod.internet.mgmt.mib_2.snmp
SNMPv2-MIB::sysORDescr.5 = STRING: iso.org.dod.internet.mgmt.mib_2.dot1dBridge
SNMPv2-MIB::sysORDescr.6 = STRING: iso.org.dod.internet.mgmt.mib_2.host
SNMPv2-MIB::sysORDescr.7 = STRING: iso.org.dod.internet.mgmt.mib_2.ifMIB

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=0x15ddceaf3070 "", src=0x15de4bd9e000 ,
 dsize=) at /usr/src/lib/libc/string/strlcpy.c:45
45  while (*src++)
(gdb) bt
#0  _libc_strlcpy (dst=0x15ddceaf3070 "",
 src=0x15de4bd9e000 , 
dsize=)
 at /usr/src/lib/libc/string/strlcpy.c:45
#1  0x15de2f559fdc in sprint_realloc_octet_string (buf=0x7f7e7220, 
buf_len=0x7f7e7218,
 out_len=0x7f7e7210, allow_realloc=1, var=0x15de238e7800, enums=0x0, 
hint=0x15de50e25274 "", units=0x0)
 at mib.c:589
#2  0x15de2f566028 in sprint_realloc_variable (buf=0x7f7e7220, 
buf_len=0x7f7e7218,
 out_len=0x7f7e7210, allow_realloc=1, objid=0x15de238e7830, 
objidlen=11, variable=0x15de238e7800)
 at mib.c:3581
#3  0x15de2f56626d in fprint_variable (f=0x15dd9e658308 <__sF+152>, 
objid=0x15de238e7830, objidlen=11,
 variable=0x15de238e7800) at mib.c:3653
#4  0x15de2f5661c5 in print_variable (objid=0x15de238e7830, objidlen=11, 
variable=0x15de238e7800) at mib.c:3629
#5  0x15db58a00fd1 in main (argc=3, argv=0x7f7e81f8) at snmpwalk.c:338


With which operating system, compiler and C library did you encounter 
this? There is no guarantee that the 'str' argument passed from that 
code path to strlcpy() will be '\0'-terminated. I'm surprised to see a 
while (*src++) loop in strlcpy() - I doubt that that is correct.


Bart.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.rc2 available for testing

[Stuart Henderson]

On 2018/05/18 18:36, Robert Story wrote:
> snmplib:
>   - [BUG 2815]: Display UTF-8 characters again
>   - [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
> sprint_realloc_octet_string() embeds unprintable control characters
> or binary zeroes in its output. This behavior could cause truncated
> output in snmptrapd.")

I think there's a problem with this change, with rc2 I'm seeing frequent
segfaults in walk/bulkwalk (one out of every 3 or 4 attempts to run it),
these don't occur with rc1 and sprint_realloc_octet_string() is in the
backtrace.

$ snmpwalk -v2c -c public 10.15.5.1
<...snip...>
SNMPv2-MIB::sysORDescr.3 = STRING: iso.org.dod.internet.mgmt.mib_2.ipMIB.ipfMIB
SNMPv2-MIB::sysORDescr.4 = STRING: iso.org.dod.internet.mgmt.mib_2.snmp
SNMPv2-MIB::sysORDescr.5 = STRING: iso.org.dod.internet.mgmt.mib_2.dot1dBridge
SNMPv2-MIB::sysORDescr.6 = STRING: iso.org.dod.internet.mgmt.mib_2.host
SNMPv2-MIB::sysORDescr.7 = STRING: iso.org.dod.internet.mgmt.mib_2.ifMIB

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=0x15ddceaf3070 "", src=0x15de4bd9e000 , 
dsize=) at /usr/src/lib/libc/string/strlcpy.c:45
45  while (*src++)
(gdb) bt
#0  _libc_strlcpy (dst=0x15ddceaf3070 "", 
src=0x15de4bd9e000 , 
dsize=)
at /usr/src/lib/libc/string/strlcpy.c:45
#1  0x15de2f559fdc in sprint_realloc_octet_string (buf=0x7f7e7220, 
buf_len=0x7f7e7218, 
out_len=0x7f7e7210, allow_realloc=1, var=0x15de238e7800, enums=0x0, 
hint=0x15de50e25274 "", units=0x0)
at mib.c:589
#2  0x15de2f566028 in sprint_realloc_variable (buf=0x7f7e7220, 
buf_len=0x7f7e7218, 
out_len=0x7f7e7210, allow_realloc=1, objid=0x15de238e7830, objidlen=11, 
variable=0x15de238e7800)
at mib.c:3581
#3  0x15de2f56626d in fprint_variable (f=0x15dd9e658308 <__sF+152>, 
objid=0x15de238e7830, objidlen=11, 
variable=0x15de238e7800) at mib.c:3653
#4  0x15de2f5661c5 in print_variable (objid=0x15de238e7830, objidlen=11, 
variable=0x15de238e7800) at mib.c:3629
#5  0x15db58a00fd1 in main (argc=3, argv=0x7f7e81f8) at snmpwalk.c:338


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.pre3 available

[Robert Story]

On Fri, 4 May 2018 05:16:29 -0700 Bart wrote:
BVA> Thanks for having drawn our attention to that bug report. How
BVA> about fixing bug 2831 with the below patch?
BVA> [...]
BVA>   include/net-snmp/agent/agent_internal_vars.h  | 25 
BVA> [...]
BVA> +#include 

In order to make it clear that this header it not to be installed,
I think it should go in the agent directory, and includes should be
of the form #include "agent/agent_internal_vars.h", including any
relative path prefix as necessary.

Robert

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.pre3 available

[Stuart Henderson]

On 2018/05/04 05:16, Bart Van Assche wrote:
> On 05/03/18 13:48, Stuart Henderson wrote:
> > On 2018-04-27, Robert Story  wrote:
> > > We're closing in on a final release. The current plan is to have
> > > release candidate 1 next week.
> > 
> > Is it planned to address https://sourceforge.net/p/net-snmp/bugs/2831/
> > before release or are distro packagers going to need to patch the other
> > programs to cope?
> 
> Thanks for having drawn our attention to that bug report. How about fixing
> bug 2831 with the below patch?
> 
> Bart.
> 
> Subject: [PATCH] BUG: 2831: Move agent-internal global variables into a
> separate header file
> 
> Because commit 81b65f4d23a9 added declarations for several global variables
> to public header files, applications that declare global variables with the
> same names no longer build. Hence move the global variables that were added
> by that commit to public header files into a new header file.
> 
> Fixes: 81b65f4d23a9 ("Move declarations of global functions and variables
> from .c to .h")

Thanks Bart, that looks like a good approach to me.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.pre3 available

[Bart Van Assche]

On 05/03/18 13:48, Stuart Henderson wrote:

On 2018-04-27, Robert Story  wrote:

We're closing in on a final release. The current plan is to have
release candidate 1 next week.


Is it planned to address https://sourceforge.net/p/net-snmp/bugs/2831/
before release or are distro packagers going to need to patch the other
programs to cope?


Thanks for having drawn our attention to that bug report. How about 
fixing bug 2831 with the below patch?


Bart.


Subject: [PATCH] BUG: 2831: Move agent-internal global variables into a 
separate header file


Because commit 81b65f4d23a9 added declarations for several global 
variables to public header files, applications that declare global 
variables with the same names no longer build. Hence move the global 
variables that were added by that commit to public header files into a 
new header file.


Fixes: 81b65f4d23a9 ("Move declarations of global functions and 
variables from .c to .h")

---
 agent/agent_index.c   |  1 +
 agent/agent_registry.c|  1 +
 agent/agent_trap.c|  1 +
 agent/mibgroup/agent/nsTransactionTable.c |  1 +
 agent/mibgroup/agentx/client.c|  1 +
 agent/mibgroup/agentx/master_admin.c  |  1 +
 agent/mibgroup/agentx/subagent.c  |  1 +
 agent/mibgroup/agentx/subagent.h  |  6 --
 agent/mibgroup/disman/event/mteEvent.c|  1 +
 agent/mibgroup/disman/event/mteTrigger.c  |  1 +
 agent/mibgroup/mibII/snmp_mib.c   |  1 +
 agent/mibgroup/mibII/snmp_mib_5_5.c   |  4 +---
 agent/mibgroup/mibII/system_mib.c |  1 +
 agent/mibgroup/notification/snmpNotifyTable.c |  3 +--
 agent/mibgroup/utilities/iquery.c |  1 +
 agent/snmp_agent.c|  1 +
 agent/snmp_vars.c |  1 +
 agent/snmpd.c |  1 +
 apps/agentxtrap.c |  1 +
 apps/snmptrapd.c  |  2 ++
 include/net-snmp/agent/agent_internal_vars.h  | 25 
+

 include/net-snmp/agent/agent_trap.h   |  8 
 include/net-snmp/agent/snmp_agent.h   | 10 --
 include/net-snmp/agent/snmp_vars.h|  2 --
 24 files changed, 45 insertions(+), 31 deletions(-)
 create mode 100644 include/net-snmp/agent/agent_internal_vars.h

diff --git a/agent/agent_index.c b/agent/agent_index.c
index c063a599c456..d3fa4c0caf26 100644
--- a/agent/agent_index.c
+++ b/agent/agent_index.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "snmpd.h"
 #include "mibgroup/struct.h"
diff --git a/agent/agent_registry.c b/agent/agent_registry.c
index 7d96c65dec57..6b461a102325 100644
--- a/agent/agent_registry.c
+++ b/agent/agent_registry.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "snmpd.h"
 #include "mibgroup/struct.h"
diff --git a/agent/agent_trap.c b/agent/agent_trap.c
index 97808afca3e5..8084d4d4d78f 100644
--- a/agent/agent_trap.c
+++ b/agent/agent_trap.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/agent/mibgroup/agent/nsTransactionTable.c 
b/agent/mibgroup/agent/nsTransactionTable.c

index df338ada03a9..8ee7a9465396 100644
--- a/agent/mibgroup/agent/nsTransactionTable.c
+++ b/agent/mibgroup/agent/nsTransactionTable.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
diff --git a/agent/mibgroup/agentx/client.c b/agent/mibgroup/agentx/client.c
index 049108e2977f..9e916b9d9467 100644
--- a/agent/mibgroup/agentx/client.c
+++ b/agent/mibgroup/agentx/client.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "agentx/protocol.h"
 #include "agentx/client.h"
diff --git a/agent/mibgroup/agentx/master_admin.c 
b/agent/mibgroup/agentx/master_admin.c

index 57cf56a72df9..fbc0688c7462 100644
--- a/agent/mibgroup/agentx/master_admin.c
+++ b/agent/mibgroup/agentx/master_admin.c
@@ -32,6 +32,7 @@

 #include 
 #include 
+#include 

 #include "agentx/protocol.h"
 #include "agentx/client.h"
diff --git a/agent/mibgroup/agentx/subagent.c 
b/agent/mibgroup/agentx/subagent.c

index a643576df331..fed12694dc52 100644
--- a/agent/mibgroup/agentx/subagent.c
+++ b/agent/mibgroup/agentx/subagent.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "snmpd.h"
diff --git a/agent/mibgroup/agentx/subagent.h 
b/agent/mibgroup/agentx/subagent.h

index eb033e3409b1..958217e419fc 100644
--- a/agent/mibgroup/agentx/subagent.h
+++ b/agent/mibgroup/agentx/subagent.h
@@ -11,14 +11,8 @@ config_require(agentx/agentx_config)
 config_error(agentx/subagent depends on the Callback transport)
 #endif

- extern int callback_master_num;
-
- extern const oid   snmptrap_oid[];
  extern const oid   snmptrapenterprise_oid[];
- extern const oid   sysuptime_oid[];
- extern 

Re: Net-SNMP 5.8.pre3 available

[Robert Story]

On Thu, 3 May 2018 21:48:50 +0100 Stuart wrote:
SH> On 2018-04-27, Robert Story  wrote:
SH> > We're closing in on a final release. The current plan is to
SH> > have release candidate 1 next week.  
SH> 
SH> Is it planned to address
SH> https://sourceforge.net/p/net-snmp/bugs/2831/ before release or
SH> are distro packagers going to need to patch the other programs
SH> to cope?

Thank you for bringing this to my attention. I will look into this.

Robert

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.pre3 available

[Stuart Henderson]

On 2018-04-27, Robert Story  wrote:
> We're closing in on a final release. The current plan is to have
> release candidate 1 next week.

Is it planned to address https://sourceforge.net/p/net-snmp/bugs/2831/
before release or are distro packagers going to need to patch the other
programs to cope?

Thanks.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Net-SNMP 5.8.pre2 available

[Robert Story]

On Mon, Mar 5, 2018 at 3:11 PM, Robert Story  wrote:

> A pre-release version of the next major Net-SNMP release is now
> available for testing. Net-SNMP 5.8.pre3 can be downloaded from:
>

This announcement had a typo. Release 5.8.pre2 (not pre3) is available.

Robert
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders