Re: Problems attempting to compile net-snmp 5.8 libs without libcrypto

[Wes Hardaker via Net-snmp-coders]

"Weiland, Nicholas"  writes:

> libnetsnmpmibs.so.35 and libnetsnmptrapd.so.35 still have links to 
> libcrypto.so.1.1
> (but not libssl.so.1.1). I would like to know if there are any configuration 
> flags I
> missed that would fix this for us, or if there is any manual hack that would 
> get
> around the issue. This was not an issue in older versions of snmp libraries 
> (namely
> we’ve used snmp 5.5). We do not use libnetsnmpmibs or libnetsnmptrapd. If 
> there is a
> way to exclude them from being built that would also solve the issue.

Is there a chance that you have them from an older build?  IE, can you
try building it from a fresh source extraction?

-- 
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: Problems attempting to compile net-snmp 5.8 libs without libcrypto

[Larry Hayes]

Not sure how to get rid of the libnetsnmpmibs.so,
But you might try the configure option: '--disable-applications' to get rid
of the libsnmptrapd.so

>From configure help:

  --disable-applications  Do not build the apps (snmpget, ...).


On Sun, Jun 13, 2021 at 10:13 AM Weiland, Nicholas 
wrote:

> Hello,
>
>
>
> We would like to compile the net snmp 5.8 libs (
> https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8/net-snmp-5.8.tar.gz/download)
> without any crypto/ssl support whatsoever. Currently I have tried the
> following configure options:
>
>   '--disable-embedded-perl',
>
> '--without-perl-modules',
>
> '--with-persistent-directory=/tmp/snmp-persistence',
>
> '--with-logfile=/var/log/snmp.log',
>
> '--with-default-snmp-version=3',
>
> '--without-openssl',
>
> '--disable-md5',
>
> '--disable-privacy',
>
> '--disable-des'
>
>
>
> The –without-openssl flag gets the build to the point where most of the
> libcrypto.so.1.1 and libssl.so.1.1 links are gone. The ones below it don’t
> seem to do anything effecting link libs.
>
>
>
> Of the following libraries --
>
> libnetsnmpagent.so.35
>
> libnetsnmphelpers.so.35
>
> libnetsnmpmibs.so.35
>
> libnetsnmp.so.35
>
> libnetsnmptrapd.so.35
>
>
>
> libnetsnmpmibs.so.35 and libnetsnmptrapd.so.35 still have links to
> libcrypto.so.1.1 (but not libssl.so.1.1). I would like to know if there are
> any configuration flags I missed that would fix this for us, or if there is
> any manual hack that would get around the issue. This was not an issue in
> older versions of snmp libraries (namely we’ve used snmp 5.5). We do not
> use libnetsnmpmibs or libnetsnmptrapd. If there is a way to exclude them
> from being built that would also solve the issue.
>
>
>
> Thank you,
>
>
>
> Nicholas Weiland
> --
>
> This electronic message and any files transmitted with it contains
> information from iDirect Government, LLC, which may be privileged,
> proprietary and/or confidential. It is intended solely for the use of the
> individual or entity to whom they are addressed. If you are not the
> original recipient or the person responsible for delivering the email to
> the intended recipient, be advised that you have received this email in
> error, and that any use, dissemination, forwarding, printing, or copying of
> this email is strictly prohibited. If you received this email in error,
> please delete it and immediately notify the sender.
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Problems attempting to compile net-snmp 5.8 libs without libcrypto

[Weiland, Nicholas]

Hello,

We would like to compile the net snmp 5.8 libs 
(https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8/net-snmp-5.8.tar.gz/download)
 without any crypto/ssl support whatsoever. Currently I have tried the 
following configure options:
  '--disable-embedded-perl',
'--without-perl-modules',
'--with-persistent-directory=/tmp/snmp-persistence',
'--with-logfile=/var/log/snmp.log',
'--with-default-snmp-version=3',
'--without-openssl',
'--disable-md5',
'--disable-privacy',
'--disable-des'

The -without-openssl flag gets the build to the point where most of the 
libcrypto.so.1.1 and libssl.so.1.1 links are gone. The ones below it don't seem 
to do anything effecting link libs.

Of the following libraries --
libnetsnmpagent.so.35
libnetsnmphelpers.so.35
libnetsnmpmibs.so.35
libnetsnmp.so.35
libnetsnmptrapd.so.35

libnetsnmpmibs.so.35 and libnetsnmptrapd.so.35 still have links to 
libcrypto.so.1.1 (but not libssl.so.1.1). I would like to know if there are any 
configuration flags I missed that would fix this for us, or if there is any 
manual hack that would get around the issue. This was not an issue in older 
versions of snmp libraries (namely we've used snmp 5.5). We do not use 
libnetsnmpmibs or libnetsnmptrapd. If there is a way to exclude them from being 
built that would also solve the issue.

Thank you,

Nicholas Weiland

--
This electronic message and any files transmitted with it contains information 
from iDirect Government, LLC, which may be privileged, proprietary and/or 
confidential. It is intended solely for the use of the individual or entity to 
whom they are addressed. If you are not the original recipient or the person 
responsible for delivering the email to the intended recipient, be advised that 
you have received this email in error, and that any use, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited. If you 
received this email in error, please delete it and immediately notify the 
sender.
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: How to use external library in net-snmp 5.8

[Wes Hardaker via Net-snmp-coders]

chandrasekharreddy chinnapareddygari 
writes:

> I want to include/ use external library is n net-snmp 5.8.
> Please help me to use external library.

Use the --with-libs configure script option.
-- 
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

How to use external library in net-snmp 5.8

[chandrasekharreddy chinnapareddygari]

Hi all,


I want to include/ use external library is n net-snmp 5.8.
Please help me to use external library.



Get Outlook for Android<https://aka.ms/ghei36>
___
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

[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

Net-SNMP 5.8 compatibility issue

[Simon Chamlian]

Hi,

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

The libcrypto has been updated to 1.1, but snmp still calls for 1.0.2
instead of using the link.



~# snmpd -v
snmpd: error while loading shared libraries: libcrypto.so.1.0.2: cannot
open shared object file: No such file or directory


# ls -l /usr/lib/libcrypto*
lrwxrwxrwx 1 root root  16 Jun 30 21:18 /usr/lib/libcrypto.so ->
libcrypto.so.1.1
-rwxr-xr-x 1 root root 2034008 Jul  6 13:01 /usr/lib/libcrypto.so.1.1
___
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

Net-SNMP 5.8 core dump

[David Moriconi (dmoricon) via Net-snmp-coders]

Hi all,
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.

Regards,

Here is the full backtrace:
=== Backtrace: =
/lib64/libc.so.6(+0x7f7c4)[0x7fb03e0637c4]
/lib64/libc.so.6(+0x82f00)[0x7fb03e066f00]
/lib64/libc.so.6(__libc_malloc+0x4c)[0x7fb03e069adc]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(snmp_clone_mem+0x45)[0x7fb03f3a3e64]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(+0x1c0fa)[0x7fb03f3a40fa]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(+0x1c47b)[0x7fb03f3a447b]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(snmp_clone_pdu+0x2c)[0x7fb03f3a4533]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmpagent.so.35(init_agent_snmp_session+0xff)[0x7fb03fc3a983]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmpagent.so.35(handle_snmp_packet+0x17a)[0x7fb03fc3c55b]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(+0x529e8)[0x7fb03f3da9e8]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(+0x52b80)[0x7fb03f3dab80]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(_sess_read+0x359)[0x7fb03f3db7ce]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(snmp_sess_read2+0x32)[0x7fb03f3dc710]
/usr/local/netsnmp/5.8.rev2c837e1/lib/libnetsnmp.so.35(snmp_read2+0x3e)[0x7fb03f3dad8a]
/usr/local/netsnmp/netsnmp_base/sbin/snmpd(+0x5084)[0x56546e196084]
/usr/local/netsnmp/netsnmp_base/sbin/snmpd(main+0x19b8)[0x56546e1958cc]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fb03e006505]
/usr/local/netsnmp/netsnmp_base/sbin/snmpd(+0x2b99)[0x56546e193b99]
=== Memory map: 
56546e191000-56546e198000 r-xp  fd:01 436216225 
/usr/local/netsnmp/5.8.rev2c837e1/sbin/snmpd
56546e397000-56546e398000 r--p 6000 fd:01 436216225 
/usr/local/netsnmp/5.8.rev2c837e1/sbin/snmpd
56546e398000-56546e399000 rw-p 7000 fd:01 436216225 
/usr/local/netsnmp/5.8.rev2c837e1/sbin/snmpd
56546e546000-56546e728000 rw-p  00:00 0 [heap]
7fb03000-7fb030021000 rw-p  00:00 0
7fb030021000-7fb03400 ---p  00:00 0
7fb03687-7fb036885000 r-xp  fd:01 25580530 
/usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fb036885000-7fb036a84000 ---p 00015000 fd:01 25580530 
/usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fb036a84000-7fb036a85000 r--p 00014000 fd:01 25580530 
/usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fb036a85000-7fb036a86000 rw-p 00015000 fd:01 25580530 
/usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fb036a86000-7fb036a8e000 r-xp  fd:01 25563045 
/usr/lib64/libnss_sss.so.2
7fb036a8e000-7fb036c8d000 ---p 8000 fd:01 25563045 
/usr/lib64/libnss_sss.so.2
7fb036c8d000-7fb036c8e000 r--p 7000 fd:01 25563045 
/usr/lib64/libnss_sss.so.2
7fb036c8e000-7fb036c8f000 rw-p 8000 fd:01 25563045 
/usr/lib64/libnss_sss.so.2
7fb036c8f000-7fb036c9b000 r-xp  fd:01 25202145 
/usr/lib64/libnss_files-2.17.so
7fb036c9b000-7fb036e9a000 ---p c000 fd:01 25202145 
/usr/lib64/libnss_files-2.17.so
7fb036e9a000-7fb036e9b000 r--p b000 fd:01 25202145 
/usr/lib64/libnss_files-2.17.so
7fb036e9b000-7fb036e9c000 rw-p c000 fd:01 25202145 
/usr/lib64/libnss_files-2.17.so
7fb036e9c000-7fb036ea2000 rw-p  00:00 0
7fb036ea2000-7fb03d3cc000 r--p  fd:01 16912899 
/usr/lib/locale/locale-archive
7fb03d3cc000-7fb03d3ce000 r-xp  fd:01 25202123 /usr/lib64/libfreebl3.so
7fb03d3ce000-7fb03d5cd000 ---p 2000 fd:01 25202123 /usr/lib64/libfreebl3.so
7fb03d5cd000-7fb03d5ce000 r--p 1000 fd:01 25202123 /usr/lib64/libfreebl3.so
7fb03d5ce000-7fb03d5cf000 rw-p 2000 fd:01 25202123 /usr/lib64/libfreebl3.so
7fb03d5cf000-7fb03d6d r-xp  fd:01 26513274 /usr/lib64/libm-2.17.so
7fb03d6d-7fb03d8cf000 ---p 00101000 fd:01 26513274 /usr/lib64/libm-2.17.so
7fb03d8cf000-7fb03d8d r--p 0010 fd:01 26513274 /usr/lib64/libm-2.17.so
7fb03d8d-7fb03d8d1000 rw-p 00101000 fd:01 26513274 /usr/lib64/libm-2.17.so
7fb03d8d1000-7fb03dbac000 r-xp  fd:01 67332135 
/usr/local/ssl/1.0.2s/lib/libcrypto.so.1.0.0
7fb03dbac000-7fb03ddab000 ---p 002db000 fd:01 67332135 
/usr/local/ssl/1.0.2s/lib/libcrypto.so.1.0.0
7fb03ddab000-7fb03ddca000 r--p 002da000 fd:01 67332135 
/usr/local/ssl/1.0.2s/lib/libcrypto.so.1.0.0
7fb03ddca000-7fb03ddd8000 rw-p 002f9000 fd:01 67332135 
/usr/local/ssl/1.0.2s/lib/libcrypto.so.1.0.0
7fb03ddd8000-7fb03dddc000 rw-p  00:00 0
7fb03dddc000-7fb03dde3000 r-xp  fd:01 25202160 /usr/lib64/librt-2.17.so
7fb03dde3000-7fb03dfe2000 ---p 7000 fd:01 25202160 /usr/lib64/librt-2.17.so
7fb03dfe2000-7fb03dfe3000 r--p 6000 fd:01 25202160 /usr/lib64/librt-2.17.so
7fb03dfe3000-7fb03dfe4000

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

NET-SNMP-5.8

[Seyfullah BECERİKLİ]

Hello,

We have some issues installing net-snmp-5.8 version. Do you have any specific 
installation guide for it?

Thanks

Saygilarimizla – Best Regards,
Seyfullah BECERİKLİ
Yazılım Mühendisi
Mühendislik ve Tasarım Direktörlüğü
[cid:image001.png@01D5BF16.87E97F30]
T T +90-850 4807744 / Ext:161 / F +90-216-2905288 /  / 
seyfullah.beceri...@ctech.com.tr
www.ctech.com.tr / Teknopark İstanbul, TGB, Sanayi Mah. Teknopark Bulvarı, No: 
1, Blok:1 K:2 Kurtköy Pendik, Istanbul / 34912 Turkey

ÖNEMLÝ NOT: Bu e-posta mesaji gizli, hassas bilgi ve ekler içerebilir. Bu 
mesaj, mesajin alici kisminda belirtilen kullanici/kullanicilara 
gönderilmistir. Eger mesaji yanlislikla almissaniz lütfen göndereni acilen 
bilgilendiriniz, mesaji ve tüm kopyalarini siliniz. Mesajdaki görüsler 
göndericiye ait olup C Tech Bil. Tek. San. ve Tic. A.S.'nin resmi görüsü olmak 
zorunda degildir.
IMPORTANT NOTICE: This email may contain confidential information and 
attachments. This email is intended for the use of the addressee only. If you 
receive this email by mistake, please advise the sender immediately and delete 
the email and any copies of it.  Any opinions presented in this e-mail message 
are solely those of the author and do not necessarily represent C Tech Bil. 
Tek. San. ve Tic.A.S.'s formal and authorized views.

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

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart Van Assche]

