net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: Correct way of stopping snmpd

[Niels B. <ni...@ba...>]

Den 21-05-2024 kl. 13:34 skrev Niels Baggesen:

> SIGTERM is not kill -9, it is kill -16. kill -9 is SIGKILL

Whoops, minor typo, SIGTERM is 15, not 16. Thanks to jhawk!

/Niels

-- 
Niels Baggesen -- @home -- Århus -- Denmark -- ni...@ba...
The purpose of computing is insight, not numbers  --  R W Hamming

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Getting listening port number while processing request

[Teus B. <teu...@gm...>]

On Mon, 13 May 2024 at 14:26, Bart Van Assche <bva...@ac...> wrote:

> On 5/13/24 03:05, Teus Benschop wrote:
>
>
> The patches work for the TCP domain, and that certainly is sufficient for
> us, and we are happy.
>
> Would it also be helpful if I would create similar patches for the *UDP*
> domain?
>
> Generalizing this work by adding UDP support for this mechanism sounds
> good to me.
>
>
>
Hello Bart,

Thank you for the go-ahead.
I went ahead and created the patch for the UDP domain.
In line with the previous patch where you had added support for IPv6, I
have added that support to this patch too.
It was tested and works fine when the snmpd listens on udp, and when it
listens on udp6.
The patch is attached to this email.
If it could be merged into the source code, we would be so grateful.

Thank you,
Teus Benschop

Re: Correct way of stopping snmpd

[Niels B. <ni...@ba...>]

Den 21-05-2024 kl. 10:30 skrev Pushpa Thimmaiah:
> Hi All,
> 
> Kindly confirm  that 'kill -9' is valid way to stop snmpd.
> 
> I am writing service script for systemctl  to stop snmpd and would like 
> to understand correct way of stopping the daemon.
> According to Source code agent/snmpd.c ,  SIGTERM (kill -9) , SIGINT 
> (ctl+c) are for snmpd shutdown.

SIGTERM is not kill -9, it is kill -16. kill -9 is SIGKILL

/Niels

-- 
Niels Baggesen -- @home -- Århus -- Denmark -- ni...@ba...
The purpose of computing is insight, not numbers  --  R W Hamming

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Correct way of stopping snmpd

[Josef Ř. <jr...@re...>]

You may take a look at
https://src.fedoraproject.org/rpms/net-snmp/blob/rawhide/f/snmpd.service
for a working example in Fedora/RHEL.

Best regards

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


On Tue, May 21, 2024 at 10:29 AM Pushpa Thimmaiah <
pus...@gm...> wrote:

> Hi All,
>
> Kindly confirm  that 'kill -9' is valid way to stop snmpd.
>
> I am writing service script for systemctl  to stop snmpd and would like to
> understand correct way of stopping the daemon.
> According to Source code agent/snmpd.c ,  SIGTERM (kill -9) , SIGINT
> (ctl+c) are for snmpd shutdown.
>
>
> Thanks,
> Pushpa.T
>
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Correct way of stopping snmpd

[Pushpa T. <pus...@gm...>]

Hi All,

Kindly confirm  that 'kill -9' is valid way to stop snmpd.

I am writing service script for systemctl  to stop snmpd and would like to
understand correct way of stopping the daemon.
According to Source code agent/snmpd.c ,  SIGTERM (kill -9) , SIGINT
(ctl+c) are for snmpd shutdown.


Thanks,
Pushpa.T

AES192 and SHA256 support

[sukeerthi bj <suk...@gm...>]

Hi,

I see AES192 and SHA256 support in SNMP, but wanted to understand if below
code is doing right? Here for pcks_generate_ku only CKM_SHA_1 is passed.
For SHA256 should not CKM_SHA256 be passed here instead?
Can anyone have a look into this and explain?

