|Summary:||net-mgmt/net-snmp still defines IPv6 macros when IPv6 is disabled at build time.|
|Product:||Ports & Packages||Reporter:||Ivan <bsd>|
|Component:||Individual Port(s)||Assignee:||Ryan Steinmetz <zi>|
|Severity:||Affects Only Me||CC:||cy, zi|
Description Ivan 2020-10-04 19:12:37 UTC
Created attachment 218524 [details] poudriere build log nuts doesn't build if ipv6 support disabled in net-mgmt/net-snmp
Comment 1 Cy Schubert 2020-10-06 05:56:16 UTC
Can you provide the output of the following command, please? grep NETSNMP_TRANSPORT_UDPIPV6_DOMAIN /usr/local/include/net-snmp/net-snmp-config.h
Comment 2 Ivan 2020-10-06 12:22:18 UTC
#define NETSNMP_TRANSPORT_UDPIPV6_DOMAIN 1 #ifdef NETSNMP_TRANSPORT_UDPIPV6_DOMAIN # define SNMP_TRANSPORT_UDPIPV6_DOMAIN NETSNMP_TRANSPORT_UDPIPV6_DOMAIN
Comment 3 Cy Schubert 2020-10-06 13:40:01 UTC
I discovered this too, here, last night. net-snmp is failing to undefine NETSNMP_TRANSPORT_UDPIPV6_DOMAIN, making apps believe IPv6 is still compiled in. I will assign this PR to zi@, the maintainer of net-snmp. He should change the title to something like "net-mgmt/net-snmp still defines IPv6 macros when IPv6 is disabled at build time."
Comment 4 Ivan 2020-10-06 14:20:59 UTC
Thanks! I'll enable ipv6 in net-mgmt/net-snmp for my builds then.
Comment 5 Cy Schubert 2020-10-06 14:30:07 UTC
For now, yes. NETSNMP_TRANSPORT_TCPIPV6_DOMAIN is also defined as 1 when IPv6 is disabled. I suspect that zi@, after some investigation, will discover that there is much more broken in net-snmp than just this one macro definition when IPv6 is disabled and will likely need to push this upstream for ultimate resolution (without spending too much time at this).
Comment 6 Ryan Steinmetz 2020-10-06 15:37:55 UTC
My inclination is to just convert the existing IPV6 OPTION to not an OPTION and force it to be on. Do either of you see a reason not to do this?
Comment 7 Ivan 2020-10-06 15:45:29 UTC
Well, I'd say I don't know such reason. I believe, ipv6 knob in kernel is deprecated or removed, so probably, it's time to clean this option from ports as well, especially if it's hard to maintain.
Comment 8 Cy Schubert 2020-10-06 15:51:41 UTC
Though my ISP (cable company) doesn't support it, I use IPv6 internally for ipfilter testing. I enable it for everything. Disabling IPv6 in net-snmp may have other issues: https://sourceforge.net/p/net-snmp/bugs/2903/. If it has this problem in Linux I expect to have the same problem in FreeBSD. In this case they fixed the logging but not the cause. This suggests that there's much more broken in net-snmp when IPv6 is disabled. It probably makes sense to disable the option entirely. You might want to discuss this in a little more detail in the commit log message to make sure nobody follows up by re-enabling the no IPv6 option.
Comment 9 Cy Schubert 2020-10-06 17:50:29 UTC
(In reply to Ivan from comment #7) INET6 can still be removed from your kernel config. Doing so might expose some bugs though. I don't know anyone who runs a kernel without the INET6 option enabled.
Comment 10 Ryan Steinmetz 2020-10-06 18:00:38 UTC
Maybe the easiest thing, for now, is to make IPV6 enabled by default. That should fix everyone using the freebsd.org packages and make things work out of the box. If people elect to make custom builds and run into issues, then that's probably a separate issue. Thoughts?
Comment 11 Cy Schubert 2020-10-06 18:25:12 UTC
Enabled by default and remove the option entirely until the upstream can fix the multitude of problems. They're on GH at https://github.com/net-snmp/net-snmp. Maybe raise an issue. And while we're at it USE_GH=yes and maybe even a net-snmp-devel port, though that might be a little more trouble than it's worth. Feeding the bears (like in the park), as a co-worker of mine says, can have consequences for the developer or support person. But something to thing about anyway. My krb5-devel, nut-devel and cfengine-devel ports haven't resulted in any extra tickets though. I'll leave it to you to decide. Personally, I use nut-devel since there hasn't been a release of nut for quite some time.