On 5/13/19 12:10 PM, Vijay, Anjali wrote:
Thanks for the help. Meanwhile, I had changed the buffer size back to 
1472 and it seems to be working fine like the previous version, net-snmp 
5.7.3. Do you think this can cause any serious impact?


Hi Anjali,

I think that approach is risky. It's easy for an SNMP manager to send an 
snmp get, getnext or getbulk request with multiple OIDs. Even if the 
request fits in a 1472 byte network packet, the response may exceed that 
packet size. Unless if you know from beforehand what kind of requests 
the SNMP manager(s) will send and if you know from beforehand what the 
maximum string length will be, I think it's safe to use a larger buffer 
size.


Bart.


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

RE: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, Anjali]

Hi Bart,

Thanks for the help. Meanwhile, I had changed the buffer size back to 1472 and 
it seems to be working fine like the previous version, net-snmp 5.7.3. Do you 
think this can cause any serious impact?

Regards,
Anjali Vijay

From: Bart Van Assche 
Sent: Sunday, April 28, 2019 3:39 AM
To: Vijay, Anjali ; net-snmp-coders@lists.sourceforge.net
Subject: Re: To understand the increase in size of buffer in agentx_parse() in 
net-snmp-5.8

On 4/25/19 5:56 PM, Bart Van Assche wrote:
On 4/25/19 8:00 AM, Vijay, Anjali wrote:
I recently started working with net-snmp-5.8. I had a query over a change that 
was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that 
the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced 
with the size 65536 in net-snmp-5.8.

u_char buffer[65536];

I didn't find any clarification in the ChangeLogs for this large increase of 
size. Can this size be reduced? It would be of great help if anyone can clear 
me out on this since my application has memory constraints.

Hi Anjali,

I will have a look and see whether it is possible to modify the AgentX code 
without reducing performance and without dropping support for large AgentX 
packets. BTW, the following commit increased the buffer size:

c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet size to 64kB.")

Hi Anjali,

A candidate fix has been checked in on the v5.8 and master branches. Please 
verify.

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

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, Anjali]

Thanks Bart !!


Regards,

Anjali S. Vijay



From: Bart Van Assche 
Sent: Sunday, April 28, 2019 3:38 AM
To: Vijay, Anjali; net-snmp-coders@lists.sourceforge.net
Subject: Re: To understand the increase in size of buffer in agentx_parse() in 
net-snmp-5.8

On 4/25/19 5:56 PM, Bart Van Assche wrote:
On 4/25/19 8:00 AM, Vijay, Anjali wrote:

I recently started working with net-snmp-5.8. I had a query over a change that 
was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that 
the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced 
with the size 65536 in net-snmp-5.8.



u_char buffer[65536];



I didn’t find any clarification in the ChangeLogs for this large increase of 
size. Can this size be reduced? It would be of great help if anyone can clear 
me out on this since my application has memory constraints.

Hi Anjali,

I will have a look and see whether it is possible to modify the AgentX code 
without reducing performance and without dropping support for large AgentX 
packets. BTW, the following commit increased the buffer size:

c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet size to 64kB.")

Hi Anjali,

A candidate fix has been checked in on the v5.8 and master branches. Please 
verify.

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

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart Van Assche]

  
  
On 4/25/19 5:56 PM, Bart Van Assche
  wrote:


  
  On 4/25/19 8:00 AM, Vijay, Anjali
wrote:
  
  




  I recently started working with
net-snmp-5.8. I had a query over a change that was made to
agentx_parse() in agent/mibgroup/agentx/protocol.c. I
noticed that the buffer of  SNMP_MAX_MSG_SIZE (1472) in
net-snmp-5.7.3 has been replaced with the size 65536 in
net-snmp-5.8. 
   
  u_char buffer[65536];
   
  I didn’t find any clarification in the
ChangeLogs for this large increase of size. Can this size be
reduced? It would be of great help if anyone can clear me
out on this since my application has memory constraints.

  
  Hi Anjali,
  I will have a look and see whether it is possible to modify the
AgentX code without reducing performance and without dropping
support for large AgentX packets. BTW, the following commit
increased the buffer size:
  
  c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet
size to 64kB.")

Hi Anjali,
A candidate fix has been checked in on the v5.8 and master
  branches. Please verify.
Bart.

  


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

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Bart Van Assche]

  
  
On 4/25/19 8:00 AM, Vijay, Anjali
  wrote:


  
  
  
  
I recently started working with
  net-snmp-5.8. I had a query over a change that was made to
  agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed
  that the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3
  has been replaced with the size 65536 in net-snmp-5.8. 
 
u_char buffer[65536];
 
I didn’t find any clarification in the
  ChangeLogs for this large increase of size. Can this size be
  reduced? It would be of great help if anyone can clear me out
  on this since my application has memory constraints.
  

Hi Anjali,
I will have a look and see whether it is possible to modify the
  AgentX code without reducing performance and without dropping
  support for large AgentX packets. BTW, the following commit
  increased the buffer size:

