Created attachment 197865 [details] patch testbuilds are fine. rel-notes: https://sourceforge.net/p/net-snmp/mailman/message/36386084/
Please test yourself.
This seems to fail for me if I have TKMIB unselected: ===> Extracting for net-snmp-5.8 => SHA256 Checksum OK for net-snmp-5.8.tar.gz. ===> Patching for net-snmp-5.8 ===> Applying extra patch /home/yuri/ws/net-snmp/files/extra-patch-local_Makefile.in 1 out of 1 hunks failed--saving rejects to local/Makefile.in.rej
And once installed, doing a `snmpwalk` makes snmpd crash: (lldb) bt * thread #1, name = 'snmpd', stop reason = signal SIGABRT * frame #0: 0x00000008010d4e0a libc.so.7`__sys_thr_kill at thr_kill.S:3 frame #1: 0x00000008010d31f4 libc.so.7`__raise(s=6) at raise.c:52 frame #2: 0x0000000801045a99 libc.so.7`abort at abort.c:67 frame #3: 0x0000000801033e37 libc.so.7`arena_dalloc_bin_locked_impl(tsdn=<unavailable>, arena=<unavailable>, slab=<unavailable>, ptr=<unavailable>, junked=<unavailable>) at jemalloc_internal_inlines_b.h:0 frame #4: 0x0000000800fe90b2 libc.so.7`__je_tcache_bin_flush_small(tsd=0x0000000800249090, tcache=<unavailable>, tbin=0x0000000800249590, binind=34, rem=1) at jemalloc_tcache.c:149 frame #5: 0x0000000800fe8d40 libc.so.7`__je_tcache_event_hard(tsd=<unavailable>, tcache=0x0000000800249250) at jemalloc_tcache.c:54 frame #6: 0x000000080104029e libc.so.7`iallocztm [inlined] tcache_event(tsd=<unavailable>) at tcache_inlines.h:37 frame #7: 0x000000080104027e libc.so.7`iallocztm [inlined] tcache_alloc_small(arena=<unavailable>, size=0) at tcache_inlines.h:99 frame #8: 0x00000008010401e2 libc.so.7`iallocztm [inlined] arena_malloc(size=<unavailable>, tcache=<unavailable>) at arena_inlines_b.h:94 frame #9: 0x000000080104010d libc.so.7`iallocztm(tsdn=<unavailable>, size=<unavailable>, ind=<unavailable>, zero=<unavailable>, tcache=0x0000000800249250, is_internal=<unavailable>, arena=0x0000000000000000, slow_path=<unavailable>) at jemalloc_internal_inlines_c.h:53 frame #10: 0x0000000801043434 libc.so.7`imalloc_body [inlined] imalloc_no_sample(sopts=<unavailable>, dopts=<unavailable>) at jemalloc_jemalloc.c:1713 frame #11: 0x0000000801043395 libc.so.7`imalloc_body(sopts=<unavailable>, dopts=<unavailable>, tsd=<unavailable>) at jemalloc_jemalloc.c:1909 frame #12: 0x000000080103a391 libc.so.7`__malloc(size=<unavailable>) at jemalloc_jemalloc.c:2042 frame #13: 0x000000080056369d libnetsnmp.so.35`_copy_varlist(var=0x0000000801d7d500, errindex=0, copy_count=9999) at snmp_client.c:456 frame #14: 0x0000000800563be0 libnetsnmp.so.35`_copy_pdu_vars(pdu=0x0000000801d67140, newpdu=0x0000000801d67280, drop_err=0, skip_count=-1, copy_count=10000) at snmp_client.c:529 frame #15: 0x0000000800563794 libnetsnmp.so.35`_clone_pdu(pdu=0x0000000801d67140, drop_err=0) at snmp_client.c:570 frame #16: 0x0000000800563757 libnetsnmp.so.35`snmp_clone_pdu(pdu=0x0000000801d67140) at snmp_client.c:597 frame #17: 0x00000008002a6706 libnetsnmpagent.so.35`init_agent_snmp_session(session=0x000000080153a400, pdu=0x0000000801d67140) at snmp_agent.c:1576 frame #18: 0x00000008002a5735 libnetsnmpagent.so.35`handle_snmp_packet(op=1, session=0x000000080153a400, reqid=803598491, pdu=0x0000000801d67140, magic=0x0000000000000000) at snmp_agent.c:2211 frame #19: 0x00000008005a38ba libnetsnmp.so.35`_sess_process_packet_handle_pdu(sessp=0x0000000801cde700, sp=0x000000080153a400, isp=0x0000000801539400, transport=0x0000000801ce5340, pdu=0x0000000801d67140) at snmp_api.c:5804 frame #20: 0x000000080059dfa1 libnetsnmp.so.35`_sess_process_packet(sessp=0x0000000801cde700, sp=0x000000080153a400, isp=0x0000000801539400, transport=0x0000000801ce5340, opaque=0x000000080155aa00, olength=60, packetptr="0,\x02\x01\x01\x04\x06public\xa1\x1f\x02\x04/\x02\x01", length=46) at snmp_api.c:5860 frame #21: 0x000000080059c8cb libnetsnmp.so.35`_sess_read(sessp=0x0000000801cde700, fdset=0x00007fffffffe9a8) at snmp_api.c:6121 frame #22: 0x000000080059c44d libnetsnmp.so.35`snmp_sess_read2(sessp=0x0000000801cde700, fdset=0x00007fffffffe9a8) at snmp_api.c:6394 frame #23: 0x000000080059c40a libnetsnmp.so.35`snmp_read2(fdset=0x00007fffffffe9a8) at snmp_api.c:5909 frame #24: 0x000000000020690f snmpd`receive at snmpd.c:1341 frame #25: 0x0000000000205d99 snmpd`main(argc=3, argv=0x00007fffffffed08) at snmpd.c:1125 frame #26: 0x0000000000204095 snmpd`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:74
(In reply to Yuri Pankov from comment #2) Thanks. I'll check and update the patch.
Testing still @work.
Testbuild on current: Failed ports: net-mgmt/py-yapsnmp:build devel/pear:build-depends databases/php72-pdo_mysql:build-depends archivers/php72-phar:build-depends sysutils/openhpi:build net/rtg:run-depends net/asterisk13:configure Skipped ports: net-mgmt/librenms net-mgmt/observium net/pear-Net_IPv4 net/pear-Net_IPv6 sysutils/cluster-glue TODO: check whether any of those is caused by the update.
Created attachment 202563 [details] patch-v2 testbuilds on 13a, 12.0a, 11.2a are fine. list of ports build to test: https://people.freebsd.org/~pi/logs/net-snmp/ports-list.txt depend failures: openhpi and py27-yapsnmp fail with or without update. asterisk13 fails in configure on 13 and 11.2, builds on 12, with the update, see https://people.freebsd.org/~pi/logs/net-snmp/asterisk13-config.log asterisk15 and 16 are fine.
(In reply to Kurt Jaeger from comment #6) The php-failures were unrelated to net-snmp.
There's a patch for openhpi to upgrade to 3.8.0 in PR#231096
(In reply to Yuri Pankov from comment #3) I tested snmpd with this: snmpd_enable="YES" snmpd_flags="-a -C" snmpd_conffile="/usr/local/etc/snmpd.conf" and the config from https://people.freebsd.org/~pi/logs/snmpd.conf and running this command: snmpwalk -v 1 -c public 127.0.0.1 It did not crash. How can I reproduce the crash ?
fails to build with NOIPV6 selected (testing, if this the cause)
Created attachment 202690 [details] patch-v3 - removed NOIPV6 option (looks non-trivial to patch) - fixed BIN_FILES list if TLS is not selected TODO: needs a bit of portlint cleanup
Created attachment 202692 [details] patch-v4 Final patch version, testbuilds are fine.
Created attachment 205132 [details] patch-v5 Fixes build on recent 13
Created attachment 205592 [details] patch-v6 patch updated after r506141
A commit references this bug: Author: pi Date: Sat Sep 28 15:16:26 UTC 2019 New revision: 513140 URL: https://svnweb.freebsd.org/changeset/ports/513140 Log: net-mgmt/net-snmp: update 5.7.3 -> 5.8 PR: 232025 Approved by: zi (maintainer timeout) Relnotes: https://sourceforge.net/p/net-snmp/mailman/message/36386084/ Changes: head/net-mgmt/net-snmp/Makefile head/net-mgmt/net-snmp/distinfo head/net-mgmt/net-snmp/files/extra-patch-local_Makefile.in head/net-mgmt/net-snmp/files/extra-patch-openssl11 head/net-mgmt/net-snmp/files/patch-Makefile.in head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_cpu_cpu__sysctl.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_cpu_cpu_sysctl.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_fsys_fsys__getfsstats.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_memory_memory__freebsd.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_icmp.h head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_tcpTable.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_udpTable.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_tcp-mib_data__access_tcpConn__freebsd4.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_ucd-snmp_diskio.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_udp-mib_data__access_udp__endpoint__freebsd4.c head/net-mgmt/net-snmp/files/patch-include__net-snmp__net-snmp-config.h.in head/net-mgmt/net-snmp/files/patch-include_net-snmp_library_transform__oids.h head/net-mgmt/net-snmp/files/patch-include_net-snmp_system_freebsd13.h head/net-mgmt/net-snmp/files/patch-kthreads head/net-mgmt/net-snmp/files/patch-perl5.23 head/net-mgmt/net-snmp/files/patch-snmplib_snmp__api.c head/net-mgmt/net-snmp/files/patch-snmplib_snmpusm.c head/net-mgmt/net-snmp/files/patch-snmpusm.c head/net-mgmt/net-snmp/files/patch-tcpTable.c head/net-mgmt/net-snmp/files/patch-transform_oids.h head/net-mgmt/net-snmp/files/patch-udpTable.c head/net-mgmt/net-snmp/pkg-plist
Created attachment 207965 [details] revert revert, for zi to check.
re-open, because of strange issues with 5.8.
Created attachment 207967 [details] revert-v2 next attempt at revert-patch
A commit references this bug: Author: pi Date: Mon Sep 30 21:45:50 UTC 2019 New revision: 513422 URL: https://svnweb.freebsd.org/changeset/ports/513422 Log: net-mgmt/net-snmp: revert back to 5.7.3 due to side-effects PR: 232025 Submitted by: dvl Reviewed by: zi, otis@sk.FreeBSD.org Changes: head/net-mgmt/net-snmp/Makefile head/net-mgmt/net-snmp/distinfo head/net-mgmt/net-snmp/files/extra-patch-local_Makefile.in head/net-mgmt/net-snmp/files/extra-patch-openssl11 head/net-mgmt/net-snmp/files/patch-Makefile.in head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_cpu_cpu__sysctl.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_cpu_cpu_sysctl.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_fsys_fsys__getfsstats.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_hardware_memory_memory__freebsd.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_icmp.h head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_tcpTable.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_mibII_udpTable.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_tcp-mib_data__access_tcpConn__freebsd4.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_ucd-snmp_diskio.c head/net-mgmt/net-snmp/files/patch-agent_mibgroup_udp-mib_data__access_udp__endpoint__freebsd4.c head/net-mgmt/net-snmp/files/patch-include__net-snmp__net-snmp-config.h.in head/net-mgmt/net-snmp/files/patch-include_net-snmp_library_transform__oids.h head/net-mgmt/net-snmp/files/patch-include_net-snmp_system_freebsd13.h head/net-mgmt/net-snmp/files/patch-kthreads head/net-mgmt/net-snmp/files/patch-perl5.23 head/net-mgmt/net-snmp/files/patch-snmplib_snmp__api.c head/net-mgmt/net-snmp/files/patch-snmplib_snmpusm.c head/net-mgmt/net-snmp/files/patch-snmpusm.c head/net-mgmt/net-snmp/files/patch-tcpTable.c head/net-mgmt/net-snmp/files/patch-transform_oids.h head/net-mgmt/net-snmp/files/patch-udpTable.c head/net-mgmt/net-snmp/pkg-plist
I upgraded a jail with 5.7.3_20 -> 5.7.3_20,1 --- starts just fine with existing configuration.
(In reply to Kurt Jaeger from comment #18) Could you please give us some pointer to what these problems are? I've already upgraded some machines and it would help to know what I should expect. Thanks.
1) If you use snmpd, with a snmpd.conf from the standard template, adding agentAddress udp:127.0.0.1:161 then snmpd does not start. For unknown reasons, snmpd reads the config file twice on startup, and during startup, always opens udp:127.0.0.1:161 for LISTEN. So if you add this statment, snmpd tries to open the same ip/port twice, fails and terminates. 2) Renato Botelho (garga@) observed a crash (which, strangly, also occurred after he went back to 5.7.x). I have some mails with details, but we probably need to get in touch with garga for more details. I have not heard issues outside of snmpd, but maybe it's the time for all net-snmp users to do more testing.
(In reply to Kurt Jaeger from comment #23) Thanks for your answer. Just for the record, I've had a related problem: _ I had no agentaddress in my conf file; _ the box has several network interfaces, including: em0: 192.168.xxx.1; tun0: 10.0.yy.2; _ the box has a stateful ipfw firewall; _ a machine from outside the network connected to snmpd through tun0 on IP 192.168.xxx.1. Previous versions responded with a source address of 192.168.xxx.1 and the stateful firewall rule matched, so everything worked. With 5.8, snmp, altough contacted on 192.168.xxx.1, responded with a source address of 10.0.yy.2 and ipfw denied the answer. I solved by adding: agentaddress 192.168.xxx.1 Just in case this helps others, but perhaps a pkg-message should state this changes?
In my case: * running snmpd in a jail * no IP address on lo0 * single IP address on another port * using EXTENDS in snmpd.conf file so I must specify a .conf file The code SEEMS to require localhost, which is not what I want in a jail. $ grep snmp /etc/rc.conf snmpd_flags="-a -r" snmpd_conffile="/usr/local/etc/snmpd.conf" snmpd_enable="YES" My conf file isn't much different from sample [dan@dev-nginx01:~] $ diff -ruN /usr/local/share/snmp/snmpd.conf.example /usr/local/etc/snmpd.conf --- /usr/local/share/snmp/snmpd.conf.example 2019-09-30 21:50:24.000000000 +0000 +++ /usr/local/etc/snmpd.conf 2019-09-30 20:47:48.270296000 +0000 @@ -12,7 +12,7 @@ # # Listen for connections from the local system only -agentAddress udp:127.0.0.1:161 +agentAddress udp:10.55.0.39:161 # Listen for connections on all interfaces (both IPv4 *and* IPv6) #agentAddress udp:161,udp6:[::1]:161 @@ -74,8 +74,8 @@ # Note that setting these values here, results in the corresponding MIB objects being 'read-only' # See snmpd.conf(5) for more details -sysLocation Sitting on the Dock of the Bay -sysContact Me <me@example.org> +sysLocation BSD Cabal HQ +sysContact dan@example.org # Application + End-to-End layers sysServices 72 @@ -154,8 +154,8 @@ # # Arbitrary extension commands # - extend test1 /bin/echo Hello, world! - extend-sh test2 echo Hello, world! ; echo Hi there ; exit 35 +# extend test1 /bin/echo Hello, world! +# extend-sh test2 echo Hello, world! ; echo Hi there ; exit 35 #extend-sh test3 /bin/sh /tmp/shtest # Note that this last entry requires the script '/tmp/shtest' to be created first, @@ -191,3 +191,6 @@ # Listen for network connections (from localhost) # rather than the default named socket /var/agentx/master #agentXSocket tcp:localhost:705 + +extend nginx /usr/local/etc/snmp/nginx-stats +extend phpfpmsp /usr/local/etc/snmp/phpfpm-sp [dan@dev-nginx01:~] $
Reverse dependencies are to be also bumped as libnetsnmp.so version changed from 35 to 30. For example, zabbix server needs to be recompiled, others might suffer from this also.
Gentoo reports something similar w/interfaces. Some fix might be already in the tree: https://github.com/net-snmp/net-snmp/issues/34#issuecomment-552069084
Please also take note of this little patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243048
Handled as part of the 5.9 update