#ifndef NETSNMP_DISABLE_MD5
if (NETSNMP_USMAUTH_HMACMD5 == auth_type)
return pkcs_generate_Ku(CKM_MD5, P, pplen, Ku, kulen);
else
#endif
if (NETSNMP_USMAUTH_HMACSHA1 == auth_type)
return pkcs_generate_Ku(CKM_SHA_1, P, pplen, Ku, kulen);
else {
return (SNMPERR_GENERR);

AES192 and AES256

[north digitalphenomena.c. <no...@di...>]

I've been attempting to get AES192 and AES256 configured
the 5.9.3 version of net-snmp.

snmpusm only recognizes DES and AES.
The configure-summary says this:
Encryption support:         DES AES AES128 AES192 AES192C AES256 AES256C

Wouldn't the configure-summary declaration imply that the protocols
are in fact part of the system?

I do have NETSNMP_DRAFT_BLUMENTHAL_AES_04 defined.

Have I overlooked something? There appears to be nothing about this in the documentation. (I am also well aware of the issue with AES192 and above being stranded for several years...)

Thanks,

--Michael

Re: Getting listening port number while processing request

[Bart V. A. <bva...@ac...>]

On 5/13/24 03:05, Teus Benschop wrote:
>
> The patches work for the TCP domain, and that certainly is sufficient 
> for us, and we are happy.
>
> Would it also be helpful if I would create similar patches for the 
> *UDP* domain?

Generalizing this work by adding UDP support for this mechanism sounds 
good to me.

Thanks,

Bart.

Re: Getting listening port number while processing request

[Teus B. <teu...@gm...>]

On Thu, 9 May 2024 at 18:20, Teus Benschop <teu...@gm...> wrote:

>
> I have tested the master branch on GitHub, including branch V5-9, on
> getting the local listening port number of the agent.
> It works well for TCP over IPv4 and also over IPv6.
> In both cases I get to see the local listening port number where the SNMP
> request  was sent to.
>
>
> Hello,

The patches work for the TCP domain, and that certainly is sufficient for
us, and we are happy.

Would it also be helpful if I would create similar patches for the *UDP*
domain?

Take care,

Teus.

Re: Getting listening port number while processing request

[Teus B. <teu...@gm...>]

Hello Bart,

Thank you for adding IPv6 support to the patch, and for integrating all the
changes into the V5-9 branch.

We are so glad about that.

I have tested the master branch on GitHub, including branch V5-9, on
getting the local listening port number of the agent.
It works well for TCP over IPv4 and also over IPv6.
In both cases I get to see the local listening port number where the SNMP
request  was sent to.

Thanks again, and take care,

Teus

Re: Getting listening port number while processing request

[Bart V. A. <bva...@ac...>]

On 5/8/24 1:42 AM, Teus Benschop wrote:
>
> I have implemented the f_setup_session() callback in 
> the snmpTCPBaseDomain.h/.c files.
> This callback obtains the port number and copies that into the session 
> object.
> Then from the session object, the local_port is available while 
> processing the SNMP requests.
> I am happy it works and that we can use this local_port in our 
> software, that is so helpful.
>
> The patch with the above modification is attached.
> It would be so great if this patch can make it in the official tarball 
> of Net-SNMP.

A slightly different patch has been applied on the V5-9-patches and 
master branches. Please take a look and please help with testing that 
patch. See also commit 8f3cedfa723c ("libsnmp: Copy the listening port 
number into snmp_session.local_port").

Thanks,

Bart.

Re: Getting listening port number while processing request

[Teus B. <teu...@gm...>]

On Wed, 3 Apr 2024 at 18:45, Bart Van Assche <bva...@ac...> wrote:

> I think this is the callchain for registering the ports that the agent
> listens on:
>
> init_master_agent()
>   netsnmp_agent_listen_on()
>     netsnmp_transport_open_server()
>     netsnmp_register_agent_nsap()
>       netsnmp_sess_config_transport()
>       snmp_add()
>         snmp_sess_add_ex()
>           transport->f_setup_session()
>
> One possible approach is to implement the .f_setup_session() callback in
> the TCP transport and to make it copy the port information from the
> transport into the session.
>
>
> Hi Bart,

The possible approach that is suggested appears to work very well.

I have implemented the f_setup_session() callback in
the snmpTCPBaseDomain.h/.c files.
This callback obtains the port number and copies that into the session
object.
Then from the session object, the local_port is available while processing
the SNMP requests.
I am happy it works and that we can use this local_port in our software,
that is so helpful.

The patch with the above modification is attached.
It would be so great if this patch can make it in the official tarball of
Net-SNMP.

Thank you for the suggestions and all the help all along.

Regards,

Teus

Re: libkvm usage on FreeBSD

[Bart V. A. <bva...@ac...>]

On 4/30/24 10:53 AM, Mark Johnston wrote:
> Fix var_udp6 and var_tcp6 on FreeBSD
 > [ ... ]

This patch has been applied on the V5-9-patches and master branches.
Thanks for the patch!

Bart.

Re: libkvm usage on FreeBSD

[Mark J. <ma...@fr...>]

On Fri, Apr 12, 2024 at 03:51:51PM -0700, Bart Van Assche wrote:
> On 4/12/24 7:29 AM, Mark Johnston wrote:
> > Do you mean that on FreeBSD we should always perform an unprivileged
> > kvm_openfile() call, no matter whether --without-kmem-usage is
> > specified?
> 
> Yes, that's what I'm proposing. If someone disagrees, please share your
> opinion now.

I spent some more time testing this and hit a small problem with the
IPv6-TCP MIB.  The implementation doesn't compile on FreeBSD (it
references a non-existent field in struct inpcb) and so is disabled in
the FreeBSD ports tree, so I didn't catch it earlier when testing a
patch to avoid using /dev/kmem.

The implementation of var_tcp6() and var_udp6() used on FreeBSD isn't
quite right; it uses the wrong structures to access the output of the
net.inet.{tcp,udp}.pcblist sysctls, and var_tcp6() tries to use kmem
access to get the TCP state of the matched connection, which at least on
FreeBSD isn't necessary (net.inet.tcp.pcblist exports that field
directly via struct xtcpcb).