c09140c934eb ("CHANGES: snmpd: Increase maximum AgentX packet
  size to 64kB.")

Bart.

  


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

To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

[Vijay, Anjali]

Hi,

I recently started working with net-snmp-5.8. I had a query over a change that 
was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that 
the buffer of  SNMP_MAX_MSG_SIZE (1472) in net-snmp-5.7.3 has been replaced 
with the size 65536 in net-snmp-5.8.

u_char buffer[65536];

I didn't find any clarification in the ChangeLogs for this large increase of 
size. Can this size be reduced? It would be of great help if anyone can clear 
me out on this since my application has memory constraints.

Thanks,
Anjali S. Vijay

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

Re: Core dump with net-snmp-5.8

[Anders Wallin]

19-04-08 16:29:15 TLS error: SSL_read: rc=-1, sslerror = 5
>>>> > (SSL_ERROR_SYSCALL): system_error=0 (Success)
>>>> > 2019-04-08 16:29:15 TLS Error: (null)
>>>> > 2019-04-08 16:29:16  OpenSSL Related Errors: 
>>>> > 2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
>>>> > (SSL_ERROR_SYSCALL): system_error=0 (Success)
>>>> > 2019-04-08 16:29:16 TLS Error: (null)
>>>> > 2019-04-08 16:29:16  OpenSSL Related Errors: 
>>>> > 2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
>>>> > (SSL_ERROR_SYSCALL): system_error=0 (Success)
>>>> > 2019-04-08 16:29:16 TLS Error: (null)
>>>> >
>>>> > With the fix suggested på Josef I don't see the DTLSUDP problem, but
>>>> maybe
>>>> > there are other problems.
>>>> >
>>>> > Regards
>>>> > Anders Wallin
>>>> >
>>>> > PS. thx for adding commit info to a420d87d3, I updated the patch with
>>>> your
>>>> > commit comments
>>>> >
>>>> >
>>>> > On Mon, Apr 8, 2019 at 3:27 PM Masayoshi Mizuma <
>>>> msys.miz...@gmail.com>
>>>> > wrote:
>>>> >
>>>> >> Hi Josef,
>>>> >>
>>>> >> I attach two patches to fix the memory inconsistency if the request
>>>> is
>>>> >> resend and timed out.
>>>> >> Could you try them?
>>>> >>
>>>> >> - 0001-agentx-master-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch
>>>> >>
>>>> >>   This patch was posted by Anders, and I tried to add the
>>>> description.
>>>> >>   This patch fixes the missing NETSNMP_CALLBACK_OP_RESEND callback.
>>>> >>
>>>> >> - 0002-snmplib-snmp_api-Remove-the-request-on-the-session-w.patch
>>>> >>
>>>> >>   This patch fixes the race between NETSNMP_CALLBACK_OP_SEND_FAILED
>>>> >>   and NETSNMP_CALLBACK_OP_TIMED_OUT callback. If the request is
>>>> failed,
>>>> >>   then remove the request from the internal session.
>>>> >>
>>>> >> Thanks,
>>>> >> Masa
>>>> >>
>>>> >> On 4/3/19 9:34 AM, Anders Wallin wrote:
>>>> >>> The introduction of that code fixes another issue;
>>>> >>> "commit 56c30b11f3616ea4f0c38a21e08e78f050096020
>>>> >>> Author: Bill Fenner 
>>>> >>> Date:   Wed Dec 20 21:52:10 2017 +
>>>> >>>
>>>> >>> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad
>>>> SNMPv3
>>>> >>> agent
>>>> >>>
>>>> >>> With the patch in 1214, the snmp_api code assumed that if magic
>>>> was
>>>> >>> set, it was the "struct synch-state" from snmp_client.  Of
>>>> course,
>>>> >>> magic belongs to the caller, and the perl library uses it
>>>> >> differently,
>>>> >>> so reaching into it is verboten.  Introduce a new callback (that
>>>> >>> was already introduced in 5.8) to report this "retries exceeded"
>>>> >>> state, and use it in snmp_client."
>>>> >>>
>>>> >>> I think the problem is really about shutting down the agentx
>>>> connection
>>>> >>> when one(1) response is to late. I have
>>>> >>> done 2 patches (one that only write a better log message and one
>>>> that
>>>> >>> removes the "bad" code.
>>>> >>> With these patches I don't get any crash. I think that 5.7.3 has
>>>> this
>>>> >> issue
>>>> >>> as well, but it can not be crashed with the agentofdead code
>>>> >>>
>>>> >>> Can you please try this?
>>>> >>>
>>>> >>> Regards
>>>> >>> Anders Wallin
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky 
>>>> wrote:
>>>> >>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found,
>&g

Re: Core dump with net-snmp-5.8

[Josef Ridky]

Hi folks,

thanks for your solution, I have tested it internally and all works as expected.
I hope, this will be soon part of net-snmp-5.8.

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

- Original Message -
| From: "Anders Wallin" 
| To: "Masayoshi Mizuma" 
| Cc: "Josef Ridky" , "Net-SNMP Coders" 

| Sent: Tuesday, April 9, 2019 12:54:09 PM
| Subject: Re: Core dump with net-snmp-5.8
| 
| Now it works fine!
| 
| thx
| Anders Wallin
| 
| 
| On Tue, Apr 9, 2019 at 2:26 AM Masayoshi Mizuma 
| wrote:
| 
| > Hi Anders,
| >
| > Thank you for your feedback!
| > I attach the v2 patch. Could you try it?
| >
| > On the v1 patch, I missed the check for the request callback. So, the
| > request
| > gets removed even though the callback doesn't run.
| >
| > Thanks,
| > Masa
| >
| > On 4/8/19 11:06 AM, Anders Wallin wrote:
| > > Hi Masa,
| > >
| > > looks like it solves the problem reported by Josef, BUT it breaks
| > DTLSUDP.
| > > I run the tests w/o analyzing why.
| > > To reproduce the issue I did the following using net-snmp master branch,
| > > plus these patches
| > > 39485c6f2 - snmplib/snmp_api: Remove the request on the session when the
| > > sending is failed (10 minutes ago) 
| > > 06a4d52d8 - agentx: logging to late responses (5 days ago)  Wallin>
| > > a420d87d3 - BUG2914: Agent master needs to treat resend as normal (5 days
| > > ago) 
| > > eaad09d04 - (origin/master, origin/HEAD, master) Merge branch
| > > 'V5-8-patches' (9 weeks ago) 
| > >
| > > $ ./configure --prefix=/usr \
| > > --with-persistent-directory=/var/lib/net-snmp \
| > > --with-mib-modules='smux tlstm-mib tsm-mib
| > examples/example
| > > examples/notification' \
| > > --with-security-modules="tsm" \
| > > --with-transports="TLSTCP DTLSUDP" \
| > > --enable-shared \
| > > --with-defaults \
| > > --enable-ipv6 \
| > > --with-cflags="-g -O2" \
| > > --without-elf
| > >
| > > $ make install
| > > $ cd testing
| > > $ ./RUNFULLTESTS -g tls
| > > DTLS-UDP user certificate tests .. 41/?
| > >  This hangs forever in "41" with snmpd.log saying
| > > ..
| > > 2019-04-08 16:29:11
| > > 2019-04-08 16:29:11
| > > Received 0 byte packet from DTLSUDP: unknown
| > > 2019-04-08 16:29:11
| > > 2019-04-08 16:29:13
| > > Received 0 byte packet from DTLSUDP: unknown
| > > 2019-04-08 16:29:13
| > > 2019-04-08 16:29:15
| > > Received 0 byte packet from DTLSUDP: unknown
| > > 2019-04-08 16:29:15
| > > 2019-04-08 16:29:15 tls verification failure: ok=0 ctx=0x55ee625b4170
| > > depth=0 err=18:self signed certificate
| > > 2019-04-08 16:29:15  OpenSSL Related Errors: 
| > > 2019-04-08 16:29:15  TLS error: SSL_read: rc=-1, sslerror = 1
| > > (SSL_ERROR_SSL)
| > > 2019-04-08 16:29:15  TLS Error: certificate verify failed
| > > 2019-04-08 16:29:15  End of OpenSSL Errors 
| > > 2019-04-08 16:29:15  OpenSSL Related Errors: 
| > > 2019-04-08 16:29:15 TLS error: SSL_read: rc=-1, sslerror = 5
| > > (SSL_ERROR_SYSCALL): system_error=0 (Success)
| > > 2019-04-08 16:29:15 TLS Error: (null)
| > > 2019-04-08 16:29:16  OpenSSL Related Errors: 
| > > 2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
| > > (SSL_ERROR_SYSCALL): system_error=0 (Success)
| > > 2019-04-08 16:29:16 TLS Error: (null)
| > > 2019-04-08 16:29:16  OpenSSL Related Errors: 
| > > 2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
| > > (SSL_ERROR_SYSCALL): system_error=0 (Success)
| > > 2019-04-08 16:29:16 TLS Error: (null)
| > >
| > > With the fix suggested på Josef I don't see the DTLSUDP problem, but
| > maybe
| > > there are other problems.
| > >
| > > Regards
| > > Anders Wallin
| > >
| > > PS. thx for adding commit info to a420d87d3, I updated the patch with
| > your
| > > commit comments
| > >
| > >
| > > On Mon, Apr 8, 2019 at 3:27 PM Masayoshi Mizuma 
| > > wrote:
| > >
| > >> Hi Josef,
| > >>
| > >> I attach two patches to fix the memory inconsistency if the request is
| > >> resend and timed out.
| > >> Could you try them?
| > >>
| > >> - 0001-agentx-master-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch
| > >>
| > >>   This patch was posted by Anders, and I tried to 

Re: Core dump with net-snmp-5.8

[Sam Tannous]

Success)
>>> > 2019-04-08 16:29:16 TLS Error: (null)
>>> >
>>> > With the fix suggested på Josef I don't see the DTLSUDP problem, but
>>> maybe
>>> > there are other problems.
>>> >
>>> > Regards
>>> > Anders Wallin
>>> >
>>> > PS. thx for adding commit info to a420d87d3, I updated the patch with
>>> your
>>> > commit comments
>>> >
>>> >
>>> > On Mon, Apr 8, 2019 at 3:27 PM Masayoshi Mizuma >> >
>>> > wrote:
>>> >
>>> >> Hi Josef,
>>> >>
>>> >> I attach two patches to fix the memory inconsistency if the request is
>>> >> resend and timed out.
>>> >> Could you try them?
>>> >>
>>> >> - 0001-agentx-master-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch
>>> >>
>>> >>   This patch was posted by Anders, and I tried to add the description.
>>> >>   This patch fixes the missing NETSNMP_CALLBACK_OP_RESEND callback.
>>> >>
>>> >> - 0002-snmplib-snmp_api-Remove-the-request-on-the-session-w.patch
>>> >>
>>> >>   This patch fixes the race between NETSNMP_CALLBACK_OP_SEND_FAILED
>>> >>   and NETSNMP_CALLBACK_OP_TIMED_OUT callback. If the request is
>>> failed,
>>> >>   then remove the request from the internal session.
>>> >>
>>> >> Thanks,
>>> >> Masa
>>> >>
>>> >> On 4/3/19 9:34 AM, Anders Wallin wrote:
>>> >>> The introduction of that code fixes another issue;
>>> >>> "commit 56c30b11f3616ea4f0c38a21e08e78f050096020
>>> >>> Author: Bill Fenner 
>>> >>> Date:   Wed Dec 20 21:52:10 2017 +
>>> >>>
>>> >>> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad
>>> SNMPv3
>>> >>> agent
>>> >>>
>>> >>> With the patch in 1214, the snmp_api code assumed that if magic
>>> was
>>> >>> set, it was the "struct synch-state" from snmp_client.  Of
>>> course,
>>> >>> magic belongs to the caller, and the perl library uses it
>>> >> differently,
>>> >>> so reaching into it is verboten.  Introduce a new callback (that
>>> >>> was already introduced in 5.8) to report this "retries exceeded"
>>> >>> state, and use it in snmp_client."
>>> >>>
>>> >>> I think the problem is really about shutting down the agentx
>>> connection
>>> >>> when one(1) response is to late. I have
>>> >>> done 2 patches (one that only write a better log message and one that
>>> >>> removes the "bad" code.
>>> >>> With these patches I don't get any crash. I think that 5.7.3 has this
>>> >> issue
>>> >>> as well, but it can not be crashed with the agentofdead code
>>> >>>
>>> >>> Can you please try this?
>>> >>>
>>> >>> Regards
>>> >>> Anders Wallin
>>> >>>
>>> >>>
>>> >>> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky 
>>> wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found,
>>> that
>>> >>>> following callbacks in snmplib/snmp_api.c causes the core dump
>>> issue:
>>> >>>>
>>> >>>> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
>>> >>>> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
>>> >>>> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
>>> >>>>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
>>> >>>>  sp->s_errno = errno;
>>> >>>>  snmp_set_detail(strerror(errno));
>>> >>>> -if (rp->callback)
>>> >>>> +/*if (rp->callback)
>>> >>>>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
>>> >>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>>> >>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/

Re: Core dump with net-snmp-5.8

[Sam Tannous]

er-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch
>> >>
>> >>   This patch was posted by Anders, and I tried to add the description.
>> >>   This patch fixes the missing NETSNMP_CALLBACK_OP_RESEND callback.
>> >>
>> >> - 0002-snmplib-snmp_api-Remove-the-request-on-the-session-w.patch
>> >>
>> >>   This patch fixes the race between NETSNMP_CALLBACK_OP_SEND_FAILED
>> >>   and NETSNMP_CALLBACK_OP_TIMED_OUT callback. If the request is failed,
>> >>   then remove the request from the internal session.
>> >>
>> >> Thanks,
>> >> Masa
>> >>
>> >> On 4/3/19 9:34 AM, Anders Wallin wrote:
>> >>> The introduction of that code fixes another issue;
>> >>> "commit 56c30b11f3616ea4f0c38a21e08e78f050096020
>> >>> Author: Bill Fenner 
>> >>> Date:   Wed Dec 20 21:52:10 2017 +
>> >>>
>> >>> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad
>> SNMPv3
>> >>> agent
>> >>>
>> >>> With the patch in 1214, the snmp_api code assumed that if magic
>> was
>> >>> set, it was the "struct synch-state" from snmp_client.  Of course,
>> >>> magic belongs to the caller, and the perl library uses it
>> >> differently,
>> >>> so reaching into it is verboten.  Introduce a new callback (that
>> >>> was already introduced in 5.8) to report this "retries exceeded"
>> >>> state, and use it in snmp_client."
>> >>>
>> >>> I think the problem is really about shutting down the agentx
>> connection
>> >>> when one(1) response is to late. I have
>> >>> done 2 patches (one that only write a better log message and one that
>> >>> removes the "bad" code.
>> >>> With these patches I don't get any crash. I think that 5.7.3 has this
>> >> issue
>> >>> as well, but it can not be crashed with the agentofdead code
>> >>>
>> >>> Can you please try this?
>> >>>
>> >>> Regards
>> >>> Anders Wallin
>> >>>
>> >>>
>> >>> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky 
>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found,
>> that
>> >>>> following callbacks in snmplib/snmp_api.c causes the core dump issue:
>> >>>>
>> >>>> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
>> >>>> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
>> >>>> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
>> >>>>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
>> >>>>  sp->s_errno = errno;
>> >>>>  snmp_set_detail(strerror(errno));
>> >>>> -if (rp->callback)
>> >>>> +/*if (rp->callback)
>> >>>>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
>> >>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>> >>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>> >>>>  return -1;
>> >>>>  } else {
>> >>>>  netsnmp_get_monotonic_clock();
>> >>>> @@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
>> >>>>  tv.tv_sec += tv.tv_usec / 100L;
>> >>>>  tv.tv_usec %= 100L;
>> >>>>  rp->expireM = tv;
>> >>>> -if (rp->callback)
>> >>>> +/*if (rp->callback)
>> >>>>  rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
>> >>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>> >>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>> >>>>  }
>> >>>>  return 0;
>> >>>>  }
>> >>>>
>> >>>> Without them, all works as expected.
>> >>>>
>> >>>> Josef Ridky
>> >>>> Software Engineer
>> >>>> Core Services Team
>> >>>> Red Hat Czech, s.r

Re: Core dump with net-snmp-5.8

[Anders Wallin]

c38a21e08e78f050096020
> >>> Author: Bill Fenner 
> >>> Date:   Wed Dec 20 21:52:10 2017 +
> >>>
> >>> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3
> >>> agent
> >>>
> >>> With the patch in 1214, the snmp_api code assumed that if magic was
> >>> set, it was the "struct synch-state" from snmp_client.  Of course,
> >>>     magic belongs to the caller, and the perl library uses it
> >> differently,
> >>> so reaching into it is verboten.  Introduce a new callback (that
> >>> was already introduced in 5.8) to report this "retries exceeded"
> >>> state, and use it in snmp_client."
> >>>
> >>> I think the problem is really about shutting down the agentx connection
> >>> when one(1) response is to late. I have
> >>> done 2 patches (one that only write a better log message and one that
> >>> removes the "bad" code.
> >>> With these patches I don't get any crash. I think that 5.7.3 has this
> >> issue
> >>> as well, but it can not be crashed with the agentofdead code
> >>>
> >>> Can you please try this?
> >>>
> >>> Regards
> >>> Anders Wallin
> >>>
> >>>
> >>> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found, that
> >>>> following callbacks in snmplib/snmp_api.c causes the core dump issue:
> >>>>
> >>>> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
> >>>> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
> >>>> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
> >>>>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
> >>>>  sp->s_errno = errno;
> >>>>          snmp_set_detail(strerror(errno));
> >>>> -if (rp->callback)
> >>>> +/*if (rp->callback)
> >>>>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
> >>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
> >>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
> >>>>  return -1;
> >>>>  } else {
> >>>>  netsnmp_get_monotonic_clock();
> >>>> @@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
> >>>>  tv.tv_sec += tv.tv_usec / 100L;
> >>>>  tv.tv_usec %= 100L;
> >>>>  rp->expireM = tv;
> >>>> -if (rp->callback)
> >>>> +/*if (rp->callback)
> >>>>  rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
> >>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
> >>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
> >>>>  }
> >>>>  return 0;
> >>>>  }
> >>>>
> >>>> Without them, all works as expected.
> >>>>
> >>>> Josef Ridky
> >>>> Software Engineer
> >>>> Core Services Team
> >>>> Red Hat Czech, s.r.o.
> >>>>
> >>>> - Original Message -
> >>>> | From: "Anders Wallin" 
> >>>> | To: "Josef Ridky" 
> >>>> | Cc: "net-snmp-coders" 
> >>>> | Sent: Tuesday, April 2, 2019 6:27:54 PM
> >>>> | Subject: Re: Core dump with net-snmp-5.8
> >>>> |
> >>>> | Hi Josef,
> >>>> | I can reproduce the issue using the master branch, I will take a
> look
> >> at
> >>>> it
> >>>> | later tonight or tomorrow
> >>>> |
> >>>> | Regards
> >>>> | Anders Wallin
> >>>> |
> >>>> |
> >>>> | On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky 
> wrote:
> >>>> |
> >>>> | > Hi,
> >>>> | >
> >>>> | > thanks for your patch. Unfortunately, even when I have applied it,
> >> it
> >>>> | > still ends with core dump due of 'double free or corruption
> >> (fasttop)'
> >>>> | >
> >

Re: Core dump with net-snmp-5.8

[Masayoshi Mizuma]

eeded"
>>> state, and use it in snmp_client."
>>>
>>> I think the problem is really about shutting down the agentx connection
>>> when one(1) response is to late. I have
>>> done 2 patches (one that only write a better log message and one that
>>> removes the "bad" code.
>>> With these patches I don't get any crash. I think that 5.7.3 has this
>> issue
>>> as well, but it can not be crashed with the agentofdead code
>>>
>>> Can you please try this?
>>>
>>> Regards
>>> Anders Wallin
>>>
>>>
>>> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky  wrote:
>>>
>>>> Hi,
>>>>
>>>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found, that
>>>> following callbacks in snmplib/snmp_api.c causes the core dump issue:
>>>>
>>>> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
>>>> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
>>>> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
>>>>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
>>>>  sp->s_errno = errno;
>>>>  snmp_set_detail(strerror(errno));
>>>> -if (rp->callback)
>>>> +/*if (rp->callback)
>>>>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
>>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>>>>  return -1;
>>>>  } else {
>>>>  netsnmp_get_monotonic_clock();
>>>> @@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
>>>>  tv.tv_sec += tv.tv_usec / 100L;
>>>>  tv.tv_usec %= 100L;
>>>>  rp->expireM = tv;
>>>> -if (rp->callback)
>>>> +/*if (rp->callback)
>>>>  rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
>>>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>>>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>>>>  }
>>>>  return 0;
>>>>  }
>>>>
>>>> Without them, all works as expected.
>>>>
>>>> Josef Ridky
>>>> Software Engineer
>>>> Core Services Team
>>>> Red Hat Czech, s.r.o.
>>>>
>>>> - Original Message -
>>>> | From: "Anders Wallin" 
>>>> | To: "Josef Ridky" 
>>>> | Cc: "net-snmp-coders" 
>>>> | Sent: Tuesday, April 2, 2019 6:27:54 PM
>>>> | Subject: Re: Core dump with net-snmp-5.8
>>>> |
>>>> | Hi Josef,
>>>> | I can reproduce the issue using the master branch, I will take a look
>> at
>>>> it
>>>> | later tonight or tomorrow
>>>> |
>>>> | Regards
>>>> | Anders Wallin
>>>> |
>>>> |
>>>> | On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky  wrote:
>>>> |
>>>> | > Hi,
>>>> | >
>>>> | > thanks for your patch. Unfortunately, even when I have applied it,
>> it
>>>> | > still ends with core dump due of 'double free or corruption
>> (fasttop)'
>>>> | >
>>>> | > When I run snmpd with -Dsnmp_agent,agentx/master it ends with:
>>>> | >
>>>> | > agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
>>>> | > snmp_agent: delegate session == 0x56207e165240
>>>> | > snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
>>>> | > agentx/master: callback resend
>>>> | > agentx/master: callback resend
>>>> | > agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
>>>> | > agentx/master: close 0x56207dfd5400, -1
>>>> | > snmp_agent: removed 40 delegated request(s) for session
>> 0x56207dfce490
>>>> | > snmp_agent: processing delegated request, asp = 0x56207e165240
>>>> | > snmp_agent: canceling next walk for asp 0x56207e165240
>>>> | > snmp_agent: REMOVE session == 0x56207e165240
>>>> | > snmp_agent: agent_session 0x56207e165240 released
>>>> | > snmp_agent: processing delegated request, asp = 0x56207e1041a0
>>>> | > snmp_agent: canceling next walk for as

Re: Core dump with net-snmp-5.8

[Anders Wallin]

Hi Masa,

looks like it solves the problem reported by Josef, BUT it breaks DTLSUDP.
I run the tests w/o analyzing why.
To reproduce the issue I did the following using net-snmp master branch,
plus these patches
39485c6f2 - snmplib/snmp_api: Remove the request on the session when the
sending is failed (10 minutes ago) 
06a4d52d8 - agentx: logging to late responses (5 days ago) 
a420d87d3 - BUG2914: Agent master needs to treat resend as normal (5 days
ago) 
eaad09d04 - (origin/master, origin/HEAD, master) Merge branch
'V5-8-patches' (9 weeks ago) 

$ ./configure --prefix=/usr \
--with-persistent-directory=/var/lib/net-snmp \
--with-mib-modules='smux tlstm-mib tsm-mib examples/example
examples/notification' \
--with-security-modules="tsm" \
--with-transports="TLSTCP DTLSUDP" \
--enable-shared \
--with-defaults \
--enable-ipv6 \
--with-cflags="-g -O2" \
--without-elf

$ make install
$ cd testing
$ ./RUNFULLTESTS -g tls
DTLS-UDP user certificate tests .. 41/?
 This hangs forever in "41" with snmpd.log saying
..
2019-04-08 16:29:11
2019-04-08 16:29:11
Received 0 byte packet from DTLSUDP: unknown
2019-04-08 16:29:11
2019-04-08 16:29:13
Received 0 byte packet from DTLSUDP: unknown
2019-04-08 16:29:13
2019-04-08 16:29:15
Received 0 byte packet from DTLSUDP: unknown
2019-04-08 16:29:15
2019-04-08 16:29:15 tls verification failure: ok=0 ctx=0x55ee625b4170
depth=0 err=18:self signed certificate
2019-04-08 16:29:15  OpenSSL Related Errors: 
2019-04-08 16:29:15  TLS error: SSL_read: rc=-1, sslerror = 1
(SSL_ERROR_SSL)
2019-04-08 16:29:15  TLS Error: certificate verify failed
2019-04-08 16:29:15  End of OpenSSL Errors 
2019-04-08 16:29:15  OpenSSL Related Errors: 
2019-04-08 16:29:15 TLS error: SSL_read: rc=-1, sslerror = 5
(SSL_ERROR_SYSCALL): system_error=0 (Success)
2019-04-08 16:29:15 TLS Error: (null)
2019-04-08 16:29:16  OpenSSL Related Errors: 
2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
(SSL_ERROR_SYSCALL): system_error=0 (Success)
2019-04-08 16:29:16 TLS Error: (null)
2019-04-08 16:29:16  OpenSSL Related Errors: 
2019-04-08 16:29:16 TLS error: SSL_read: rc=-1, sslerror = 5
(SSL_ERROR_SYSCALL): system_error=0 (Success)
2019-04-08 16:29:16 TLS Error: (null)

With the fix suggested på Josef I don't see the DTLSUDP problem, but maybe
there are other problems.

Regards
Anders Wallin

PS. thx for adding commit info to a420d87d3, I updated the patch with your
commit comments


On Mon, Apr 8, 2019 at 3:27 PM Masayoshi Mizuma 
wrote:

> Hi Josef,
>
> I attach two patches to fix the memory inconsistency if the request is
> resend and timed out.
> Could you try them?
>
> - 0001-agentx-master-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch
>
>   This patch was posted by Anders, and I tried to add the description.
>   This patch fixes the missing NETSNMP_CALLBACK_OP_RESEND callback.
>
> - 0002-snmplib-snmp_api-Remove-the-request-on-the-session-w.patch
>
>   This patch fixes the race between NETSNMP_CALLBACK_OP_SEND_FAILED
>   and NETSNMP_CALLBACK_OP_TIMED_OUT callback. If the request is failed,
>   then remove the request from the internal session.
>
> Thanks,
> Masa
>
> On 4/3/19 9:34 AM, Anders Wallin wrote:
> > The introduction of that code fixes another issue;
> > "commit 56c30b11f3616ea4f0c38a21e08e78f050096020
> > Author: Bill Fenner 
> > Date:   Wed Dec 20 21:52:10 2017 +
> >
> > NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3
> > agent
> >
> > With the patch in 1214, the snmp_api code assumed that if magic was
> > set, it was the "struct synch-state" from snmp_client.  Of course,
> > magic belongs to the caller, and the perl library uses it
> differently,
> > so reaching into it is verboten.  Introduce a new callback (that
> > was already introduced in 5.8) to report this "retries exceeded"
> > state, and use it in snmp_client."
> >
> > I think the problem is really about shutting down the agentx connection
> > when one(1) response is to late. I have
> > done 2 patches (one that only write a better log message and one that
> > removes the "bad" code.
> > With these patches I don't get any crash. I think that 5.7.3 has this
> issue
> > as well, but it can not be crashed with the agentofdead code
> >
> > Can you please try this?
> >
> > Regards
> > Anders Wallin
> >
> >
> > On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky  wrote:
> >
> >> Hi,
> >>
> >> I have compared net-snmp-5.7.3 and net

Re: Core dump with net-snmp-5.8

[Masayoshi Mizuma]

Hi Josef,

I attach two patches to fix the memory inconsistency if the request is
resend and timed out. 
Could you try them?

- 0001-agentx-master-Return-when-NETSNMP_CALLBACK_OP_RESEND.patch

  This patch was posted by Anders, and I tried to add the description.
  This patch fixes the missing NETSNMP_CALLBACK_OP_RESEND callback.

- 0002-snmplib-snmp_api-Remove-the-request-on-the-session-w.patch

  This patch fixes the race between NETSNMP_CALLBACK_OP_SEND_FAILED 
  and NETSNMP_CALLBACK_OP_TIMED_OUT callback. If the request is failed,
  then remove the request from the internal session.

Thanks,
Masa

On 4/3/19 9:34 AM, Anders Wallin wrote:
> The introduction of that code fixes another issue;
> "commit 56c30b11f3616ea4f0c38a21e08e78f050096020
> Author: Bill Fenner 
> Date:   Wed Dec 20 21:52:10 2017 +
> 
> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3
> agent
> 
> With the patch in 1214, the snmp_api code assumed that if magic was
> set, it was the "struct synch-state" from snmp_client.  Of course,
> magic belongs to the caller, and the perl library uses it differently,
> so reaching into it is verboten.  Introduce a new callback (that
> was already introduced in 5.8) to report this "retries exceeded"
> state, and use it in snmp_client."
> 
> I think the problem is really about shutting down the agentx connection
> when one(1) response is to late. I have
> done 2 patches (one that only write a better log message and one that
> removes the "bad" code.
> With these patches I don't get any crash. I think that 5.7.3 has this issue
> as well, but it can not be crashed with the agentofdead code
> 
> Can you please try this?
> 
> Regards
> Anders Wallin
> 
> 
> On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky  wrote:
> 
>> Hi,
>>
>> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found, that
>> following callbacks in snmplib/snmp_api.c causes the core dump issue:
>>
>> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
>> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
>> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
>>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
>>  sp->s_errno = errno;
>>  snmp_set_detail(strerror(errno));
>> -if (rp->callback)
>> +/*if (rp->callback)
>>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>>  return -1;
>>  } else {
>>  netsnmp_get_monotonic_clock();
>> @@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
>>  tv.tv_sec += tv.tv_usec / 100L;
>>  tv.tv_usec %= 100L;
>>  rp->expireM = tv;
>> -if (rp->callback)
>> +/*if (rp->callback)
>>  rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
>> - rp->pdu->reqid, rp->pdu, rp->cb_data);
>> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>>  }
>>  return 0;
>>  }
>>
>> Without them, all works as expected.
>>
>> Josef Ridky
>> Software Engineer
>> Core Services Team
>> Red Hat Czech, s.r.o.
>>
>> - Original Message -
>> | From: "Anders Wallin" 
>> | To: "Josef Ridky" 
>> | Cc: "net-snmp-coders" 
>> | Sent: Tuesday, April 2, 2019 6:27:54 PM
>> | Subject: Re: Core dump with net-snmp-5.8
>> |
>> | Hi Josef,
>> | I can reproduce the issue using the master branch, I will take a look at
>> it
>> | later tonight or tomorrow
>> |
>> | Regards
>> | Anders Wallin
>> |
>> |
>> | On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky  wrote:
>> |
>> | > Hi,
>> | >
>> | > thanks for your patch. Unfortunately, even when I have applied it, it
>> | > still ends with core dump due of 'double free or corruption (fasttop)'
>> | >
>> | > When I run snmpd with -Dsnmp_agent,agentx/master it ends with:
>> | >
>> | > agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
>> | > snmp_agent: delegate session == 0x56207e165240
>> | > snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
>> | > agentx/master: callback resend
>> | > agentx/master: callback resend
>> | > agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
>> | > agent

RE: Core dump with net-snmp-5.8

[Matsumoto, Shogo]

Hi,

> I will check, but it will be tomorrow
>I don't know how I read the code last time, I was referring to the wrong 
>commit where the code was introduced, it was introduced with
>"commit b7b50bbac7f21a924149d03da26ff0a44b25ec60

Thank you for your response.

I share steps to reproduce the issue just to be sure.


0.  extract files from reproducer.tar.gz

1.  deploy snmpd.conf

2.  start snmpd

3.  make (to generate sub_agent)

4.  ./sub_agent &

5.  pkill -STOP -x sub_agent

6.  snmpwalk -v2c -c "public" 127.0.0.1 .1.3.6.1.4.1.9 -Ona

Regards,
Shogo Matsumoto


From: Anders Wallin [mailto:walli...@gmail.com]
Sent: Thursday, April 4, 2019 8:37 PM
To: shogo.matsum...@jp.fujitsu.com<mailto:shogo.matsum...@jp.fujitsu.com>
Cc: 
net-snmp-coders@lists.sourceforge.net<mailto:net-snmp-coders@lists.sourceforge.net>
Subject: Re: Core dump with net-snmp-5.8

I will check, but it will be tomorrow
I don't know how I read the code last time, I was referring to the wrong commit 
where the code was introduced, it was introduced with
"commit b7b50bbac7f21a924149d03da26ff0a44b25ec60
Author: VMwareDev Randy 
mailto:snmp-maintain...@vmware.com>>
Date:   Mon Jun 22 22:20:43 2015 -0400

snmp_send callback updates

- add new NETSNMP_CALLBACK_OP_RESEND
- add missing calls for NETSNMP_CALLBACK_OP_SEND_FAILED

Signed-off-by: Robert Story 
mailto:rst...@freesnmp.com>>"

Regards
Anders Wallin

On Thu, Apr 4, 2019 at 10:48 AM Matsumoto, Shogo 
mailto:shogo.matsum...@jp.fujitsu.com>> wrote:
Hi,

The issue also occurs with the following patches.

NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3

 0001-agentx-logging-to-late-responses.patch
 0002-agentx-do-not-shut-down-all-sessions-when-one-sessio.patch


The issue occurs with the following patch (2914) too but I found
the cause of this issue.

 https://sourceforge.net/p/net-snmp/bugs/2914/
 0001-BUG2914-Agent-master-needs-to-treat-resend-as-normal.patch


With the patch 2914, netsnmp_free_delegated_cache is called
several times for the same object as follows:

 1. snmp_resend_request calls agentx_got_response with 
NETSNMP_CALLBACK_OP_RESEND,
 2. agentx_got_response's NETSNMP_CALLBACK_OP_RESEND handler do nothing
 3. snmp_resend_request calls agentx_got_response with 
NETSNMP_CALLBACK_OP_SEND_FAILED,
 4. agentx_got_response's NETSNMP_CALLBACK_OP_SEND_FAILED handler calls 
netsnmp_free_delegated_cache,
 5. snmp_sess_close calls agentx_got_response with 
NETSNMP_CALLBACK_OP_TIMED_OUT,
 6. agentx_got_response's NETSNMP_CALLBACK_OP_TIMED_OUT handler calls 
netsnmp_free_delegated_cache
(double free)

gdb
--
Breakpoint 2, snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5eb160, incr_retries=1) at snmp_api.c:6747
6747rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at agent_handler.c:929
#1  0x7fab254d5363 in agentx_got_response (operation=, 
session=0x564eec4ad560, reqid=2, pdu=0x564eec5e3050, magic=)
at mibgroup/agentx/master.c:262
#2  0x7fab24c6b58f in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000) 
at snmp_api.c:6813
#3  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
#4  0x564eeb4c0f58 in receive () at snmpd.c:1347
#5  0x564eeb4c066e in main (argc=, argv=) at 
snmpd.c:1126
(gdb) c
Continuing.

Breakpoint 1, snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
6735rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at agent_handler.c:929
#1  0x7fab254d541a in agentx_got_response (operation=3, 
session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, magic=0x564eec5f3730)
at mibgroup/agentx/master.c:223
#2  0x7fab24c69325 in snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
#3  0x7fab24c6b5db in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000) 
at snmp_api.c:6826
#4  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
#5  0x564eeb4c0f58 in receive () at snmpd.c:1347
#6  0x564eeb4c066e in main (argc=, argv=) at 
snmpd.c:1126
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at agent_handler.c:929
#1  0x7fab254d541a in agentx_got_response (operation=2, 
session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, mag

Re: Core dump with net-snmp-5.8

[Anders Wallin]

I will check, but it will be tomorrow
I don't know how I read the code last time, I was referring to the wrong
commit where the code was introduced, it was introduced with
"commit b7b50bbac7f21a924149d03da26ff0a44b25ec60
Author: VMwareDev Randy 
Date:   Mon Jun 22 22:20:43 2015 -0400

snmp_send callback updates

- add new NETSNMP_CALLBACK_OP_RESEND
- add missing calls for NETSNMP_CALLBACK_OP_SEND_FAILED

Signed-off-by: Robert Story "

Regards
Anders Wallin


On Thu, Apr 4, 2019 at 10:48 AM Matsumoto, Shogo <
shogo.matsum...@jp.fujitsu.com> wrote:

> Hi,
>
> The issue also occurs with the following patches.
>
> NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3
>
>  0001-agentx-logging-to-late-responses.patch
>  0002-agentx-do-not-shut-down-all-sessions-when-one-sessio.patch
>
>
> The issue occurs with the following patch (2914) too but I found
> the cause of this issue.
>
>  https://sourceforge.net/p/net-snmp/bugs/2914/
>  0001-BUG2914-Agent-master-needs-to-treat-resend-as-normal.patch
>
>
> With the patch 2914, netsnmp_free_delegated_cache is called
> several times for the same object as follows:
>
>  1. snmp_resend_request calls agentx_got_response with
> NETSNMP_CALLBACK_OP_RESEND,
>  2. agentx_got_response's NETSNMP_CALLBACK_OP_RESEND handler do nothing
>  3. snmp_resend_request calls agentx_got_response with
> NETSNMP_CALLBACK_OP_SEND_FAILED,
>  4. agentx_got_response's NETSNMP_CALLBACK_OP_SEND_FAILED handler calls
> netsnmp_free_delegated_cache,
>  5. snmp_sess_close calls agentx_got_response with
> NETSNMP_CALLBACK_OP_TIMED_OUT,
>  6. agentx_got_response's NETSNMP_CALLBACK_OP_TIMED_OUT handler calls
> netsnmp_free_delegated_cache
> (double free)
>
> gdb
> --
> Breakpoint 2, snmp_resend_request (slp=slp@entry=0x564eec5df000,
> rp=rp@entry=0x564eec5eb160, incr_retries=1) at snmp_api.c:6747
> 6747rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
> (gdb) c
> Continuing.
>
> Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at
> agent_handler.c:929
> 929 {
> (gdb) bt
> #0  netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at
> agent_handler.c:929
> #1  0x7fab254d5363 in agentx_got_response (operation=,
> session=0x564eec4ad560, reqid=2, pdu=0x564eec5e3050, magic=)
> at mibgroup/agentx/master.c:262
> #2  0x7fab24c6b58f in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000)
> at snmp_api.c:6813
> #3  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
> #4  0x564eeb4c0f58 in receive () at snmpd.c:1347
> #5  0x564eeb4c066e in main (argc=, argv= out>) at snmpd.c:1126
> (gdb) c
> Continuing.
>
> Breakpoint 1, snmp_resend_request (slp=slp@entry=0x564eec5df000,
> rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
> 6735rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
> (gdb) c
> Continuing.
>
> Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at
> agent_handler.c:929
> 929 {
> (gdb) bt
> #0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at
> agent_handler.c:929
> #1  0x7fab254d541a in agentx_got_response (operation=3,
> session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, magic=0x564eec5f3730)
> at mibgroup/agentx/master.c:223
> #2  0x7fab24c69325 in snmp_resend_request (slp=slp@entry=0x564eec5df000,
> rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
> #3  0x7fab24c6b5db in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000)
> at snmp_api.c:6826
> #4  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
> #5  0x564eeb4c0f58 in receive () at snmpd.c:1347
> #6  0x564eeb4c066e in main (argc=, argv= out>) at snmpd.c:1126
> (gdb) c
> Continuing.
>
> Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at
> agent_handler.c:929
> 929 {
> (gdb) bt
> #0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at
> agent_handler.c:929
> #1  0x7fab254d541a in agentx_got_response (operation=2,
> session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, magic=0x564eec5f3730)
> at mibgroup/agentx/master.c:223
> #2  0x7fab24c69586 in snmp_sess_close (sessp=0x564eec5df000) at
> snmp_api.c:1975
> #3  0x7fab24c6afea in snmp_sess_select_info2_flags (sessp=0x0,
> numfds=0x7fff68db3694, fdset=0x7fff68db36b0, timeout=0x7fff68db36a0,
> block=0x7fff68db369c, flags=0) at snmp_api.c:6556
> #4  0x564eeb4c0e95 in receive () at snmpd.c:1263
> #5  0x564eeb4c066e in main (argc=, argv= out>) at snmpd.c:1126
> (gdb) c
> Continuing.
>
> Program received signal SIGABRT, Aborted.
> 0x7fab2335f93f in raise () from /lib64/libc.so.6
> --
>
>
> On the other hand, without the patch 2914 netsnmp_free_delegated_cache is
> called
> several times for the same object as follows:
>
>  1. snmp_resend_request calls agentx_got_response with
> NETSNMP_CALLBACK_OP_RESEND,
>  2. 

Re: Core dump with net-snmp-5.8

[Matsumoto, Shogo]

Hi,

The issue also occurs with the following patches.

NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3

 0001-agentx-logging-to-late-responses.patch
 0002-agentx-do-not-shut-down-all-sessions-when-one-sessio.patch


The issue occurs with the following patch (2914) too but I found
the cause of this issue.

 https://sourceforge.net/p/net-snmp/bugs/2914/
 0001-BUG2914-Agent-master-needs-to-treat-resend-as-normal.patch


With the patch 2914, netsnmp_free_delegated_cache is called
several times for the same object as follows:

 1. snmp_resend_request calls agentx_got_response with 
NETSNMP_CALLBACK_OP_RESEND,
 2. agentx_got_response's NETSNMP_CALLBACK_OP_RESEND handler do nothing
 3. snmp_resend_request calls agentx_got_response with 
NETSNMP_CALLBACK_OP_SEND_FAILED, 
 4. agentx_got_response's NETSNMP_CALLBACK_OP_SEND_FAILED handler calls 
netsnmp_free_delegated_cache,
 5. snmp_sess_close calls agentx_got_response with 
NETSNMP_CALLBACK_OP_TIMED_OUT,
 6. agentx_got_response's NETSNMP_CALLBACK_OP_TIMED_OUT handler calls 
netsnmp_free_delegated_cache
(double free)

gdb
--
Breakpoint 2, snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5eb160, incr_retries=1) at snmp_api.c:6747
6747rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f2ec0) at agent_handler.c:929
#1  0x7fab254d5363 in agentx_got_response (operation=, 
session=0x564eec4ad560, reqid=2, pdu=0x564eec5e3050, magic=)
at mibgroup/agentx/master.c:262
#2  0x7fab24c6b58f in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000) 
at snmp_api.c:6813
#3  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
#4  0x564eeb4c0f58 in receive () at snmpd.c:1347
#5  0x564eeb4c066e in main (argc=, argv=) at 
snmpd.c:1126
(gdb) c
Continuing.

Breakpoint 1, snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
6735rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at agent_handler.c:929
#1  0x7fab254d541a in agentx_got_response (operation=3, 
session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, magic=0x564eec5f3730)
at mibgroup/agentx/master.c:223
#2  0x7fab24c69325 in snmp_resend_request (slp=slp@entry=0x564eec5df000, 
rp=rp@entry=0x564eec5f3e50, incr_retries=1) at snmp_api.c:6735
#3  0x7fab24c6b5db in snmp_sess_timeout (sessp=sessp@entry=0x564eec5df000) 
at snmp_api.c:6826
#4  0x7fab24c6b710 in snmp_timeout () at snmp_api.c:6660
#5  0x564eeb4c0f58 in receive () at snmpd.c:1347
#6  0x564eeb4c066e in main (argc=, argv=) at 
snmpd.c:1126
(gdb) c
Continuing.

Breakpoint 3, netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x564eec5f3730) at agent_handler.c:929
#1  0x7fab254d541a in agentx_got_response (operation=2, 
session=0x564eec4ad560, reqid=4, pdu=0x564eec5e54a0, magic=0x564eec5f3730)
at mibgroup/agentx/master.c:223
#2  0x7fab24c69586 in snmp_sess_close (sessp=0x564eec5df000) at 
snmp_api.c:1975
#3  0x7fab24c6afea in snmp_sess_select_info2_flags (sessp=0x0, 
numfds=0x7fff68db3694, fdset=0x7fff68db36b0, timeout=0x7fff68db36a0,
block=0x7fff68db369c, flags=0) at snmp_api.c:6556
#4  0x564eeb4c0e95 in receive () at snmpd.c:1263
#5  0x564eeb4c066e in main (argc=, argv=) at 
snmpd.c:1126
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x7fab2335f93f in raise () from /lib64/libc.so.6
--


On the other hand, without the patch 2914 netsnmp_free_delegated_cache is called
several times for the same object as follows:

 1. snmp_resend_request calls agentx_got_response with 
NETSNMP_CALLBACK_OP_RESEND,
 2. agentx_got_response's "Unknown operation" handler calls 
netsnmp_free_delegated_cache,
 3. (retry) snmp_resend_request calls agentx_got_response AGAIN with 
NETSNMP_CALLBACK_OP_RESEND,
 4. agentx_got_response's "Unknown operation" handler calls 
netsnmp_free_delegated_cache
(double free)

gdb
--
(gdb) b netsnmp_free_delegated_cache
Breakpoint 1 at 0x7f03bd437250: file agent_handler.c, line 929.
(gdb) c
Continuing.

Breakpoint 1, netsnmp_free_delegated_cache (dcache=0x558981be9110) at 
agent_handler.c:929
929 {
(gdb) bt
#0  netsnmp_free_delegated_cache (dcache=0x558981be9110) at agent_handler.c:929
#1  0x7f03bd44a2df in agentx_got_response (operation=6, 
session=0x558981aa1540, reqid=12, 

Re: Core dump with net-snmp-5.8

[Anders Wallin]

The introduction of that code fixes another issue;
"commit 56c30b11f3616ea4f0c38a21e08e78f050096020
Author: Bill Fenner 
Date:   Wed Dec 20 21:52:10 2017 +

NEWS: snmplib: PATCH: 1349: Fix perl/other crash against bad SNMPv3
agent

With the patch in 1214, the snmp_api code assumed that if magic was
set, it was the "struct synch-state" from snmp_client.  Of course,
magic belongs to the caller, and the perl library uses it differently,
so reaching into it is verboten.  Introduce a new callback (that
was already introduced in 5.8) to report this "retries exceeded"
state, and use it in snmp_client."

I think the problem is really about shutting down the agentx connection
when one(1) response is to late. I have
done 2 patches (one that only write a better log message and one that
removes the "bad" code.
With these patches I don't get any crash. I think that 5.7.3 has this issue
as well, but it can not be crashed with the agentofdead code

Can you please try this?

Regards
Anders Wallin


On Wed, Apr 3, 2019 at 12:35 PM Josef Ridky  wrote:

> Hi,
>
> I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found, that
> following callbacks in snmplib/snmp_api.c causes the core dump issue:
>
> --- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
> +++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
> @@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
>  sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
>  sp->s_errno = errno;
>  snmp_set_detail(strerror(errno));
> -if (rp->callback)
> +/*if (rp->callback)
>  rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
> - rp->pdu->reqid, rp->pdu, rp->cb_data);
> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>  return -1;
>  } else {
>  netsnmp_get_monotonic_clock();
> @@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
>  tv.tv_sec += tv.tv_usec / 100L;
>  tv.tv_usec %= 100L;
>  rp->expireM = tv;
> -if (rp->callback)
> +/*if (rp->callback)
>  rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
> - rp->pdu->reqid, rp->pdu, rp->cb_data);
> + rp->pdu->reqid, rp->pdu, rp->cb_data);*/
>  }
>  return 0;
>  }
>
> Without them, all works as expected.
>
> Josef Ridky
> Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
>
> - Original Message -
> | From: "Anders Wallin" 
> | To: "Josef Ridky" 
> | Cc: "net-snmp-coders" 
> | Sent: Tuesday, April 2, 2019 6:27:54 PM
> | Subject: Re: Core dump with net-snmp-5.8
> |
> | Hi Josef,
> | I can reproduce the issue using the master branch, I will take a look at
> it
> | later tonight or tomorrow
> |
> | Regards
> | Anders Wallin
> |
> |
> | On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky  wrote:
> |
> | > Hi,
> | >
> | > thanks for your patch. Unfortunately, even when I have applied it, it
> | > still ends with core dump due of 'double free or corruption (fasttop)'
> | >
> | > When I run snmpd with -Dsnmp_agent,agentx/master it ends with:
> | >
> | > agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
> | > snmp_agent: delegate session == 0x56207e165240
> | > snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
> | > agentx/master: callback resend
> | > agentx/master: callback resend
> | > agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
> | > agentx/master: close 0x56207dfd5400, -1
> | > snmp_agent: removed 40 delegated request(s) for session 0x56207dfce490
> | > snmp_agent: processing delegated request, asp = 0x56207e165240
> | > snmp_agent: canceling next walk for asp 0x56207e165240
> | > snmp_agent: REMOVE session == 0x56207e165240
> | > snmp_agent: agent_session 0x56207e165240 released
> | > snmp_agent: processing delegated request, asp = 0x56207e1041a0
> | > snmp_agent: canceling next walk for asp 0x56207e1041a0
> | > snmp_agent: REMOVE session == 0x56207e1041a0
> | > snmp_agent: agent_session 0x56207e1041a0 released
> | > snmp_agent: processing delegated request, asp = 0x56207e1656c0
> | > snmp_agent: canceling next walk for asp 0x56207e1656c0
> | > snmp_agent: REMOVE session == 0x56207e1656c0
> | > snmp_agent: agent_session 0x56207e1656c0 released
> | > snmp_agent: processing delegated request, asp = 0x56207e11af40
> | > snmp_agent: canceling next walk for asp 0x56207e11af40
> | > snmp_agent: REMOVE ses

Re: Core dump with net-snmp-5.8

[Josef Ridky]

Hi,

I have compared net-snmp-5.7.3 and net-snmp-5.8 and I have found, that 
following callbacks in snmplib/snmp_api.c causes the core dump issue:

--- old/snmplib/snmp_api.c  2019-04-03 12:13:55.126769866 +0200
+++ new/snmplib/snmp_api.c  2019-04-03 12:15:18.353420790 +0200
@@ -6731,9 +6731,9 @@ snmp_resend_request(struct session_list
 sp->s_snmp_errno = SNMPERR_BAD_SENDTO;
 sp->s_errno = errno;
 snmp_set_detail(strerror(errno));
-if (rp->callback)
+/*if (rp->callback)
 rp->callback(NETSNMP_CALLBACK_OP_SEND_FAILED, sp,
- rp->pdu->reqid, rp->pdu, rp->cb_data);
+ rp->pdu->reqid, rp->pdu, rp->cb_data);*/
 return -1;
 } else {
 netsnmp_get_monotonic_clock();
@@ -6743,9 +6743,9 @@ snmp_resend_request(struct session_list
 tv.tv_sec += tv.tv_usec / 100L;
 tv.tv_usec %= 100L;
 rp->expireM = tv;
-if (rp->callback)
+/*if (rp->callback)
 rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
- rp->pdu->reqid, rp->pdu, rp->cb_data);
+ rp->pdu->reqid, rp->pdu, rp->cb_data);*/
 }
 return 0;
 }