I wrote the patch below to fix this and manually verified the MIB values
on a test system.

commit f131c5b7dd599cf6c3a15b372075d299262cbfee
Author: Mark Johnston <ma...@Fr...>
Date:   Tue Apr 30 10:23:25 2024 -0400

    Fix var_udp6 and var_tcp6 on FreeBSD

diff --git a/agent/mibgroup/mibII/ipv6.c b/agent/mibgroup/mibII/ipv6.c
index f44568c9fa..1ec05efce2 100644
--- a/agent/mibgroup/mibII/ipv6.c
+++ b/agent/mibgroup/mibII/ipv6.c
@@ -5,9 +5,6 @@
 
 #include <net-snmp/net-snmp-config.h>
 #include <net-snmp/net-snmp-features.h>
-/* For FreeBSD */
-#define _WANT_INPCB 1
-#define _WANT_TCPCB 1
 #include <sys/types.h>
 #include <sys/socket.h>
 #ifdef HAVE_SYS_IOCTL_H
@@ -1513,8 +1510,10 @@ var_udp6(register struct variable * vp,
     int             result;
     int             i, j;
     caddr_t         p;
-#if defined(openbsd4) || defined(freebsd3)
+#if defined(openbsd4)
     static struct inpcb in6pcb, savpcb;
+#elif defined(freebsd3)
+    static struct xinpcb in6pcb, savpcb;
 #else
     static struct in6pcb in6pcb, savpcb;
 #endif
@@ -1614,8 +1613,7 @@ var_udp6(register struct variable * vp,
         DEBUGMSGTL(("mibII/ipv6", "looping: p=%p\n", p));
 
 #if defined(freebsd3)
-	/* To do: fill in in6pcb properly. */
-	memset(&in6pcb, 0, sizeof(in6pcb));
+	in6pcb = *(struct xinpcb *) xig;
 #elif defined(darwin)
 	in6pcb = ((struct xinpcb *) xig)->xi_inp;
 #else
@@ -2108,12 +2106,18 @@ var_tcp6(register struct variable * vp,
     int             result;
     int             i, j;
     caddr_t         p;
-#if defined(openbsd4) || defined(freebsd3)
+#if defined(openbsd4)
     static struct inpcb in6pcb, savpcb;
+#elif defined(freebsd3)
+    static struct xinpcb in6pcb;
+    static int      savstate;
 #else
     static struct in6pcb in6pcb, savpcb;
 #endif
+#if !defined(freebsd3)
     struct tcpcb    tcpcb;
+#endif
+    int             state;
     int             found, savnameLen;
 #if defined(__NetBSD__) && __NetBSD_Version__ >= 106250000 || defined(openbsd4)	/*1.6Y*/
     struct inpcbtable tcbtable;
@@ -2208,8 +2212,7 @@ var_tcp6(register struct variable * vp,
         DEBUGMSGTL(("mibII/ipv6", "looping: p=%p\n", p));
 
 #if defined(freebsd3)
-	/* To do: fill in in6pcb properly. */
-	memset(&in6pcb, 0, sizeof(in6pcb));
+	in6pcb = ((struct xtcpcb *) xig)->xt_inp;
 #elif defined(dragonfly)
 	in6pcb = xtp->xt_inp;
 #elif defined(darwin)
@@ -2294,7 +2297,11 @@ var_tcp6(register struct variable * vp,
 #endif
         result = snmp_oid_compare(name, *length, newname, j);
         if (exact && (result == 0)) {
+#if defined(freebsd3)
+                savstate = ((struct xtcpcb *) xig)->t_state;
+#else
                 memcpy(&savpcb, &in6pcb, sizeof(savpcb));
+#endif
                 savnameLen = j;
                 memcpy(savname, newname, j * sizeof(oid));
                 found++;
@@ -2305,7 +2312,11 @@ var_tcp6(register struct variable * vp,
              */
             if ((savnameLen == 0) ||
               (snmp_oid_compare(savname, savnameLen, newname, j) > 0)) {
+#if defined(freebsd3)
+                savstate = ((struct xtcpcb *) xig)->t_state;
+#else
                 memcpy(&savpcb, &in6pcb, sizeof(savpcb));
+#endif
                 savnameLen = j;
                 memcpy(savname, newname, j * sizeof(oid));
                 found++;
@@ -2344,19 +2355,27 @@ var_tcp6(register struct variable * vp,
         return NULL;
     *length = savnameLen;
     memcpy((char *) name, (char *) savname, *length * sizeof(oid));
+#if defined(freebsd3)
+    state = savstate;
+#elif defined(__NetBSD__) && __NetBSD_Version__ >= 999010400
     memcpy(&in6pcb, &savpcb, sizeof(savpcb));
-#if defined(__NetBSD__) && __NetBSD_Version__ >= 999010400
     if (!NETSNMP_KLOOKUP(in6pcb.in6p_pcb.inp_ppcb, (char *) &tcpcb, sizeof(tcpcb))) {
         DEBUGMSGTL(("mibII/ipv6", "klookup fail for tcb6.tcpcb at %p\n",
                     in6pcb.in6p_pcb.inp_ppcb));
+	found = 0;
+	return NULL;
+    }
+    state = (int)tcpcb.t_state;
 #else
+    memcpy(&in6pcb, &savpcb, sizeof(savpcb));
     if (!NETSNMP_KLOOKUP(in6pcb.inp_ppcb, (char *) &tcpcb, sizeof(tcpcb))) {
 	DEBUGMSGTL(("mibII/ipv6", "klookup fail for tcb6.tcpcb at %p\n",
 		    in6pcb.inp_ppcb));
-#endif
 	found = 0;
 	return NULL;
     }
+    state = (int)tcpcb.t_state;
+#endif
     *write_method = 0;
     *var_len = sizeof(long);    /* default to 'long' results */
 
@@ -2368,7 +2387,7 @@ var_tcp6(register struct variable * vp,
     DEBUGMSGTL(("mibII/ipv6", "magic=%d\n", vp->magic));
     switch (vp->magic) {
     case IPV6TCPCONNSTATE:
-        long_return = mapTcpState((int)tcpcb.t_state);
+        long_return = mapTcpState(state);
         return (u_char *) & long_return;
     default:
         break;

Re: length of snmpEngineID

[Pushpa T. <pus...@gm...>]

Hi Magnus Fromreide,

Thanks for clarifying.

Thanks,
Pushpa.T

On Thu, Apr 25, 2024 at 10:17 AM Magnus Fromreide <ma...@ly...>
wrote:

> On Tue, Apr 23, 2024 at 09:51:08AM +0530, Pushpa Thimmaiah wrote:
> > Hi All,
> >
> > Could you please let me know length of snmpEngineID.  Is it 12 octets or
> 32
> > octets.
> >
> > In RFC 3411 (https://www.ietf.org/rfc/rfc3411.txt) ,
> > mib object 'snmpEngineID' says  12 octets in description and 32 octet in
>
> You have to read the whole text.
>
> An snmpEngineID has a syntax of OCTET STRING (SIZE(5..32))
>
> If the first bit of the snmpEngineID is 0 and it is 12 octets long then it
> might have been generated using the algorithm described in bullet 2 which
> is
> copied from rfc1910.
>
> If the first bit is 1 then it is generated in accordance with one of the
> methods in bullet 3 (or RFC5343) but it is important to notice that bullets
> 1-3 are just an recommended algorithm, not a mandatory one so you should
> treat snmpEngineID a a variable length string and not attempt to parse it.
>
> /MF
>

Re: length of snmpEngineID

[Magnus F. <ma...@ly...>]

On Tue, Apr 23, 2024 at 09:51:08AM +0530, Pushpa Thimmaiah wrote:
> Hi All,
> 
> Could you please let me know length of snmpEngineID.  Is it 12 octets or 32
> octets.
> 
> In RFC 3411 (https://www.ietf.org/rfc/rfc3411.txt) ,
> mib object 'snmpEngineID' says  12 octets in description and 32 octet in

You have to read the whole text.

An snmpEngineID has a syntax of OCTET STRING (SIZE(5..32))

If the first bit of the snmpEngineID is 0 and it is 12 octets long then it
might have been generated using the algorithm described in bullet 2 which is
copied from rfc1910.

If the first bit is 1 then it is generated in accordance with one of the
methods in bullet 3 (or RFC5343) but it is important to notice that bullets
1-3 are just an recommended algorithm, not a mandatory one so you should
treat snmpEngineID a a variable length string and not attempt to parse it.

/MF

length of snmpEngineID

[Pushpa T. <pus...@gm...>]

Hi All,

Could you please let me know length of snmpEngineID.  Is it 12 octets or 32
octets.

In RFC 3411 (https://www.ietf.org/rfc/rfc3411.txt) ,
mib object 'snmpEngineID' says  12 octets in description and 32 octet in
the range .

Kindly guide.

Pushpa.T

Fw: Trap Sending Not OK.

[Pramav S <pr...@ou...>]

Issue: Trap not being sent from Application.

Context: Currently, I am porting application from CentOS 7 to Oracle Linux.
In CentOS7, Libraries from 5.7.3 was used by the Application. All things works OK. SNMP GET/SET and Traps send from Application was OK.

With Oracle Linux - Libraries from 5.8-28 is used by the ported Application. No specific Application code changed for this version.
But SNMP GET/SET is OK. But Trap send from Application is not OK. Not packet is seen going out. send_v2trap()​ call isn't happening?


I have the following in the snmpd.conf with Trap target information.

`snmpNotifyTable  "allTraps" "allTraps" 1 3 1`
snmpNotifyTable "allTraps" "allTraps" 1 3 1 targetAddr "test" .1.3.6.1.6.1.1 0x0a6400a000a2 0 0 "allTraps"​ snmpV2c 3 1

What could I be missing?



Thanks,
Prabhu

Re: libkvm usage on FreeBSD

[Mark J. <ma...@fr...>]

On Fri, Apr 12, 2024 at 03:51:51PM -0700, Bart Van Assche wrote:
> On 4/12/24 7:29 AM, Mark Johnston wrote:
> > Do you mean that on FreeBSD we should always perform an unprivileged
> > kvm_openfile() call, no matter whether --without-kmem-usage is
> > specified?
> 
> Yes, that's what I'm proposing. If someone disagrees, please share your
> opinion now.

I can't see any reason not to go ahead with that, for what it's worth.
I'm confident that none of the existing code in net-snmp needs /dev/kmem
access on FreeBSD, and it shouldn't be required by new code.

Re: libkvm usage on FreeBSD

[Bart V. A. <bva...@ac...>]

On 4/12/24 7:29 AM, Mark Johnston wrote:
> Do you mean that on FreeBSD we should always perform an unprivileged
> kvm_openfile() call, no matter whether --without-kmem-usage is
> specified?

Yes, that's what I'm proposing. If someone disagrees, please share your
opinion now.

Thanks,

Bart.

None

[Alex K. <krj...@ma...>]

Hello!
 
In our project we use net-snmp 5.7.3 and we are going to migrate to 5.9.4.
And the main issue for our project during migration as I could see is that previously we used authProtocol MD5 for authentication of SNMP users. And the support of MD5 authProtocol was removed from 5.9.4.
So please could advice me if there is a way that we can change automatically authProtocol  for the SNMP users after upgrade of snmp (I mean on the side of net-snmp) or it can be done only manually with for example «snmpusm» utils?
 
Regards,
Alexei
 

Re: libkvm usage on FreeBSD

[Mark J. <ma...@fr...>]

On Fri, Apr 12, 2024 at 07:13:41AM -0700, Bart Van Assche wrote:
> On 4/12/24 06:44, Mark Johnston wrote:
> > I would like to introduce the patch below, which gets compiled when
> > --without-kmem-usage is specified.  In this case, snmpd will still use
> > libkvm, but won't open /dev/(k)mem.  In my testing so far, this works
> > perfectly.  Does anyone have any thoughts on this patch/approach?  Would
> > the net-snmp project be willing to accept the patch?  Thank you in
> > advance for any feedback or guidance.
> 
> What privileges are required to call kvm_open() on FreeBSD? Are
> the same privileges required as for opening /dev/kmem or not?

The only privileges required are those needed to open the file.  So,
kvm_openfiles(NULL, NULL, NULL, O_RDONLY, err) requires root privileges,
because it tries to open /dev/mem.  If I change the second parameter to
"/dev/null", then any user can call it successfully, and most of the
kvm_* functions will still work as expected.

> If not,
> has it been considered to make init_kmem() call kvm_open() on FreeBSD
> independent of whether or not --without-kmem-usage has been specified?

Assuming I don't misunderstand, that's effectively what my patch does -
it just does so in a separate implementation of init_kmem().

Do you mean that on FreeBSD we should always perform an unprivileged
kvm_openfile() call, no matter whether --without-kmem-usage is
specified?

Re: libkvm usage on FreeBSD

[Bart V. A. <bva...@ac...>]

On 4/12/24 06:44, Mark Johnston wrote:
> I would like to introduce the patch below, which gets compiled when
> --without-kmem-usage is specified.  In this case, snmpd will still use
> libkvm, but won't open /dev/(k)mem.  In my testing so far, this works
> perfectly.  Does anyone have any thoughts on this patch/approach?  Would
> the net-snmp project be willing to accept the patch?  Thank you in
> advance for any feedback or guidance.

What privileges are required to call kvm_open() on FreeBSD? Are
the same privileges required as for opening /dev/kmem or not? If not,
has it been considered to make init_kmem() call kvm_open() on FreeBSD
independent of whether or not --without-kmem-usage has been specified?

Thanks,

Bart.

libkvm usage on FreeBSD

[Mark J. <ma...@fr...>]

I'm quite new to net-snmp, so apologies in advance if this is the wrong
place to discuss patches.

Currently, when one runs snmpd on FreeBSD, it keeps /dev/mem and
/dev/kmem open.  This is a result of using kvm_openfiles() to get a kvm
descriptor, which is used to implement various MIBs (via kvm_getprocs(),
kvm_getswapinfo(), etc.).  However, the libkvm interfaces used by
net-snmp don't actually require /dev/mem or /dev/kmem - they are all
implemented using sysctls.

I would like to have snmpd not hold /dev/(k)mem open.  I can of course
compile using --without-kmem-usage, but that disables the use of libkvm,
so all of that code (used to implement the hostres MIB, for instance)
would need to be rewritten.  However, it turns out that one can ask
kvm_openfiles() to not open /dev/mem and /dev/kmem, by passing
"/dev/null" as the path.  In fact, snmpd already contains code to do
this, but it's only done in a fallback path in init_kmem().

I would like to introduce the patch below, which gets compiled when
--without-kmem-usage is specified.  In this case, snmpd will still use
libkvm, but won't open /dev/(k)mem.  In my testing so far, this works
perfectly.  Does anyone have any thoughts on this patch/approach?  Would
the net-snmp project be willing to accept the patch?  Thank you in
advance for any feedback or guidance.

commit 1c7881da5963508bcbcbd4ac44a60192fec4f7d8
Author: Mark Johnston <ma...@Fr...>
Date:   Thu Apr 4 16:34:26 2024 -0400

    snmpd: Enable the use of libkvm without kmem access on FreeBSD

diff --git a/agent/kernel.c b/agent/kernel.c
index 285a603a77..164a6a8ca2 100644
--- a/agent/kernel.c
+++ b/agent/kernel.c
@@ -259,7 +259,37 @@ free_kmem(void)
         kmem = -1;
     }
 }
+#elif defined(__FreeBSD__)
+kvm_t *kd;
+
+/**
+ * Initialize the libkvm descriptor. On FreeBSD we can use most of libkvm
+ * without requiring /dev/kmem access.  Only kvm_nlist() and kvm_read() need
+ * that, and we don't use them.
+ *
+ * @return TRUE upon success; FALSE upon failure.
+ */
+int
+init_kmem(const char *file)
+{
+    char err[4096];
 
+    kd = kvm_openfiles(NULL, "/dev/null", NULL, O_RDONLY, err);
+    if (!kd) {
+        snmp_log(LOG_CRIT, "init_kmem: kvm_openfiles failed: %s\n", err);
+        return FALSE;
+    }
+    return TRUE;
+}
+
+void
+free_kmem(void)
+{
+    if (kd != NULL) {
+        (void)kvm_close(kd);
+        kd = NULL;
+    }
+}
 #else
 int
 init_kmem(const char *file)

Re: Getting listening port number while processing request

[Teus B. <teu...@gm...>]

On Wed, 3 Apr 2024 at 18:45, Bart Van Assche <bva...@ac...> wrote:

>
> I think this is the callchain for registering the ports that the agent
> listens on:
>
[...]

> One possible approach is to implement the .f_setup_session() callback in
> the TCP transport and to make it copy the port information from the
> transport into the session.
>

Hi Bart,

Thank you for the very helpful information about the call chain for
registering the agent listening ports, and for the possible suggestions on
how to get the port number into the session.

I am going to look into this and try it all out.

My hope and expectation is that this leads to a good patch acceptable for
the Net-SNMP project!

Regards,

Teus