Without them, all works as expected.

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

- Original Message -
| From: "Anders Wallin" 
| To: "Josef Ridky" 
| Cc: "net-snmp-coders" 
| Sent: Tuesday, April 2, 2019 6:27:54 PM
| Subject: Re: Core dump with net-snmp-5.8
| 
| Hi Josef,
| I can reproduce the issue using the master branch, I will take a look at it
| later tonight or tomorrow
| 
| Regards
| Anders Wallin
| 
| 
| On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky  wrote:
| 
| > Hi,
| >
| > thanks for your patch. Unfortunately, even when I have applied it, it
| > still ends with core dump due of 'double free or corruption (fasttop)'
| >
| > When I run snmpd with -Dsnmp_agent,agentx/master it ends with:
| >
| > agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
| > snmp_agent: delegate session == 0x56207e165240
| > snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
| > agentx/master: callback resend
| > agentx/master: callback resend
| > agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
| > agentx/master: close 0x56207dfd5400, -1
| > snmp_agent: removed 40 delegated request(s) for session 0x56207dfce490
| > snmp_agent: processing delegated request, asp = 0x56207e165240
| > snmp_agent: canceling next walk for asp 0x56207e165240
| > snmp_agent: REMOVE session == 0x56207e165240
| > snmp_agent: agent_session 0x56207e165240 released
| > snmp_agent: processing delegated request, asp = 0x56207e1041a0
| > snmp_agent: canceling next walk for asp 0x56207e1041a0
| > snmp_agent: REMOVE session == 0x56207e1041a0
| > snmp_agent: agent_session 0x56207e1041a0 released
| > snmp_agent: processing delegated request, asp = 0x56207e1656c0
| > snmp_agent: canceling next walk for asp 0x56207e1656c0
| > snmp_agent: REMOVE session == 0x56207e1656c0
| > snmp_agent: agent_session 0x56207e1656c0 released
| > snmp_agent: processing delegated request, asp = 0x56207e11af40
| > snmp_agent: canceling next walk for asp 0x56207e11af40
| > snmp_agent: REMOVE session == 0x56207e11af40
| > snmp_agent: agent_session 0x56207e11af40 released
| > snmp_agent: processing delegated request, asp = 0x56207e118f00
| > snmp_agent: canceling next walk for asp 0x56207e118f00
| > snmp_agent: REMOVE session == 0x56207e118f00
| > snmp_agent: agent_session 0x56207e118f00 released
| > snmp_agent: processing delegated request, asp = 0x56207e11b540
| > snmp_agent: canceling next walk for asp 0x56207e11b540
| > snmp_agent: REMOVE session == 0x56207e11b540
| > snmp_agent: agent_session 0x56207e11b540 released
| > snmp_agent: processing delegated request, asp = 0x56207e11bd00
| > snmp_agent: canceling next walk for asp 0x56207e11bd00
| > snmp_agent: REMOVE session == 0x56207e11bd00
| > snmp_agent: agent_session 0x56207e11bd00 released
| > agentx/master: Continue removing delegated subsession reqests
| > agentx/master: close transport
| > snmp_agent: REMOVE session == 0x56207dfd5400
| > agentx/master: response too late on session 0x56207dfd5400
| > agentx/master: response too late on session 0x56207dfd5400
| > double free or corruption (fasttop)
| > Aborted (core dumped)
| >
| >
| > What's interesting, when I run it with -DALL it pass (at least for several
| > rounds).
| > It looks like some strange race condition.
| >
| > Regards
| >
| > Josef Ridky
| > Software Engineer
| > Core Services Team
| > Red Hat Czech, s.r.o.
| >
| > - Original Message -
| > | From: "Anders Wallin" 
| >

Re: Core dump with net-snmp-5.8

[Anders Wallin]

Hi Josef,
I can reproduce the issue using the master branch, I will take a look at it
later tonight or tomorrow

Regards
Anders Wallin


On Tue, Apr 2, 2019 at 3:42 PM Josef Ridky  wrote:

> Hi,
>
> thanks for your patch. Unfortunately, even when I have applied it, it
> still ends with core dump due of 'double free or corruption (fasttop)'
>
> When I run snmpd with -Dsnmp_agent,agentx/master it ends with:
>
> agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
> snmp_agent: delegate session == 0x56207e165240
> snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
> agentx/master: callback resend
> agentx/master: callback resend
> agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
> agentx/master: close 0x56207dfd5400, -1
> snmp_agent: removed 40 delegated request(s) for session 0x56207dfce490
> snmp_agent: processing delegated request, asp = 0x56207e165240
> snmp_agent: canceling next walk for asp 0x56207e165240
> snmp_agent: REMOVE session == 0x56207e165240
> snmp_agent: agent_session 0x56207e165240 released
> snmp_agent: processing delegated request, asp = 0x56207e1041a0
> snmp_agent: canceling next walk for asp 0x56207e1041a0
> snmp_agent: REMOVE session == 0x56207e1041a0
> snmp_agent: agent_session 0x56207e1041a0 released
> snmp_agent: processing delegated request, asp = 0x56207e1656c0
> snmp_agent: canceling next walk for asp 0x56207e1656c0
> snmp_agent: REMOVE session == 0x56207e1656c0
> snmp_agent: agent_session 0x56207e1656c0 released
> snmp_agent: processing delegated request, asp = 0x56207e11af40
> snmp_agent: canceling next walk for asp 0x56207e11af40
> snmp_agent: REMOVE session == 0x56207e11af40
> snmp_agent: agent_session 0x56207e11af40 released
> snmp_agent: processing delegated request, asp = 0x56207e118f00
> snmp_agent: canceling next walk for asp 0x56207e118f00
> snmp_agent: REMOVE session == 0x56207e118f00
> snmp_agent: agent_session 0x56207e118f00 released
> snmp_agent: processing delegated request, asp = 0x56207e11b540
> snmp_agent: canceling next walk for asp 0x56207e11b540
> snmp_agent: REMOVE session == 0x56207e11b540
> snmp_agent: agent_session 0x56207e11b540 released
> snmp_agent: processing delegated request, asp = 0x56207e11bd00
> snmp_agent: canceling next walk for asp 0x56207e11bd00
> snmp_agent: REMOVE session == 0x56207e11bd00
> snmp_agent: agent_session 0x56207e11bd00 released
> agentx/master: Continue removing delegated subsession reqests
> agentx/master: close transport
> snmp_agent: REMOVE session == 0x56207dfd5400
> agentx/master: response too late on session 0x56207dfd5400
> agentx/master: response too late on session 0x56207dfd5400
> double free or corruption (fasttop)
> Aborted (core dumped)
>
>
> What's interesting, when I run it with -DALL it pass (at least for several
> rounds).
> It looks like some strange race condition.
>
> Regards
>
> Josef Ridky
> Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
>
> ----- Original Message -
> | From: "Anders Wallin" 
> | To: "Josef Ridky" 
> | Cc: "net-snmp-coders" 
> | Sent: Tuesday, April 2, 2019 1:46:40 PM
> | Subject: Re: Core dump with net-snmp-5.8
> |
> | Hi Josef,
> |
> | I think it's the same issue as
> https://sourceforge.net/p/net-snmp/bugs/2914/
> | (where I also posted the solution)
> | Regards
> | Anders Wallin
> |
> |
> | On Tue, Apr 2, 2019 at 12:43 PM Josef Ridky  wrote:
> |
> | > Hi,
> | >
> | > recently, I have hit to an issue in net-snmp-5.8, that is connected to
> the
> | > bug report [1].
> | >
> | > When I tried to run agentofdeath test from [1], snmpd daemon will crash
> | > with malloc(): smallbin double linked list corrupted or double free()
> issue
> | > and dumps core (see bellow).
> | > From log file, I can identified one issue with "Unknown operation".
> | >
> | > This issue is in the agentx_got_response function
> | > (agent/mibgroup/agentx/master.c). There isn't implemented action for
> | > NETSNMP_CALLBACK_OP_RESEND (defined in
> | > include/net-snmp/library/snmp_api.h).
> | > As result "Unknown operation 6 in agentx_got_response" is shown in log
> | > file.
> | >
> | > /var/log/messages
> | > ---
> | > Mar 28 06:52:42 localhost snmpd[12073]: Unknown operation 6 in
> | > agentx_got_response
> | > Mar 28 06:52:43 localhost snmpd[12073]: Unknown operation 6 in
> | > agentx_got_response
> | > Mar 28 06:52:43 localhost snmpd[12073]: malloc(): smallbin double
> linked
> | > list corrupted
> | > Mar 28 06:52:43 localhost systemd[1]: Started Process Core Dump (PID
&g

Re: Core dump with net-snmp-5.8

[Josef Ridky]

Hi,

thanks for your patch. Unfortunately, even when I have applied it, it still 
ends with core dump due of 'double free or corruption (fasttop)'

When I run snmpd with -Dsnmp_agent,agentx/master it ends with:

agentx/master: sending pdu (req=0x1d4,trans=0x1d3,sess=0x5)
snmp_agent: delegate session == 0x56207e165240
snmp_agent: end of handle_snmp_packet, asp = 0x56207e165240
agentx/master: callback resend
agentx/master: callback resend
agentx/master: timeout on session 0x56207dfd5400 req=0x1c9
agentx/master: close 0x56207dfd5400, -1
snmp_agent: removed 40 delegated request(s) for session 0x56207dfce490
snmp_agent: processing delegated request, asp = 0x56207e165240
snmp_agent: canceling next walk for asp 0x56207e165240
snmp_agent: REMOVE session == 0x56207e165240
snmp_agent: agent_session 0x56207e165240 released
snmp_agent: processing delegated request, asp = 0x56207e1041a0
snmp_agent: canceling next walk for asp 0x56207e1041a0
snmp_agent: REMOVE session == 0x56207e1041a0
snmp_agent: agent_session 0x56207e1041a0 released
snmp_agent: processing delegated request, asp = 0x56207e1656c0
snmp_agent: canceling next walk for asp 0x56207e1656c0
snmp_agent: REMOVE session == 0x56207e1656c0
snmp_agent: agent_session 0x56207e1656c0 released
snmp_agent: processing delegated request, asp = 0x56207e11af40
snmp_agent: canceling next walk for asp 0x56207e11af40
snmp_agent: REMOVE session == 0x56207e11af40
snmp_agent: agent_session 0x56207e11af40 released
snmp_agent: processing delegated request, asp = 0x56207e118f00
snmp_agent: canceling next walk for asp 0x56207e118f00
snmp_agent: REMOVE session == 0x56207e118f00
snmp_agent: agent_session 0x56207e118f00 released
snmp_agent: processing delegated request, asp = 0x56207e11b540
snmp_agent: canceling next walk for asp 0x56207e11b540
snmp_agent: REMOVE session == 0x56207e11b540
snmp_agent: agent_session 0x56207e11b540 released
snmp_agent: processing delegated request, asp = 0x56207e11bd00
snmp_agent: canceling next walk for asp 0x56207e11bd00
snmp_agent: REMOVE session == 0x56207e11bd00
snmp_agent: agent_session 0x56207e11bd00 released
agentx/master: Continue removing delegated subsession reqests
agentx/master: close transport
snmp_agent: REMOVE session == 0x56207dfd5400
agentx/master: response too late on session 0x56207dfd5400
agentx/master: response too late on session 0x56207dfd5400
double free or corruption (fasttop)
Aborted (core dumped)


What's interesting, when I run it with -DALL it pass (at least for several 
rounds).
It looks like some strange race condition.

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

- Original Message -
| From: "Anders Wallin" 
| To: "Josef Ridky" 
| Cc: "net-snmp-coders" 
| Sent: Tuesday, April 2, 2019 1:46:40 PM
| Subject: Re: Core dump with net-snmp-5.8
| 
| Hi Josef,
| 
| I think it's the same issue as https://sourceforge.net/p/net-snmp/bugs/2914/
| (where I also posted the solution)
| Regards
| Anders Wallin
| 
| 
| On Tue, Apr 2, 2019 at 12:43 PM Josef Ridky  wrote:
| 
| > Hi,
| >
| > recently, I have hit to an issue in net-snmp-5.8, that is connected to the
| > bug report [1].
| >
| > When I tried to run agentofdeath test from [1], snmpd daemon will crash
| > with malloc(): smallbin double linked list corrupted or double free() issue
| > and dumps core (see bellow).
| > From log file, I can identified one issue with "Unknown operation".
| >
| > This issue is in the agentx_got_response function
| > (agent/mibgroup/agentx/master.c). There isn't implemented action for
| > NETSNMP_CALLBACK_OP_RESEND (defined in
| > include/net-snmp/library/snmp_api.h).
| > As result "Unknown operation 6 in agentx_got_response" is shown in log
| > file.
| >
| > /var/log/messages
| > ---
| > Mar 28 06:52:42 localhost snmpd[12073]: Unknown operation 6 in
| > agentx_got_response
| > Mar 28 06:52:43 localhost snmpd[12073]: Unknown operation 6 in
| > agentx_got_response
| > Mar 28 06:52:43 localhost snmpd[12073]: malloc(): smallbin double linked
| > list corrupted
| > Mar 28 06:52:43 localhost systemd[1]: Started Process Core Dump (PID
| > 13652/UID 0).
| > Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Main process exited,
| > code=dumped, status=6/ABRT
| > Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Failed with result
| > 'core-dump'.
| > ---
| >
| > The "Unknown operation" callback is caused by newly added piece of code in
| > snmplib/snmp_api.c:
| >
| >  static int
| >  snmp_resend_request(struct session_list *slp, netsnmp_request_list *rp,
| >  int incr_retries)
| >  {
| >
| > ...
| >
| >  tv.tv_sec += tv.tv_usec / 100L;
| >  tv.tv_usec %= 100L;
| >  rp->expireM = tv;
| > +if (rp->callback)
| > 

Re: Core dump with net-snmp-5.8

[Anders Wallin]

Hi Josef,

I think it's the same issue as https://sourceforge.net/p/net-snmp/bugs/2914/
(where I also posted the solution)
Regards
Anders Wallin


On Tue, Apr 2, 2019 at 12:43 PM Josef Ridky  wrote:

> Hi,
>
> recently, I have hit to an issue in net-snmp-5.8, that is connected to the
> bug report [1].
>
> When I tried to run agentofdeath test from [1], snmpd daemon will crash
> with malloc(): smallbin double linked list corrupted or double free() issue
> and dumps core (see bellow).
> From log file, I can identified one issue with "Unknown operation".
>
> This issue is in the agentx_got_response function
> (agent/mibgroup/agentx/master.c). There isn't implemented action for
> NETSNMP_CALLBACK_OP_RESEND (defined in include/net-snmp/library/snmp_api.h).
> As result "Unknown operation 6 in agentx_got_response" is shown in log
> file.
>
> /var/log/messages
> ---
> Mar 28 06:52:42 localhost snmpd[12073]: Unknown operation 6 in
> agentx_got_response
> Mar 28 06:52:43 localhost snmpd[12073]: Unknown operation 6 in
> agentx_got_response
> Mar 28 06:52:43 localhost snmpd[12073]: malloc(): smallbin double linked
> list corrupted
> Mar 28 06:52:43 localhost systemd[1]: Started Process Core Dump (PID
> 13652/UID 0).
> Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Main process exited,
> code=dumped, status=6/ABRT
> Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Failed with result
> 'core-dump'.
> ---
>
> The "Unknown operation" callback is caused by newly added piece of code in
> snmplib/snmp_api.c:
>
>  static int
>  snmp_resend_request(struct session_list *slp, netsnmp_request_list *rp,
>  int incr_retries)
>  {
>
> ...
>
>  tv.tv_sec += tv.tv_usec / 100L;
>  tv.tv_usec %= 100L;
>  rp->expireM = tv;
> +if (rp->callback)
> +rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
> + rp->pdu->reqid, rp->pdu, rp->cb_data);
>  }
>  return 0;
>  }
>
>
> When I tried to remove it, it just stop complaining about operation 6, but
> the core dump is still present.
>
> May I ask you for help with this issue? Do you have any idea, what causing
> this issue in 5.8 and how to fix it?
> I know, that Jan Safranek has fixed this for 5.7 by commit [2], but it
> looks like something other has changed and this issue is current again.
>
> [1] https://sourceforge.net/p/net-snmp/bugs/2411/
> [2]
> https://github.com/net-snmp/net-snmp/commit/793d596838ff7cb48a73b675d62897c56c9e62df
>
> Regards
>
> Josef Ridky
> Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
>
>
>
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Core dump with net-snmp-5.8

[Josef Ridky]

Hi,

recently, I have hit to an issue in net-snmp-5.8, that is connected to the bug 
report [1].

When I tried to run agentofdeath test from [1], snmpd daemon will crash with 
malloc(): smallbin double linked list corrupted or double free() issue and 
dumps core (see bellow).
>From log file, I can identified one issue with "Unknown operation".

This issue is in the agentx_got_response function 
(agent/mibgroup/agentx/master.c). There isn't implemented action for 
NETSNMP_CALLBACK_OP_RESEND (defined in include/net-snmp/library/snmp_api.h).
As result "Unknown operation 6 in agentx_got_response" is shown in log file.

/var/log/messages
---
Mar 28 06:52:42 localhost snmpd[12073]: Unknown operation 6 in 
agentx_got_response
Mar 28 06:52:43 localhost snmpd[12073]: Unknown operation 6 in 
agentx_got_response
Mar 28 06:52:43 localhost snmpd[12073]: malloc(): smallbin double linked list 
corrupted
Mar 28 06:52:43 localhost systemd[1]: Started Process Core Dump (PID 13652/UID 
0).
Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Main process exited, 
code=dumped, status=6/ABRT
Mar 28 06:52:48 localhost systemd[1]: snmpd.service: Failed with result 
'core-dump'.
---

The "Unknown operation" callback is caused by newly added piece of code in 
snmplib/snmp_api.c:

 static int
 snmp_resend_request(struct session_list *slp, netsnmp_request_list *rp,
 int incr_retries)
 {

...

 tv.tv_sec += tv.tv_usec / 100L;
 tv.tv_usec %= 100L;
 rp->expireM = tv;
+if (rp->callback)
+rp->callback(NETSNMP_CALLBACK_OP_RESEND, sp,
+ rp->pdu->reqid, rp->pdu, rp->cb_data);
 }
 return 0;
 }


When I tried to remove it, it just stop complaining about operation 6, but the 
core dump is still present.

May I ask you for help with this issue? Do you have any idea, what causing this 
issue in 5.8 and how to fix it? 
I know, that Jan Safranek has fixed this for 5.7 by commit [2], but it looks 
like something other has changed and this issue is current again. 

[1] https://sourceforge.net/p/net-snmp/bugs/2411/
[2] 
https://github.com/net-snmp/net-snmp/commit/793d596838ff7cb48a73b675d62897c56c9e62df

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.



___
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

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

[Simon Chamlian]

Greetings,

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.

Did the compilation flags changed ?

Do I need a specific flag (something like --enable_v2) to enable both v2
and v3?

Thanks,
S
--
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: porting Net-SNMP 5.8 to Yocto

[Robert Story]

On Fri, 20 Jul 2018 09:35:22 -0400 Simon wrote:
SC> While trying to port the newly released net-snmp to yocto, I am
SC> getting the following error:
SC> 
SC> ERROR: This autoconf log indicates errors, it looked at host
SC> include and/or library paths while determining system
SC> capabilities. Rerun configure task after fixing this.
SC> DEBUG: Python function do_qa_configure finished
SC> ERROR: Function failed: do_qa_configure
SC> 
SC> 
SC> Any hints?

Did you check config.log for errors?

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

porting Net-SNMP 5.8 to Yocto

[Simon Chamlian]

Hi,

While trying to port the newly released net-snmp to yocto, I am getting the
following error:

ERROR: This autoconf log indicates errors, it looked at host include and/or
library paths while determining system capabilities.
Rerun configure task after fixing this.
DEBUG: Python function do_qa_configure finished
ERROR: Function failed: do_qa_configure


Any hints?

Thanks,
S
--
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

Net-SNMP 5.8.rc4 available for testing

[Robert Story]

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.

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

Net-SNMP 5.8.rc3 available for testing

[Robert Story]

Net-SNMP 5.8.rc3 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 major changes in 5.8.rc3.

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.rc3
snmplib:
  - [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
sprint_realloc_octet_string() triggers a segmentation fault
strlcpy() implementations typically scan for the end of the source
argument passed to strlcpy(). Hence avoid passing an unterminated
string to strlcpy().

Cygwin64:
  -  Fix build with OpenSSL


With any luck, this will be the last release candidate, and 5.8
will be out next week!

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

Net-SNMP 5.8.rc2 available for testing

[Robert Story]

Net-SNMP 5.8.rc2 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 major changes in 5.8.rc2

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.rc2*
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.")

NetBSD:
  - Fix for NetBSD 8

Cygwin64:
  -  Fix winExtDLL build

install:
  - Install missing system header files

building:
  - Add Travis and Appveyor CI support
  - Fix recently introduced autoreconf warnings

misc:
  - restore auth/priv defines for protocol OID lengths

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

Net-SNMP 5.8.pre3 available

[Robert Story]

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:

  https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-pre-releases/

Partial summary of changes since since 5.8.pre2:

*5.8.pre3*
snmplib:
  - Asn1: BUG: 2828: from "Google Autofuzz project": fix off-by-one
heap access for opaque types   (and an adjacent bug that was not in
5.4, noticed by code inspection)
  - Asn1: from "Google Autofuzz project": propagate error from
asn_parse_length

snmpd:
  - BUG: 2810: from "Minzhuan Gong": fix compile with
--enable-read-only
  - BUG: 2845: fix compilation error with NETSNMP_NO_WRITE_SUPPORT
  - BUG: 2846: fix agent compile when both --enable-read-only and
--disable-set-support are given.
  - Com2sec and com2sec6 SOURCE values may deny sources as well as
permit.
  - TLSTM MIB: Fix support for sha256, 384 and 512 fingerprints
  - BUG: 2830: Make the agentxperms keyword work again

agentx:
  - From "Google AutoFuzz project": account for the nul character we
will add to the string.
  - From "Google Autofuzz project": additional agentx protocol parser
bounds checking

Win32:
  - Add support for the DTLS-UDP and TLS-TCP transports
  - Win32/MSVC general cleanup

unspecified:
  - Fix bug #2832 for building new checkbandwidth script
  - Many fixes found by Coverity scans


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

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

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

[Bill Fenner]

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.

I suspect that this code, which is trying to avoid calling callbacks when
there aren't any sessions of the given version, is irrelevant when using
the built in list of sinks (i.e., when there is no snmp_callback_available(
..., SNMPD_CALLBACK_REGISTER_NOTIFICATIONS ).  However, I don't have a
brilliant idea about how to avoid this error.

1. Change it to a DEBUGMSG. Obviously makes the apparent error not very
visible, but, I don't know if it needs visibility.
2. Register the agentx session using SNMP_VERSION_2c. I assume something
else will break if we pretend it's an SNMP session and not AgentX, but I
haven't tried this.
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/

Any other ideas?

Thanks,
  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.pre2 available

[Robert Story]

On Mon, Mar 5, 2018 at 3:11 PM, Robert Story <rst...@freesnmp.com> 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

Net-SNMP 5.8.pre2 available

[Robert Story]

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:

  https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-pre-releases/

Partial summary of changes since since 5.8.pre2:

snmplib:
  - TLS/DTLS fixes
  - Add more openssl error cases where we check for local cert
  - fix usm keychanges for new algorithms and longer keylengths
  - fix some memory leaks in usm processing
  - IP address formatting fixes
  - Make the source code C89 compliant

building:
  - Fix MinGW build
  - Unbreak the NetBSD build
  - Unbreak AIX support
  - RHEL 5 build fix

scripts:
  - A new 'checkbandwidth' script to check host min/max bandwidth

docs:
  - Bug 2826: from Tomasz: fix utf-8 encoding

python:
  - BUG 2824: from: Tomasz: Fix python module make install
--
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

Net-SNMP 5.8.pre1 available for testing

[Robert Story]

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

  https://sourceforge.net/projects/net-snmp/files/5.8-pre-releases/

* Net-SNMP version 5.8 introduces support for new Authentication
protocols defined in RFC 7860. The following authentication
protocols are now supported:

  - SHA-224
  - SHA-256
  - SHA-384
  - SHA-512

Successful interoperability testing of these new protocols has been
performed with the pySNMP and Snmp Research implementations.


* Net-SNMP version 5.8 introduces support for additional Privacy
protocols, as defined in draft-blumenthal-aes-usm-04.txt. This was
complicated a bit because some vendors chose to extend localized
keys using an algorithm defined in the Reeder 3DESEDE draft
(draft-reeder-snmpv3-usm-3desede-00) instead of the algoritm
defined in the Blumenthal AES draft.

Net-SNMP implements both algorithms. As these new privacy protocols
are based on IETF drafts and are not part of any standard, you must
specify an additional option to configure enable them:

  --enable-blumenthal-aes

Successful interoperability testing of these new protocols has been
performed with the pySNMP (AES and 3DESEDE methods) and Snmp
Research (3DESEDE method) implementations.

To use the original algorithm as defined in the Blumenthal AES
draft, use one of the following privacy protocols:

  - AES-192
  - AES-256

To use the algorithm defined in the Reeder 3DESEDE draft, use one of
the following privacy protocols:

  - AES-192-C
  - AES-256-C


* While the Changes and NEWS files are still incomplete, some of
  the other changes in 5.8 include:

*5.8.pre1*
snmplib:
  - Fixed reporting 'error writing to /var/xxx/snmpapp.conf'.
  - BUG: 2592: from Stuart Kendrick - increase MAXTC to 16384
  - Restore AES-192 and AES-256 privacy protocols - from
draft-blumenthal-aes-usm-04 (precursor to RFC 3826)
  - BUG: 2622: Fix excessive indents in log file

snmpd:
  - Add new snmpd.conf option 'diskio' to monitor only selected disks.

snmptranslate:
  - Introduce bulk translation mode The special argument "-" causes
snmptranslate to enter bulk translation mode, in which it expects
one OID per line.

snmptrapd:
  - Add support for the latest libmysqlclient version
  - Correctly forward traps with Request-ID '0'.

mib2c:
  - PATCH: 1281, BUG: 2534 fixed mfd writability

python:
  - Patch from David Hankins to fix python binding error codes

unspecified:
  - Fixed crash when receiving non-standard compliant responses.
  - IPv6 support is now compiled by default.  If you need an IPv4-only
agent, use --disable-ipv6.
  - [BUG 2616]: Fix certain spelling errors in source code comments and
printed messages
  - [BUG 2624]: stop trying to use the deprecated perl uninstall
  - [BUG 2712]: Fix Perl module compilation
  - [BUG ]: #2615: Don't return incompletely parsed varbinds

DISMAN EXPRESSION MIB:
  - Avoid that enabling this MIB causes snmpd to crash during startup

DISMAN MIB:
  - Avoid reading past the end of a buffer

HP:
  - UX on ia64: Fix large fd set implementation

MIB:
  - Speed up reading /proc/net/tcp and /proc/net/tcp6

Windows:
  - BUG: 2550: Suppress netsnmp_assert s != (-1) messages
  - Feature-request: 181: Export snmp_api and ASN functions


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